+Tom Rini in case this affects the release Hi Christian,
On Fri, 4 Apr 2025 at 01:46, Christian Kohlschütter <christ...@kohlschutter.com> wrote: > > Hi Simon, > > > On 1. Apr 2025, at 17:51, Simon Glass <s...@chromium.org> wrote: > >> > >> but I don't know precisely what these various functions are supposed to > >> do, and I can't find any path that leads from any of these to eth_halt(). > >> > >> Is it possible that U-Boot is failing to call eth_halt() in response to > >> ExitBootServices(), and is therefore leaving the network device active > >> and performing DMA while the kernel starts up? > > > > The dm_remove_devices_active() is supposed to handle this, but it is > > possible that one of the drivers lacks a remove() method. > > for what it's worth, this is happening on both ODROID N2+ (meson8b-dwmac) as > well as NanoPI R4S (rk_gmac-dwmac). > > I also don't understand why reverting > 06ef8089f876b6dabf56caba31a05c003f03c629 "fixes" this behavior. Does it mean > that any memalign / malloc may cause this? > Also, how can this failure mode be detected and prevented in code? > > I really don't fancy the thought of remote code injection into Linux initrd > by spoofing Ethernet packages, but it really looks like a possibility. Here's my idea of what might be going on based on Michael's observations: 1. designware_eth_start() starts the interface and designware_eth_stop() stops it 2. tx_descs_init() sets up the DMA and uses the device-private info (struct dw_eth_dev) 3. When the device is removed, the struct is freed, meaning that a future malloc() can use that same space. 4. DMA traffic could then write over the malloc() region I'm not seeing where the Ethernet device's stop() is called. The dwmac_meson8b driver does not have a remove() method, so presumably DMA is still running after the device is removed. Probably the correct fix would be to add a remove() method to that driver. Regards, Simon
