From: Qasim Ijaz <qasdev00@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] net: fix uninitialised access in mii_nway_restart()
Date: Tue, 18 Feb 2025 12:19:57 +0000 [thread overview]
Message-ID: <Z7R6uet1dJ1UJsJ1@qasdev.system> (raw)
On Tue, Feb 18, 2025 at 02:10:08AM +0100, Andrew Lunn wrote:
> On Tue, Feb 18, 2025 at 12:24:43AM +0000, Qasim Ijaz wrote:
> > In mii_nway_restart() during the line:
> >
> > bmcr = mii->mdio_read(mii->dev, mii->phy_id, MII_BMCR);
> >
> > The code attempts to call mii->mdio_read which is ch9200_mdio_read().
> >
> > ch9200_mdio_read() utilises a local buffer, which is initialised
> > with control_read():
> >
> > unsigned char buff[2];
> >
> > However buff is conditionally initialised inside control_read():
> >
> > if (err == size) {
> > memcpy(data, buf, size);
> > }
> >
> > If the condition of "err == size" is not met, then buff remains
> > uninitialised. Once this happens the uninitialised buff is accessed
> > and returned during ch9200_mdio_read():
> >
> > return (buff[0] | buff[1] << 8);
> >
> > The problem stems from the fact that ch9200_mdio_read() ignores the
> > return value of control_read(), leading to uinit-access of buff.
> >
> > To fix this we should check the return value of control_read()
> > and return early on error.
>
> What about get_mac_address()?
>
> If you find a bug, it is a good idea to look around and see if there
> are any more instances of the same bug. I could be wrong, but it seems
> like get_mac_address() suffers from the same problem?
Thank you for the feedback Andrew. I checked get_mac_address() before
sending this patch and to me it looks like it does check the return value of
control_read(). It accumulates the return value of each control_read() call into
rd_mac_len and then checks if it not equal to what is expected (ETH_ALEN which is 6),
I believe each call should return 2.
>
> Andrew
next reply other threads:[~2025-02-18 12:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 12:19 Qasim Ijaz [this message]
2025-02-26 13:43 ` [PATCH] net: fix uninitialised access in mii_nway_restart() Andrew Lunn
2025-03-07 17:55 ` Qasim Ijaz
2025-03-07 17:56 ` Andrew Lunn
-- strict thread matches above, loose matches on Subject: below --
2025-02-27 23:15 Qasim Ijaz
2025-02-26 11:27 Qasim Ijaz
2025-02-18 0:24 Qasim Ijaz
2025-02-18 1:10 ` Andrew Lunn
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=Z7R6uet1dJ1UJsJ1@qasdev.system \
--to=qasdev00@gmail.com \
--cc=andrew@lunn.ch \
--cc=cf0d2929-d854-48ce-97eb-69747f0833f2@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.