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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 02 Dec 2023 19:01:04 +0530
From: Siddh Raman Pant <>
To: "Krzysztof Kozlowski" <>
Cc: "David S. Miller" <>,
	"Eric Dumazet" <>,
	"Jakub Kicinski" <>,
	"Paolo Abeni" <>, "netdev" <>,
	"linux-kernel" <>
Subject: Re: [PATCH 1/4] nfc: Extract nfc_dev access from
 nfc_alloc_send_skb() into the callers

On Mon, 27 Nov 2023 15:40:51 +0530, Krzysztof Kozlowski wrote:
> On 25/11/2023 21:26, Siddh Raman Pant wrote:
> > The only reason why nfc_dev was accessed inside nfc_alloc_send_skb() is
> > for getting the headroom and tailroom values.
> > 
> > This can cause UAF to be reported from nfc_alloc_send_skb(), but the
> > callers are responsible for managing the device access, and thus the
> > UAF being reported, as the callers (like nfc_llcp_send_ui_frame()) may
> > repeatedly call this function, and this function will repeatedly try
> > to get the same headroom and tailroom values.
> I don't understand this sentence.
> "This can cause ..., but ...". But starts another clause which should be
> in contradictory to previous one.

Sorry about that, I should have phrased it better.

> > Thus, put the nfc_dev access responsibility on the callers and accept
> > the headroom and tailroom values directly.
> Is this a fix or improvement? If fix, is the UAF real? If so, you miss
> Fixes tag.

I intended to remove access to nfc_dev (accessing which causes UAF) inside
this function, as it is used only for fetching headroom and tailroom integral

nfc_llcp_send_ui_frame() called this function in a do-while loop, so
I thought of extracting the values before the loop, so that in the next
patch where I used locking, I would have to lock only once*.

Since these are two units of changes, I separated them into two patches.

Though since the next patch is shit anyways, this patch is not needed.


Powered by blists - more mailing lists