CVE-2026-46267

What it actually does

This vulnerability is a use-after-free race condition in the Linux kernel NFC HCI SHDLC code. During SHDLC teardown, the kernel frees the SHDLC context and purges related socket-buffer queues before synchronously stopping associated timers and state-machine work. A timer callback can still schedule work after or during teardown, and that work can then access freed SHDLC state or queues. A local attacker with sufficient ability to interact with the NFC subsystem may be able to trigger the race, causing kernel memory corruption, kernel crash, denial of service, or potentially local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems running affected Linux kernels with NFC support exposed to local users or untrusted workloads may be at risk of crashes or full host compromise. Because successful exploitation can provide high confidentiality, integrity, and availability impact, this is most relevant for shared Linux servers, desktops, kiosks, embedded devices, mobile-adjacent systems, and container or workload-hosting environments where local code execution is possible. The currently reported EPSS is low and there is no known CISA KEV listing or public exploit maturity, so broad opportunistic exploitation is not indicated, but kernel privilege-escalation flaws should still be prioritized in environments where untrusted users can execute code.

How an attack unfolds

An attacker first needs local access to execute code on an affected Linux system and a path to exercise the NFC HCI SHDLC functionality. They attempt to create teardown conditions for an SHDLC context while associated timers or state-machine work are still pending or running. By repeatedly racing teardown against timer callbacks and queued work, they try to cause the state-machine work handler to access memory that has already been freed. Depending on memory layout and exploitation reliability, this can result in an immediate kernel fault and system crash, or the freed memory may be reclaimed and manipulated to corrupt kernel objects. If the attacker can control the memory reuse precisely enough, the flaw may be leveraged to escalate from a local user context to kernel privileges.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the fix for the NFC HCI SHDLC teardown race. The corrected behavior synchronously stops SHDLC timers and cancels state-machine work before purging queues and freeing the SHDLC context. Because no universal fixed version was provided, use vendor advisories for the exact patched kernel package for each distribution or appliance. Where immediate patching is not possible, reduce exposure by disabling NFC support if it is not required, blacklisting or preventing loading of NFC-related kernel modules where operationally safe, and restricting local shell or code-execution access to trusted users only. Reboot systems after kernel updates so the patched kernel is actually running.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, using standard OS tooling such as `uname -r` and the distribution package manager. Verify that the installed and booted kernel corresponds to a vendor build that includes the NFC HCI SHDLC fix. If NFC is not required as a mitigation, confirm that NFC modules are not loaded and cannot be automatically loaded. Check for loaded NFC-related modules with commands such as `lsmod | grep -i nfc` and inspect kernel configuration where applicable. Review vendor security advisories, changelogs, or kernel commit references to confirm the fix is present. After remediation, reboot and re-check the active kernel version.

Typical attack path

1. Gain local code execution on a Linux system running an affected kernel.
2. Confirm that NFC support and the vulnerable HCI SHDLC code path are available or loadable.
3. Interact with the NFC subsystem to initialize SHDLC-related state.
4. Trigger SHDLC teardown while timers or state-machine work may still be active.
5. Repeatedly race teardown, timer callbacks, and queued work to induce use-after-free behavior.
6. Use the resulting memory corruption to crash the kernel or attempt privilege escalation.

How to detect it

There are no widely established public indicators of compromise for this vulnerability, and exploitation may leave only generic signs of kernel memory corruption or system instability. Review kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, and crash dump facilities for NFC, SHDLC, HCI, workqueue, timer, slab, or use-after-free related faults. Look for repeated local execution attempts followed by kernel oopses, panics, general protection faults, KASAN reports, or sudden reboots. On systems with audit or EDR telemetry, correlate suspicious local processes interacting with device interfaces, module loading, NFC sockets, or NFC-related utilities before a crash. If kernel crash dumps are available, inspect stack traces for NFC HCI SHDLC functions, timer callbacks, workqueue execution, or freed skb queue access. Absence of these artifacts does not prove non-exploitation because a successful privilege escalation may not produce a crash or durable logs.

• nfc: hci: shdlc
• llc_shdlc
• llc_shdlc_deinit
• shdlc
• sm_work
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• general protection fault
• Unable to handle kernel NULL pointer dereference
• workqueue
• timer callback
• skb_queue
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems with NFC support enabled or NFC-related kernel modules available, especially endpoints, embedded systems, kiosks, and shared systems.
• Prioritize patching systems where untrusted local users, sandboxed workloads, or third-party applications can execute code.
• Apply vendor-provided kernel updates and reboot into the patched kernel.
• If NFC is unnecessary, disable or blacklist NFC kernel modules as a compensating control after testing operational impact.
• Monitor kernel logs for crashes, use-after-free warnings, workqueue faults, NFC subsystem errors, or unexplained reboots on systems where NFC is enabled.
• Treat successful exploitation as potential kernel compromise; if suspicious crashes align with NFC activity, perform forensic triage and consider rebuilding affected hosts from trusted media.
• Track distribution advisories because fixed package versions vary by vendor and kernel branch.