| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CADm8Te=Yp9KXGJia-oMp1pe91FWoZxgKOuF2WP5DpBFRfbtS-Q@mail.gmail.com>
Date: Sat, 13 Dec 2025 10:54:45 +0800
From: Tuo Li <islituo@...il.com>
To: Scott Branden <scott.branden@...adcom.com>
Cc: bcm-kernel-feedback-list@...adcom.com, arnd@...db.de,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read()
Hi Scott,
On Sat, Dec 13, 2025 at 2:34 AM Scott Branden
<scott.branden@...adcom.com> wrote:
>
> Hi Tuo,
>
> On Thu, Dec 11, 2025 at 9:10 PM Tuo Li <islituo@...il.com> wrote:
> >
> > Hi Scott,
> >
> > On Fri, Dec 12, 2025 at 8:00 AM Scott Branden
> > <scott.branden@...adcom.com> wrote:
> > >
> > > Hi Tuo,
> > >
> > > On Thu, Dec 11, 2025 at 3:42 PM Tuo Li <islituo@...il.com> wrote:
> > > >
> > > > Hi Scott,
> > > >
> > > > Thanks for your reply!
> > > >
> > > > On Fri, Dec 12, 2025 at 3:18 AM Scott Branden
> > > > <scott.branden@...adcom.com> wrote:
> > > > >
> > > > > Hi Tuo,
> > > > >
> > > > > On Wed, Dec 10, 2025 at 10:36 PM Tuo Li <islituo@...il.com> wrote:
> > > > > >
> > > > > > In the function bcm_vk_read(), the pointer entry is checked, indicating
> > > > > > that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the
> > > > > > following code may cause null-pointer dereferences:
> > > > > >
> > > > > > struct vk_msg_blk tmp_msg = entry->to_h_msg[0];
> > > > > > set_msg_id(&tmp_msg, entry->usr_msg_id);
> > > > > > tmp_msg.size = entry->to_h_blks - 1;
> > > > > >
> > > > > > To prevent these possible null-pointer dereferences, copy to_h_msg,
> > > > > > usr_msg_id, and to_h_blks from iter into temporary variables, and return
> > > > > > these temporary variables to the application instead of accessing them
> > > > > > through a potentially NULL entry.
> > > > > >
> > > > > > Signed-off-by: Tuo Li <islituo@...il.com>
> > > > > > ---
> > > > > > drivers/misc/bcm-vk/bcm_vk_msg.c | 12 ++++++++----
> > > > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/misc/bcm-vk/bcm_vk_msg.c b/drivers/misc/bcm-vk/bcm_vk_msg.c
> > > > > > index 1f42d1d5a630..665a3888708a 100644
> > > > > > --- a/drivers/misc/bcm-vk/bcm_vk_msg.c
> > > > > > +++ b/drivers/misc/bcm-vk/bcm_vk_msg.c
> > > > > > @@ -1010,6 +1010,9 @@ ssize_t bcm_vk_read(struct file *p_file,
> > > > > > struct device *dev = &vk->pdev->dev;
> > > > > > struct bcm_vk_msg_chan *chan = &vk->to_h_msg_chan;
> > > > > > struct bcm_vk_wkent *entry = NULL, *iter;
> > > > > > + struct vk_msg_blk tmp_msg;
> > > > > > + u32 tmp_usr_msg_id;
> > > > > > + u32 tmp_blks;
> > > > > > u32 q_num;
> > > > > > u32 rsp_length;
> > > > > >
> > > > > > @@ -1034,6 +1037,9 @@ ssize_t bcm_vk_read(struct file *p_file,
> > > > > > entry = iter;
> > > > > > } else {
> > > > > > /* buffer not big enough */
> > > > > > + tmp_msg = iter->to_h_msg[0];
> > > > > > + tmp_usr_msg_id = iter->usr_msg_id;
> > > > > > + tmp_blks = iter->to_h_blks;
> > > > > > rc = -EMSGSIZE;
> > > > > > }
> > > > > > goto read_loop_exit;
> > > > > > @@ -1052,14 +1058,12 @@ ssize_t bcm_vk_read(struct file *p_file,
> > > > > >
> > > > > > bcm_vk_free_wkent(dev, entry);
> > > > > > } else if (rc == -EMSGSIZE) {
> > > > > > - struct vk_msg_blk tmp_msg = entry->to_h_msg[0];
> > > > > > -
> > > > > > /*
> > > > > > * in this case, return just the first block, so
> > > > > > * that app knows what size it is looking for.
> > > > > > */
> > > > > > - set_msg_id(&tmp_msg, entry->usr_msg_id);
> > > > > > - tmp_msg.size = entry->to_h_blks - 1;
> > > > > You can just change entry to iter on these 2 lines here?
> > > > >
> > > > > > + set_msg_id(&tmp_msg, tmp_usr_msg_id);
> > > > > > + tmp_msg.size = tmp_blks - 1;
> > > > > > if (copy_to_user(buf, &tmp_msg, VK_MSGQ_BLK_SIZE) != 0) {
> > > > > > dev_err(dev, "Error return 1st block in -EMSGSIZE\n");
> > > > > > rc = -EFAULT;
> > > > > > --
> > > > > > 2.43.0
> > > > > >
> > > >
> > > > Thanks for the suggestion! My understanding is that you are suggesting
> > > > replacing entry with iter in the rc == -EMSGSIZE path. However, I am not
> > > > sure whether the objects referenced by iter can be modified or freed by
> > > > other threads, since this path runs outside the protection of chan->pendq
> > > > lock. If that can happen, accessing the objects via iter may lead to a data
> > > > race or a use-after-free.
> > > >
> > > > Could you please help confirm whether this scenario is possible? If my
> > > > concern is unfounded, I will prepare a v2 patch and replace entry with
> > > > iter as you suggested.
> > > >
> > > > Thanks again for your time and helpful feedback!
> > > >
> > > > Sincerely,
> > > > Tuo Li
> > >
> > > Portions of your response sound like it is coming from an AI tool.
> > > Are you using such?
> > > I am just commenting on your patch.
> > > Could you please examine the code to answer your questions?
> > >
> > > Regards,
> > > Scott
> >
> > Thanks for pointing it out.
> > I manually analyzed the code, wrote the patch and response, but I did
> > polish them through an AI tool because my English is not great.
> > I am sorry if that made the message look odd.
>
> I can see why you went with the approach you did now.
> Sure, we can go with this patch version.
>
> Reviewed-by: Scott Branden <scott.branden@...adcom.com>
> >
> > Sincerely,
> > Tuo Li
Thank you for your patience and help!
Sincerely,
Tuo Li
Powered by blists - more mailing lists