Hello,
I recently came across serious issues using U-Boot on Beagle Bone
Black. The USB Ethernet gadget is behaving in a way that is not
compliant with the uclass expectations, leading to use-after-free
accesses often producing data aborts. All network commands are
affected.
There are two problems:
* Any network command after completion could produce a data abort
* A tftp retrieval with a wrong file name would produce a data abort
Here is how the major issue (the former one) looks like:
=> tftp 0x81000000 zImage
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC f8:dc:7a:00:00:02
HOST MAC f8:dc:7a:00:00:01
RNDIS ready
musb-hdrc: peripheral reset irq lost!
high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
USB RNDIS network up!
Using usb_ether device
TFTP from server 192.168.0.1; our IP address is 192.168.0.100
Filename 'zImage'.
Load address: 0x81000000
Loading: ################################################## 13 MiB
4.2 MiB/s
done
Bytes transferred = 13634360 (d00b38 hex)
data abort
pc : [<9ff80fba>] lr : [<9ff7abd9>]
reloc pc : [<8081bfba>] lr : [<80815bd9>]
sp : 9df2f9f8 ip : 00000020 fp : 00000003
r10: 00000200 r9 : 9df44ea0 r8 : 9df2fa68
r7 : 9df2fa68 r6 : 9ffdbabc r5 : 9ffcdbcd r4 : 00000018
r3 : 00000018 r2 : 9ffdba00 r1 : 00000001 r0 : 9df4d348
Flags: Nzcv IRQs off FIQs on Mode SVC_32 (T)
Code: 68c2 6881 f023 0303 (60ca) 4403
Resetting CPU ...
While debugging this issue, I came across Qianfan's bug report which
raised this issue one year ago. Qianfan nicely pointed at two of his
patches sent on the mailing list following his investigations, which
IMHO got refused for a wrong reason.
Link: https://lore.kernel.org/all/7536b9e1-de7a-a492-6951-485d4eb75...@163.com/
Link:
https://patchwork.ozlabs.org/project/uboot/patch/20220402025836.19374-1-qianfangui...@163.com/
Link:
https://patchwork.ozlabs.org/project/uboot/patch/20220402025836.19374-2-qianfangui...@163.com/
I've taken over Qianfan's two patches, I took the liberty to explain a
bit more what these issues were about and why they were serious,
rewording his first patch, and trying to fix the second issue
differently, because I believe the second issue should be avoided rather
than workarounded.
Once ready to send this series, I noticed that two other people already
tried to fix this:
Link: https://lore.kernel.org/all/20221212204411.2247170-1-b...@baylibre.com/
Link: https://lists.denx.de/pipermail/u-boot/2022-December/502055.html
I have no idea why this is still an open issue, I hope the "code
reorganization" reason that was mentioned in one of the above threads
does not stand anymore given how serious these issues are, so whatever
solution is preferred, I hope one will soon be picked-up :-)
Thanks,
Miquèl
Miquel Raynal (1):
net: tftp: Prevent too early device removal leading to data aborts
Qianfan Zhao (1):
net: eth-uclass: Prevent data aborts with the Ethernet USB gadget
net/eth-uclass.c | 14 ++++++++++++--
net/tftp.c | 1 -
2 files changed, 12 insertions(+), 3 deletions(-)
--
2.34.1
