mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Wei Jie Law <law.wei.jie@gt.tech.gov.sg>
Cc: Thangaraj Samynathan <Thangaraj.S@microchip.com>,
	UNGLinuxDriver@microchip.com, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	netdev@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, Wei Jie Law <98lawweijie@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH net v2 2/2] net: usb: lan78xx: reject short register and statistics reads
Date: Sun, 18 Oct 2026 18:09:58 +0200	[thread overview]
Message-ID: <ce3a8add-3bf2-4507-b778-a0f8a10370c7@lunn.ch> (raw)
In-Reply-To: <20261018061734.19488-3-law.wei.jie@gt.tech.gov.sg>

On Sun, Oct 18, 2026 at 02:17:34PM +0800, Wei Jie Law wrote:
> From: Wei Jie Law <98lawweijie@gmail.com>
> 
> lan78xx_read_reg() and lan78xx_read_stats() read from the device into
> a freshly kmalloc()ed buffer, but only treat a negative return value
> from usb_control_msg() as an error. A device that answers with fewer
> bytes than requested leaves part or all of the buffer uninitialized,
> and those bytes are then used as the register value or the counters.

You are assuming reading registers can fail with sort reads. To be
symmetric, don't you have to assume writes can also fail in the same
way? Should lan78xx_write_reg() have a similar test?

> With an emulated device on a kernel booted with init_on_alloc=0:
> 
> - A reply to the statistics request that is shorter than the 188 byte
>   counter block leaves the rest of the kmalloc-192 buffer stale, and
>   ethtool -S, which needs no privileges, reports it. Before the
>   previous patch, a zero-length reply was enough: one counter pair read
>   back as 0xffffffff8a427800, the address of
>   usb_api_blocking_completion(), next to several direct map pointers.
>   With the previous patch a zero-length reply is already harmless, but
>   a reply of 1 to 187 bytes still gets through.
> 
> - 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).
>   Both of those are valid unicast addresses, so they are used as they
>   are: written to MAF_LO(0)/MAF_HI(0) and set as the address of the
>   net device, where anyone can read it.

If short reads can happen, bad things are expected to happen. No need
for examples.

> This patch needs the previous one. Without it, a failed statistics read
> would make lan78xx_update_stats() compute the counters from its
> uninitialized on-stack buffer, so the leak would move from the heap to
> the stack. Both patches are Cc: stable and should be backported
> together.

This belongs below the --- so that is it not part of the commit
message.

    Andrew

---
pw-bot: cr

  reply	other threads:[~2026-10-18 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-18  6:17 [PATCH net v2 0/2] net: usb: lan78xx: do not use uninitialized data after short reads Wei Jie Law
2026-10-18  6:17 ` [PATCH net v2 1/2] net: usb: lan78xx: do not update statistics after a failed read Wei Jie Law
2026-10-18  6:17 ` [PATCH net v2 2/2] net: usb: lan78xx: reject short register and statistics reads Wei Jie Law
2026-10-18 16:09   ` Andrew Lunn [this message]
2026-10-19  2:17     ` Wei Jie Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce3a8add-3bf2-4507-b778-a0f8a10370c7@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=98lawweijie@gmail.com \
    --cc=Thangaraj.S@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=kuba@kernel.org \
    --cc=law.wei.jie@gt.tech.gov.sg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®