From: Nagamani PV <nagamani@linux.ibm.com>
To: Alexandra Winter <wintera@linux.ibm.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Cc: horms@kernel.org, linux-s390@vger.kernel.org,
netdev@vger.kernel.org, twinkler@linux.ibm.com,
heiko.carstens@de.ibm.com, hidayath@linux.ibm.com,
borntraeger@linux.ibm.com, stable@vger.kernel.org
Subject: Re: [PATCH net-next] net/iucv: fix UAF in afiucv_netdev_event()
Date: Tue, 4 Aug 2026 18:22:18 +0530 [thread overview]
Message-ID: <029629de-ee55-4b3e-a7fb-a693c2b1261d@linux.ibm.com> (raw)
In-Reply-To: <9cda0e57-ce4b-428b-9385-743fdef02789@linux.ibm.com>
On 04/08/26 2:03 PM, Alexandra Winter wrote:
>
> As this is a fix, it should have been prefixed with net and not net-next.
>
Apologies for that — you had already corrected this in the internal
review. v2 will use [PATCH net] and include your Reviewed-by.
>
> See the discussions with Bryam Vargas [1]:
> It is correct that afiucv_netdev_event() is missing lock protection.
>
> However for a complete solution it should call lock_sock()
> (because netdev events are called in process context) and handle
> owned_by_user and a backlog queue.
>
> So this patch improves the situation, but is not the complete solution.
> I'd rather continue to work on a more complete fix than take this one,
> but both ways are possible.
>
Understood. This patch addresses the UAF on iucv_sk_list traversal
specifically. The lock_sock() concern is at a different level and
could be a follow-up.
Could you clarify your preference — take this as an incremental fix
with a follow-up for lock_sock(), or hold and work toward a combined
solution?
Thanks,
Nagamani
> Kind regards
> Alexandra
>
> [1] https://lore.kernel.org/netdev/20260724222917.134769-1-hexlabsecurity@proton.me/
>
>
>
>
next prev parent reply other threads:[~2026-08-04 12:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 18:20 [PATCH net-next] net/iucv: fix UAF in afiucv_netdev_event() Nagamani PV
2026-08-04 8:33 ` Alexandra Winter
2026-08-04 12:52 ` Nagamani PV [this message]
2026-08-04 13:30 ` Alexandra Winter
2026-08-04 18:21 ` sashiko-bot
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=029629de-ee55-4b3e-a7fb-a693c2b1261d@linux.ibm.com \
--to=nagamani@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hidayath@linux.ibm.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=twinkler@linux.ibm.com \
--cc=wintera@linux.ibm.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 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.