Re: Fwd: UAF in NFC digital DEP link-up (kernel heap info leak)

[David Heidelberg <david@ixit.cz>]

Hello Vladimir,

thank you for the report. Would be possible to send a patch based on [1]?

Please let me know.

Thanks
David

P.S. Same gos for the 2nd finding.

[1] https://codeberg.org/linux-nfc/linux/src/branch/for-linus


On 07/08/2026 12:32, vova tokarev wrote:
> Hi,
> 
> It's been almost two months since I reported this, and I haven't heard
> back. I recently learned I should reach out to the subsystem maintainer
> directly, so forwarding this to you.
> 
> The bug: digital_in_send_atr_req() in net/nfc/digital_dep.c stores a
> raw struct nfc_target * pointer as cb_context (line 522). A concurrent
> poll cycle frees the targets array via nfc_targets_found(), leaving a
> dangling pointer. When digital_in_recv_atr_res() fires, it reads freed
> kmalloc-96 memory -- leaking a kernel heap pointer to userspace via
> NFC_ATTR_TARGET_INDEX netlink multicast.
> 
> Triggers reliably within 12-15 seconds using nfcsim (no hardware).
> Full PoC attached in the original report.
> 
> I'd appreciate any feedback when you get a chance.
> 
> Thanks,
> Vladimir
> 
> ---------- Forwarded message ---------
> From: *vova tokarev* <vladimirelitokarev@gmail.com 
> <mailto:vladimirelitokarev@gmail.com>>
> Date: Sat, Jul 4, 2026 at 10:14 PM
> Subject: UAF in NFC digital DEP link-up (kernel heap info leak)
> To: <security@kernel.org <mailto:security@kernel.org>>
> 
> 
> Hi,
> 
> I found a use-after-free in digital_in_recv_atr_res() in
> net/nfc/digital_dep.c. A stale nfc_target pointer freed by
> concurrent nfc_targets_found() is read by the ATR completion
> callback, leaking 4 bytes from freed kmalloc-96 to userspace
> via NFC_ATTR_TARGET_INDEX netlink broadcast.
> 
> No hardware needed (nfcsim). Fires in ~12 seconds. The PoC
> leaks a kernel struct page * pointer (0xc51a8000), defeating
> KASLR. The stale value also corrupts LLCP state.
> 
> Affected: Linux 3.13+
> Confirmed: 7.1.0 (aarch64) with KASAN
> 
> Attached: report, two PoCs (minimal + info leak), KASAN output.
> 
> Thank you,
> Vladimir Tokarev
> 

-- 
David Heidelberg