From: Michael Ellerman <mpe@ellerman.id.au>
To: Ma Ke <make24@iscas.ac.cn>
Cc: ajd@linux.ibm.com, arnd@arndb.de, make24@iscas.ac.cn,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, manoj@linux.vnet.ibm.com,
imunsie@au1.ibm.com, fbarrat@linux.ibm.com,
linuxppc-dev@lists.ozlabs.org, dan.carpenter@linaro.org,
clombard@linux.vnet.ibm.com
Subject: Re: [PATCH v4] cxl: Fix possible null pointer dereference in read_handle()
Date: Fri, 19 Jul 2024 11:23:07 +1000 [thread overview]
Message-ID: <87msmew4xw.fsf@mail.lhotse> (raw)
In-Reply-To: <20240716132737.1642226-1-make24@iscas.ac.cn>
Ma Ke <make24@iscas.ac.cn> writes:
>> Michael Ellerman<mpe@ellerman.id.au> wrote:
>> > In read_handle(), of_get_address() may return NULL if getting address and
>> > size of the node failed. When of_read_number() uses prop to handle
>> > conversions between different byte orders, it could lead to a null pointer
>> > dereference. Add NULL check to fix potential issue.
>> >
>> > Found by static analysis.
>> >
>> > Cc: stable@vger.kernel.org
>> > Fixes: 14baf4d9c739 ("cxl: Add guest-specific code")
>> > Signed-off-by: Ma Ke <make24@iscas.ac.cn>
>> > ---
>> > Changes in v4:
>> > - modified vulnerability description according to suggestions, making the
>> > process of static analysis of vulnerabilities clearer. No active research
>> > on developer behavior.
>> > Changes in v3:
>> > - fixed up the changelog text as suggestions.
>> > Changes in v2:
>> > - added an explanation of how the potential vulnerability was discovered,
>> > but not meet the description specification requirements.
>> > ---
>> > drivers/misc/cxl/of.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/misc/cxl/of.c b/drivers/misc/cxl/of.c
>> > index bcc005dff1c0..d8dbb3723951 100644
>> > --- a/drivers/misc/cxl/of.c
>> > +++ b/drivers/misc/cxl/of.c
>> > @@ -58,7 +58,7 @@ static int read_handle(struct device_node *np, u64 *handle)
>> >
>> > /* Get address and size of the node */
>> > prop = of_get_address(np, 0, &size, NULL);
>> > - if (size)
>> > + if (!prop || size)
>> > return -EINVAL;
>> >
>> > /* Helper to read a big number; size is in cells (not bytes) */
>>
>> If you expand the context this could just use of_property_read_reg(),
>> something like below.
>>
>> cheers
>>
>>
>> diff --git a/drivers/misc/cxl/of.c b/drivers/misc/cxl/of.c
>> index bcc005dff1c0..a184855b2a7b 100644
>> --- a/drivers/misc/cxl/of.c
>> +++ b/drivers/misc/cxl/of.c
>> @@ -53,16 +53,15 @@ static const __be64 *read_prop64_dword(const struct device_node *np,
>>
>> static int read_handle(struct device_node *np, u64 *handle)
>> {
>> - const __be32 *prop;
>> u64 size;
>> +
>> + if (of_property_read_reg(np, 0, handle, &size))
>> + return -EINVAL;
>>
>> - /* Get address and size of the node */
>> - prop = of_get_address(np, 0, &size, NULL);
>> + // Size must be zero per PAPR+ v2.13 § C.6.19
>> if (size)
>> return -EINVAL;
>>
>> - /* Helper to read a big number; size is in cells (not bytes) */
>> - *handle = of_read_number(prop, of_n_addr_cells(np));
>> return 0;
>> }
> Thank you for discussing and guiding me on the vulnerability I submitted.
> I've carefully read through your conversation with Dan Carpenter. I'm
> uncertain whether to use my patch or the one you provided. Could you please
> advise on which patch would be more appropriate?
> Looking forward to your reply.
Your patch is OK, I'll send an ack.
If we want to refactor it to use of_property_read_reg() we can do that
in future - though this code will probably be removed in the not too
distant future anyway.
cheers
next prev parent reply other threads:[~2024-07-19 1:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 2:54 [PATCH v4] cxl: Fix possible null pointer dereference in read_handle() Ma Ke
2024-07-15 5:12 ` Greg KH
2024-07-15 6:28 ` Michael Ellerman
2024-07-15 17:11 ` Dan Carpenter
2024-07-16 13:27 ` Ma Ke
2024-07-19 1:23 ` Michael Ellerman [this message]
2024-07-15 13:18 ` Markus Elfring
2024-07-15 13:32 ` Greg Kroah-Hartman
2024-07-19 1:25 ` Michael Ellerman
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=87msmew4xw.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=ajd@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=clombard@linux.vnet.ibm.com \
--cc=dan.carpenter@linaro.org \
--cc=fbarrat@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=imunsie@au1.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=make24@iscas.ac.cn \
--cc=manoj@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).