[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADm8TekXPCwfYpiTUJuh6F6Uy3db-2rUzG900SJPz5Pad_dwrg@mail.gmail.com>
Date: Mon, 12 Jan 2026 01:25:29 +0800
From: Tuo Li <islituo@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: ayush.sawal@...lsio.com, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, kernelxing@...cent.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] chcr_ktls: add a defensive NULL check to prevent a
possible null-pointer dereference in chcr_ktls_dev_del()
Hi Jakub
On Fri, Jan 9, 2026 at 9:53 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 6 Jan 2026 20:33:02 +0800 Tuo Li wrote:
> > In this function, u_ctx is guarded by an if statement, which indicates that
> > it may be NULL:
> >
> > u_ctx = tx_info->adap->uld[CXGB4_ULD_KTLS].handle;
> > if (u_ctx && u_ctx->detach)
> > return;
> >
> > Consequently, a potential null-pointer dereference may occur when
> > tx_info->tid != -1, as shown below:
> >
> > if (tx_info->tid != -1) {
> > ...
> > xa_erase(&u_ctx->tid_list, tx_info->tid);
> > }
> >
> > Therefore, add a defensive NULL check to prevent this issue.
>
> There seems to be no locking here.
> It'd take much more to make this code safe, sprinking random ifs
> here and there seem like a waste of time.
Thanks for pointing this out.
Given the lack of proper locking here, I'd rather drop this patch than add
ad-hoc NULL checks.
Thanks for the review,
Tuo
Powered by blists - more mailing lists