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: <18c2ab9bba5.26abdb8f38744.5002982123699219766@siddh.me> Date: Sat, 02 Dec 2023 19:01:04 +0530 From: Siddh Raman Pant <code@...dh.me> To: "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org> Cc: "David S. Miller" <davem@...emloft.net>, "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>, "Paolo Abeni" <pabeni@...hat.com>, "netdev" <netdev@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org> 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 values. 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. Thanks, Siddh
Powered by blists - more mailing lists