Re: [PATCH net 2/2] net: usb: lan78xx: reject short register and statistics reads

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] Three statements in this commit message (tagged for stable) do
  not match the code at its parent.

--

net: usb: lan78xx: reject short register and statistics reads

This patch makes lan78xx_read_reg() and lan78xx_read_stats() return -EIO
when usb_control_msg() transfers fewer bytes than requested. Before this,
uninitialized kmalloc() memory could be used as a register value or as the
statistics counters.

> With an emulated device on a kernel booted with init_on_alloc=0:
>
> - A zero-length reply to the statistics request makes ethtool -S, which
>   needs no privileges, report the stale contents of the kmalloc-192
>   buffer. One counter pair read back as 0xffffffff8a427800, the
>   address of usb_api_blocking_completion(), next to several direct
>   map pointers.
>
> - A zero-length reply to the RX_ADDRL/RX_ADDRH reads in
>   lan78xx_init_mac_address() turns uninitialized heap memory into the
>   MAC address (12:85:1f:dc:2e:bd and e6:93:44:41:9b:9f on two probes),
>   which is then written back to the device in RX_ADDRL/RX_ADDRH and
>   MAF_LO(0)/MAF_HI(0).
>
> Treat a short transfer as -EIO in both helpers. With this change the
> same device fails to probe with -EIO, and with only the statistics
> reply cut short all counters stay zero.

[Severity: Medium]

Can the zero-length statistics case still be reproduced at this patch's
parent?

The previous patch in the series, "net: usb: lan78xx: do not update
statistics after a failed read", already updates curr_stat only when the
return value is positive:

drivers/net/usb/lan78xx.c:lan78xx_update_stats() {
    ...
	if (lan78xx_read_stats(dev, &lan78xx_stats) > 0) {
		lan78xx_check_stat_rollover(dev, &lan78xx_stats);

		for (i = 0; i < (sizeof(lan78xx_stats) / (sizeof(u32))); i++)
			data[i] = (u64)p[i] +
				  ((u64)count[i] * ((u64)max[i] + 1));
	}
    ...
}

A zero-length reply makes usb_control_msg() return 0. Then
lan78xx_read_stats() returns 0 and dev->stats.curr_stat is never written.

With that patch applied, it looks like only a partial reply of 1 to 187
bytes still leaks the uninitialized tail of the kmalloc() buffer. The
message doesn't mention that case.

For the same reason, wouldn't "with only the statistics reply cut short all
counters stay zero" also be true without this patch when the reply has zero
length?

Could the message also mention that it depends on the previous patch? Both
patches are Cc: stable, but they have different Fixes: tags (20ff55655a93
and 55d7de9de6c3).

If this patch is backported alone, lan78xx_read_stats() returns -EIO
without writing data. The old lan78xx_update_stats() still runs the loop
unconditionally:

	if (lan78xx_read_stats(dev, &lan78xx_stats) > 0)
		lan78xx_check_stat_rollover(dev, &lan78xx_stats);

	for (i = 0; i < (sizeof(lan78xx_stats) / (sizeof(u32))); i++)
		data[i] = (u64)p[i] + ((u64)count[i] * ((u64)max[i] + 1));

The heap leak would then become a leak of the uninitialized on-stack
lan78xx_stats through ethtool -S, and the counters would not stay zero.

In the MAC paragraph, is the RX_ADDRL/RX_ADDRH write-back accurate? In
lan78xx_init_mac_address(), those registers are only written when the
address is invalid, after addr has been replaced from DT, EEPROM, OTP or a
random address:

	if (!is_valid_ether_addr(addr)) {
		...
		ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
		...
		ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
		...
	}

	ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);

Both quoted addresses (12:85:1f:dc:2e:bd and e6:93:44:41:9b:9f) are valid
unicast addresses, so they skip that block. Only MAF_LO(0)/MAF_HI(0) and
the netdev address set by eth_hw_addr_set() receive the value taken from
the heap.

The code change itself looks correct.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261014025602.26334-1-law.wei.jie%40gt.tech.gov.sg