Re: Fwd: UAF in NFC digital DEP link-up (kernel heap info leak)
David Heidelberg <[email protected]>
| Newsgroups | dev.linux.lists.oe-linux-nfc |
|---|---|
| Message-ID | <[email protected]> |
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* <[email protected] > <mailto:[email protected]>> > Date: Sat, Jul 4, 2026 at 10:14 PM > Subject: UAF in NFC digital DEP link-up (kernel heap info leak) > To: <[email protected] <mailto:[email protected]>> > > > 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