In early 2026, the Linux kernel’s NFC stack gained a security fix that is easy to overlook at a glance but important in practice:
CVE-2026-23372 closes a race in the
rawsock path where transmit work could outlive the socket teardown sequence. The bug sits in a classic kernel danger zone—workqueue activity, device lifetimes, and asynchronous cleanup—and the reported failure mode is serious enough to include both
use-after-free risk and leaked references. For administrators, the headline is simple: this is the kind of kernel defect that can become instability, privilege boundary trouble, or both, depending on how it is triggered and what state the system is in. The fix has already been accepted upstream and assigned a CVE by kernel.org as part of the normal stable-kernel security process.
Background
Linux kernel CVEs are often assigned after the fix is available, not before, and that is exactly the pattern here. Kernel.org explicitly notes that CVEs are commonly attached to bug fixes that reach stable trees, with the commit ID serving as the anchor point for tracking and backporting. That workflow matters because it tells defenders this is not a speculative issue floating in abstraction; it is a concrete kernel change with a documented resolution path.
The vulnerable area is the
NFC subsystem, specifically the
raw socket implementation used to talk to NFC hardware. The kernel documentation describes NFC raw sockets as a user-facing interface for connecting to a target through
NFC_SOCKPROTO_RAW, which places the code in a narrow but real attack surface exposed to local userspace. That exposure is limited compared with a network daemon, but kernel bugs in socket teardown paths are notorious because they often combine timing sensitivity with object lifetime complexity.
The commit message tied to CVE-2026-23372 explains the race in plain terms:
rawsock_tx_work runs on the system workqueue and calls
nfc_data_exchange, which dereferences the NCI device. Without synchronization, that transmit work can overlap with socket destruction and device teardown if the owning process dies abruptly, such as under
SIGKILL. The result can be a stale pointer dereference, a freed device being touched again, or references that never get cleaned up correctly.
The Linux kernel’s own security-bug guidance reinforces why this matters operationally. It treats issues that might expose privilege escalation, memory corruption, or similar kernel integrity problems as security-sensitive even when exploitability is not fully obvious at first glance. That conservative posture is why a seemingly routine cleanup fix can still receive a CVE and travel through stable backports.
The Microsoft Security Response Center listing adds another clue to the issue’s significance: the CVE page points to multiple stable kernel commits, indicating that the fix has already been propagated or prepared across supported branches. That is a strong sign this is not just a mainline curiosity; it is the sort of bug maintainers expect distributors to absorb into long-term kernels.
What the bug actually is
At a technical level, the flaw is a
lifetime race between transmit work and teardown.
rawsock_release() is supposed to cleanly shut down the socket, but before this fix it could orphan the socket while queued or in-flight transmit work was still able to run. That means the worker thread could continue touching the NFC device object after the rest of the socket path had already moved on.
The kernel fix does three things in sequence: it sets
SEND_SHUTDOWN first, then uses
cancel_work_sync(), and finally purges any remaining queued SKBs from the write queue. That ordering is not accidental. It ensures any currently executing worker sees the shutdown flag and bails out, any in-progress work is waited on, and only then are leftover packets discarded. In kernel code,
ordering is security.
Why this sequence matters
If cleanup happened in the wrong order, the kernel could invalidate the very objects the worker still expects to use.
cancel_work_sync() is especially important because it blocks until any running instance of the work item finishes, eliminating a common race where a pointer remains valid only until the next scheduler slice. The purge step at the end handles packets that were queued but never started, which closes the remaining gap.
A key detail is the mention of
nfc_data_exchange, which dereferences the NCI device. That function sits at the boundary between socket operations and hardware-facing code, making it a natural place for a teardown race to become a memory-safety problem. When a kernel worker crosses subsystem boundaries like that, cleanup must be precise or the object graph can collapse under it.
- Set the shutdown flag first so running work can notice teardown.
- Wait for work completion with
cancel_work_sync().
- Drain remaining queued packets only after the worker is safe.
- Prevent device dereference after teardown.
- Reduce both UAF and leak risk in one pass.
Why SIGKILL is part of the story
The commit message specifically calls out a process killed by
SIGKILL. That is a good example of how kernel bugs are often triggered by abnormal but not rare system behavior. A hard kill can interrupt application-level cleanup and force the kernel to reconcile sockets, workqueues, and device references without the luxury of orderly user-space shutdown.
This matters because the most reliable exploitation paths in kernel bugs frequently rely on teardown edges rather than the “happy path.” The application may not be doing anything exotic; it may simply be dying at the wrong moment while asynchronous kernel work is still pending. In other words,
failure handling becomes the attack surface.
Teardown races are kernel-classic bugs
The Linux kernel is full of workqueues, deferred callbacks, and reference-counted objects, and they all interact under scheduler pressure. If one subsystem assumes another has already stopped using an object, a race window opens. In this case, the risk was not about malformed NFC payloads so much as about who still owns the device object when the last transmit completes.
The practical lesson is familiar to anyone who tracks kernel security: asynchronous cleanup code needs the same level of care as the “main” data path. A security flaw can emerge not from processing data, but from stopping the processing at the wrong time. That is why bugs like this are often hard to spot in review and yet important to patch decisively.
- SIGKILL can interrupt normal cleanup and expose edge conditions.
- Deferred work may still be running while teardown proceeds.
- The bug is about ownership timing, not packet parsing.
- Kernel races often surface during error paths and process death.
- Cleanup code must be synchronized as carefully as transmit code.
Impact on the Linux NFC stack
The direct impact is confined to the
Linux NFC subsystem, but the significance is broader because the bug lives in a socket implementation reachable from userspace. Linux NFC is not universally deployed on every server, but it does appear in embedded systems, specialized hardware, development platforms, and endpoint configurations with NFC support enabled. That combination means the exposure profile is narrower than a TCP stack flaw, yet still worth treating as a real security issue.
Because the vulnerable path is in a raw socket release routine, the impact is likely tied to local access and NFC-capable hardware or a configured NFC environment. That makes it less likely to be mass-exploitable over a network in the ordinary sense, but kernel bugs do not need remote reachability to be operationally serious. Local privilege escalation, denial of service, and memory corruption are all plausible consequences once a use-after-free appears in kernel space.
Consumer versus enterprise exposure
On consumer devices, NFC is often present but not always actively used. That reduces the immediate blast radius, yet laptops, tablets, and developer workstations can still carry the relevant kernel code and hardware support. If an attacker already has a foothold on the machine, a kernel race in a niche subsystem can become a valuable escalation primitive.
In enterprise environments, the concern is broader but more subtle. Fleet teams often standardize kernels across diverse hardware profiles, which means an NFC fix may need to be deployed even on systems that do not obviously use NFC every day.
Unused code is still loaded code when the kernel ships it as part of the platform image.
- Consumer systems face lower exposure if NFC is unused.
- Enterprise images may still carry the affected kernel path.
- Local attackers benefit most from teardown races.
- The main risks are UAF, crash, or reference corruption.
- Specialized devices and embedded systems may be especially relevant.
The fix and why it is correct
The patch is the kind of surgical kernel correction that looks small but closes a dangerous timing gap. By setting
SEND_SHUTDOWN early, the code establishes a visible state change for any worker already in motion. Then
cancel_work_sync() guarantees the active job has finished before teardown proceeds. Finally, purging the write queue removes stale packets that never made it to execution.
This ordering also demonstrates why kernel fixes are often more about sequencing than about adding new logic. The code is not being redesigned; it is being disciplined. The goal is to preserve the invariant that once release begins, no transmit worker should continue to behave as if the socket and NCI device are still alive.
What cancel_work_sync buys you
cancel_work_sync() is a heavyweight but correct mechanism for this scenario because it resolves both pending and in-flight execution. That is preferable to looser cleanup that only removes work from a queue, because queued and executing work are two different hazards. When the target object is a device with live references, merely “probably not running” is not enough.
There is also a broader software-engineering lesson here for kernel developers: flags alone are not synchronization. The shutdown flag helps the worker make a safer decision, but the synchronization primitive is what prevents a race from becoming a memory-safety issue. That blend of state signaling and blocking cleanup is what makes the fix robust.
- Early shutdown state prevents new transmit activity.
- Synchronization waits out the already-running worker.
- Queue purging handles packets that never started.
- The patch closes both corruption and leak paths.
- The fix is minimal, but the effect is comprehensive.
How this fits the kernel CVE pipeline
Kernel.org’s CVE documentation is useful here because it explains why security-adjacent bug fixes are regularly assigned CVEs after landing in stable trees. The Linux kernel maintainers intentionally take a conservative approach: if a bugfix might have security implications, they often assign a CVE even when exploitability is not fully proven. That means defenders should read CVE assignment as a signal of seriousness, not only of confirmed exploitation.
This also explains the multiple stable references attached to the record. A single upstream fix can be backported into several maintained branches, and the CVE record can point at more than one stable commit as those versions receive the correction. For security teams, that is a reminder to check both the mainline fix and the distro backport status, because the public CVE label alone does not tell you whether your specific kernel build is patched.
What administrators should infer
The absence of an NVD score at publication time does not mean the bug is minor. It usually means the advisory is still moving through enrichment and scoring workflows. In the Linux world, the kernel fix itself is often the best early indicator of severity, especially when the commit message names use-after-free risk or device reference hazards directly.
That said, not every kernel CVE maps to a remotely exploitable emergency. The correct posture is measured urgency: inventory your kernel versions, verify backports, and assess whether NFC support is present in your deployment.
Patch promptly, but verify carefully is the right formula here.
- CVE assignment can follow the fix rather than precede it.
- Stable branches are the critical deployment target.
- NVD scoring may lag behind kernel disclosure.
- Backport status matters as much as the upstream commit.
- Kernel CVEs often signal caution, not proof of exploitation.
Enterprise patching considerations
For enterprise fleets, the key question is not whether the affected code exists in theory, but whether the shipped kernel includes the fix. Linux distributors frequently maintain their own long-term kernels, and kernel.org’s active-release documentation shows that longterm branches remain supported for years. That means security teams need a patch-validation process that tracks vendor build numbers, not just upstream version strings.
In practice, this also means a vulnerability like CVE-2026-23372 can be present in older but still-supported enterprise kernels long after the mainline fix is known. The NFC subsystem is not always top of mind for patch windows, yet it should not be dismissed simply because it feels specialized. Kernel memory safety is a platform property, not an application feature.
Validation steps for admins
A good enterprise response has to be systematic rather than reactive. The best workflow is to confirm which kernel builds are deployed, check vendor advisories for backported fixes, and validate whether the affected NFC components are enabled in the shipping configuration. If your fleet uses generic images, assume more exposure than your hardware inventory suggests.
You should also remember that many embedded and specialized systems do not receive the same patch cadence as servers or desktops. That creates a lag between public disclosure and real-world remediation. In a kernel race condition, that lag can be the difference between “theoretical” and “operational.”
- Confirm vendor backports, not just upstream version numbers.
- Check whether NFC support is enabled in the image.
- Audit embedded and specialized hardware separately.
- Treat generic fleet images as potentially exposed.
- Verify patch deployment after update installation.
Consumer and developer impact
For consumers, this CVE is mostly about trust in the platform layer. The average user may never intentionally open a raw NFC socket, but kernel bugs rarely respect user intent. If a device supports NFC and the kernel feature is present, the risk exists whether or not the owner thinks of the machine as an NFC system.
For developers and researchers, the story is different. People working with NFC hardware, protocol testing, or kernel modules are more likely to exercise unusual teardown paths and stress the race window. That does not imply negligence; it simply means test rigs and developer workstations often create the conditions in which synchronization defects reveal themselves.
Why developers should care
Kernel developers should view this as another example of why workqueue cleanup patterns need defensive review. A socket release path is not just a resource deallocation function; it is a concurrency boundary. If one worker can still reference a hardware object after release has started, then the release logic has not actually finished its job.
This also highlights a broader quality issue: bugs in less-traveled code paths often survive because they are not exercised under real-world stress. That is especially true for subsystems like NFC, where normal user demand is lower than for networking or storage. The smaller the audience, the easier it is for a race to stay hidden until a hard-kill or teardown event exposes it.
- Consumer risk is lower in everyday use, but not zero.
- Developer rigs may expose the race more often.
- NFC hardware support makes the path relevant even when unused.
- Cleanup bugs often hide in uncommon execution paths.
- Kernel testing needs teardown-path coverage as much as happy-path coverage.
Broader competitive and ecosystem implications
Security issues like this do not stay isolated inside one subsystem. They affect perceptions of kernel maturity, distro maintenance quality, and the operational cost of supporting specialized hardware. A flaw in the NFC raw socket teardown path is not a headline rival vendors will market aggressively, but it is exactly the sort of issue that can quietly raise the cost of lifecycle management across the ecosystem.
The broader market implication is that Linux continues to demonstrate both its strength and its complexity. The strength is responsiveness: a fix lands, gets tracked, and flows into supported branches. The complexity is that modern kernel security is increasingly about coordination across asynchronous subsystems, and that means even a niche path can carry platform-wide implications.
Why this matters beyond NFC
NFC itself is not the point; the point is the pattern. Workqueue teardown races appear in many kernel subsystems, from storage to networking to power management. A well-handled fix in NFC is therefore useful as a case study for all kernel engineers, because it shows how to shut down deferred work without leaving a reference leak or an exploitable window behind.
For distributors and OEMs, the lesson is equally clear:
small subsystems can generate large support obligations. Once a CVE exists, customers will ask whether their kernel build is affected, whether the vendor backported the change, and whether any adjacent fixes were included. That documentation burden is part of the real cost of maintaining a long-lived Linux platform.
- Niche bugs can still create platform-wide support work.
- Kernel responsiveness helps, but does not eliminate risk.
- Asynchronous cleanup remains a common source of security defects.
- Distros and OEMs must explain backports clearly.
- The issue reinforces the value of strong stable-kernel governance.
Strengths and Opportunities
The good news is that this vulnerability was identified and corrected in a way that fits Linux’s established stable-kernel process. The fix is also conceptually strong: it blocks the race, prevents stale work from touching the device, and preserves object lifetime discipline without requiring invasive redesign. That makes it a clean patch for downstream maintainers to backport.
- The fix is targeted and minimal.
- It addresses both use-after-free and reference leak risk.
- The shutdown ordering is easy for maintainers to audit.
- Stable backports are straightforward to evaluate.
- The CVE record helps defenders track remediation.
- The bug reinforces good teardown design practices.
- Enterprises can use it as a test case for kernel patch verification.
Risks and Concerns
The main concern is that kernel CVEs often arrive in the field before everyone knows exactly which vendor builds are affected. Because the NVD record was still awaiting enrichment at publication time, some downstream tooling may lag behind the upstream fix. There is also the perennial problem that specialized code paths, especially in less common hardware stacks, may not receive the same validation intensity as major networking or storage paths.
- Downstream scoring and enrichment may lag.
- Vendor backports may be uneven across distributions.
- NFC-enabled systems may be overlooked in asset inventories.
- Hard-kill teardown paths are easy to under-test.
- Use-after-free bugs can be hard to reproduce reliably.
- Local attacker access would raise the practical risk significantly.
- Embedded systems may remain exposed longer than desktops.
Looking Ahead
The next step is boring but essential: patch verification. Security teams should confirm which kernels include the fix, compare distro advisories against the upstream change, and make sure systems with NFC support are not skipped just because the subsystem seems niche. The most dangerous assumption here is that “we don’t use NFC” automatically means “we can ignore the CVE.”
Longer term, this CVE is another reminder that kernel security work is increasingly about lifecycle control rather than input validation alone. Asynchronous work, deferred execution, and teardown paths are where mature systems still stumble. That is not a sign of fragility so much as a sign of how much correctness modern kernels must maintain at once.
- Validate vendor backports and package versions.
- Check embedded and workstation images separately.
- Review teardown paths in other workqueue-based code.
- Prioritize local privilege boundary issues in kernel triage.
- Keep an eye on later NVD enrichment and distro advisories.
In the end, CVE-2026-23372 is less about NFC as a technology than about the hard engineering truth that
cleanup is part of security. The patch fixes a race that could let deferred work outlive the objects it depends on, and that makes it a textbook kernel hardening change with real operational value. For administrators, the practical takeaway is simple: verify your kernel build, confirm the backport, and treat this as a reminder that even small subsystems can carry large consequences.
Source: NVD / Linux Kernel
Security Update Guide - Microsoft Security Response Center