Linux NFC CVE-2026-23330 Fix: Complete In-Flight Exchange on Device Close

The Linux kernel’s NFC stack is getting a small but important correctness fix in CVE-2026-23330, and the problem is exactly the kind of lifecycle bug that kernel maintainers try to stamp out early. In nci_close_device(), the kernel now completes any pending data exchange before the NFC device is shut down, preventing a socket reference from being left behind when the callback never gets a chance to finish cleanly. The upstream stable patch describes the issue as a leak observed by NIPA, with the callback path holding a socket reference that could survive device close if the exchange was not explicitly completed first.

Overview​

At first glance, this looks like a narrow NFC maintenance patch, not a headline-grabbing security flaw. But in kernel terms, narrow fixes often matter precisely because they sit at the boundary between object lifetime, asynchronous work, and teardown ordering. The stable tree patch shows that the affected code path lives inside the NCI subsystem, where device shutdown already has to coordinate command work queues, timers, and protocol state before returning control to the caller.
The vulnerability record itself makes the same point from a different angle: the issue was not about parsing malformed frames or overreading buffers, but about failing to finish an in-flight exchange before closing the device. That distinction matters because teardown bugs are frequently dismissed as “just cleanup” until they become persistent leaks, state corruption risks, or hard-to-reproduce failures under load. The fact that the callback holds a socket reference raises the stakes, because socket lifecycle mistakes in kernel networking code often cascade beyond a single subsystem.
This CVE was published through Microsoft’s Security Update Guide, but the technical source is clearly upstream Linux kernel material, with the patch tied to stable review and the original upstream commit. That is a familiar pattern in modern vulnerability reporting: one vendor surfaces the record, while the Linux community, stable maintainers, and downstream distributions do the real work of tracking and shipping the fix.

Background​

The NFC subsystem in Linux is a layered piece of infrastructure. The NCI layer, or NFC Controller Interface, is the glue between higher-level NFC logic and controller-specific behavior, and that means it has to manage device state carefully as operations begin, complete, and unwind. In practice, those transitions are often asynchronous, which makes shutdown paths especially sensitive to timing.
The patch content shows that nci_close_device() already had to flush command work, delete timers, and unwind internal flags. The new change adds one more requirement: if NCI_DATA_EXCHANGE is still active, the kernel must call nci_data_exchange_complete() with -ENODEV before final close. That is a classic kernel design move: rather than letting a pending operation dangle, the code forces completion with an error so every holder of a reference gets a deterministic end state.
That approach is especially important in a subsystem like NFC, where user space may be talking to raw sockets or higher-level protocol objects while the device itself is being torn down. If the kernel closes the hardware-facing side too early, a callback may never fire, the reference count may never drop, and an object that should be ephemeral can linger longer than intended. That is exactly the kind of bug NIPA was catching here.
The change also fits into a broader pattern across Linux networking and protocol code: lifecycle completion is often the real fix, not a bigger lock. When the data path is already inherently asynchronous, the safe shutdown strategy is usually to complete outstanding work in a controlled way before freeing or invalidating the device context. This CVE is a compact example of that philosophy.

What the Patch Changes​

The stable patch is only nine added lines, but those lines close the exact hole described by the vulnerability report. In both branches of the close logic shown in the diff, the kernel now checks whether the data exchange bit is set and, if so, completes the exchange with an explicit -ENODEV error. That error tells the callback path that the device is no longer available and that teardown is in progress.

Why -ENODEV matters​

Using -ENODEV is not just a convenient return code. It is the kernel’s way of saying that the hardware or logical device is gone, so any outstanding operation must stop depending on it. In effect, the close path is now making the asynchronous state machine consistent rather than hoping a deferred callback arrives in time.
This is also why the patch is better than a simple “wait and hope” approach. The close routine already flushes relevant workqueues and timers, but the data exchange callback itself is the object that owns the socket reference, so the teardown has to explicitly resolve that ownership. Otherwise, the kernel can clean up the transport shell while leaving the payload of the operation alive in a half-finished state.

The leak mechanism​

The patch text makes the leak mechanism unusually clear. The callback, such as rawsock_data_exchange_complete, holds a socket reference, and NIPA occasionally detects an “unreferenced object” associated with the NFC device close path. That is a strong sign that the reference counting discipline is correct most of the time but fails under a race window or a missing completion path.
The backtrace included in the report also anchors the issue in socket creation and NFC raw socket setup. That matters because it shows the leak is not merely theoretical; it is rooted in the actual socket lifecycle used by NFC userspace access paths. A bug like that can be invisible during normal testing and still be exercised repeatedly by fuzzing or stress workloads.

Why This Became a CVE​

Not every kernel leak becomes a CVE, so it is worth asking why this one did. The answer is that CVEs often track correctness flaws when they can affect reliability, lifecycle safety, or security-relevant resource handling in a shared subsystem. A socket reference leak in the teardown path can degrade stability, complicate recovery, and create the sort of latent state problems that kernel teams prefer to eliminate proactively.

Reliability is part of security​

This is one of those cases where the reliability/security boundary is blurry by design. A leak is not a buffer overflow, but it can still be operationally serious if it leaves kernel objects hanging around, prevents clean shutdown, or makes subsequent device operations behave unpredictably. In a networking stack, that kind of failure is often enough for security teams to want a tracked identifier and a fixed build.
The fact that the issue came from NIPA is also important. Fuzzing and automated kernel testing increasingly surface bugs that may never appear in ordinary manual QA. Those tools do not just find crashes; they find lifecycle mismatches, missing callbacks, and state transitions that are technically legal only if every edge case behaves perfectly.

Impact on Systems and Users​

The immediate impact is most likely limited to systems that actually use the Linux NFC stack and the affected NCI code path. That means this is not a generic desktop emergency for every Linux user, but it is still a meaningful fix for embedded systems, specialized NFC deployments, and anyone relying on raw NFC socket functionality.

Enterprise vs consumer exposure​

For enterprise fleets, the question is less about exploit drama and more about whether the kernel tree includes the fix and whether NFC features are enabled at all. Many servers will never touch NFC, but appliance-style systems, integrated readers, or device-lifecycle-heavy platforms may. In those environments, a teardown leak can matter even if no attacker is actively poking at it.
For consumers, the risk is usually narrower unless the machine is running a Linux build with NFC support in a relevant form factor. The issue is still worth patching because kernel bugs rarely stay isolated once vendors begin backporting and hardening adjacent code. Even when the practical exposure is low, the maintenance value of the fix is real.
This also means vulnerability managers should avoid over-reading the CVE label. A lifecycle leak in a subsystem is not automatically a remote code execution risk, but it is still a valid patch item, especially when the patch is already in the stable queue and clearly tied to an upstream fix.

The Role of Asynchronous Cleanup​

The essence of the bug is that asynchronous work can outlive the device if the shutdown path does not explicitly resolve it. That is a familiar problem in kernel code, where workqueues, timers, callbacks, and reference counts all need to agree about when an object is still alive. If one of those participants misses the memo, the object can leak or be used after teardown.

Callback ownership and reference counts​

A callback that holds a socket reference is effectively extending the lifetime of the socket until it says otherwise. If the close path does not force completion, the reference may remain pinned because the callback never executes its final release logic. That is why the patch does not simply clear a flag or stop future submissions; it actively completes the in-flight exchange.
This pattern is common in well-engineered kernel code. The close routine becomes the final arbiter of lifecycle state, and any pending work is told to finish in a defined error state instead of limping on. That is much safer than relying on deferred events to “eventually” clean up after themselves.

Why cleanup bugs keep recurring​

Cleanup bugs recur because they are easy to underestimate. Developers focus on the fast path, while teardown code gets less runtime attention and often fewer test iterations. But in real systems, teardown happens constantly: devices are unplugged, processes exit, sockets close, and state machines reset.
When the teardown path is wrong, it can produce leaks that only appear under stress or fuzzing. That makes this CVE a good reminder that closing a device is not a passive act; it is an active protocol transition that has to account for every outstanding reference.

Relationship to Linux Stable and Downstream Vendors​

The fix is already in the stable pipeline, which is usually the clearest sign that maintainers consider a patch suitable for backporting. The patch page identifies the change as part of a 6.18 stable series review, and the content explicitly links it to the upstream commit. That strongly suggests downstream Linux vendors can absorb the correction without pulling in unrelated features.

Backportability is part of the story​

A tiny patch like this is attractive to stable maintainers because the scope is narrow and the behavior change is obvious. There is no redesign of the NFC subsystem, no new API surface, and no speculative optimization. The fix simply ensures that outstanding exchanges are completed before the device is torn down.
That makes the vulnerability comparatively easy to manage for distribution security teams. It also means the practical question for administrators is likely to be not “Is there a patch?” but “Has my vendor already shipped the backport?” In Linux security, those are very different questions.
The bigger lesson is that downstream safety depends on prompt stable adoption. Users rarely consume upstream commit IDs directly; they consume vendor kernel builds, which means the real mitigation path runs through distribution release engineering. This CVE is exactly the type that tends to disappear quietly into a routine kernel update once the backport lands.

How to Think About Severity​

The publication record does not yet show an NVD-assigned CVSS score, so organizations should resist the temptation to treat the absence of a score as evidence of low importance. A missing score often just means enrichment is still in progress. The patch itself, however, provides enough detail to judge the issue as a real kernel correctness flaw with observable impact on reference handling.

Not a dramatic exploit, still worth fixing​

There is no indication in the patch that this is a direct privilege-escalation primitive or a memory-corruption path. The more likely risk is operational: leaked references, state inconsistencies, and hard-to-diagnose cleanup anomalies. Those are the kinds of issues that security teams often undervalue until they cause service churn or complicate later incident response.
That said, it would be a mistake to dismiss it as “just a leak.” Kernel reference leaks can be the first sign of a bad lifecycle contract, and lifecycle bugs can become much more serious when combined with other state transitions. In other words, the patch deserves attention even if it is not the sort of flaw that headlines usually focus on.

Strengths and Opportunities​

This patch has a lot going for it, both technically and operationally. It is small, targeted, and easy to reason about, which is exactly the kind of fix administrators and stable maintainers like to see in a kernel release. More importantly, it addresses the root cause rather than masking the symptom.

• Minimal code change reduces regression risk.
• Explicit completion makes teardown deterministic.
• Socket reference handling is corrected at the source.
• Stable backportability should be straightforward.
• Fuzzing feedback loop improves future kernel hardening.
• Low subsystem blast radius makes deployment easier.
• Clear upstream lineage simplifies vendor tracking.

Risks and Concerns​

The main concern is not that this patch is complex, but that lifecycle bugs often hide in adjacent paths. If one teardown case missed completion, there may be other close, reset, or error branches in the NFC stack that deserve the same scrutiny. Another concern is that systems with vendor kernels may not immediately map the CVE to the exact fixed build, which can leave administrators guessing.

• Adjacent cleanup paths may deserve review.
• Vendor backport delays can obscure fixed status.
• Low severity assumptions may lead to underpatching.
• Fuzz-only reproduction can hide real-world exposure.
• Reference leaks can become harder to diagnose later.
• Subsystem-specific usage may complicate asset inventory.
• Incomplete vulnerability scoring leaves triage teams without a quick benchmark.

What to Watch Next​

The most important next step is simple: watch for the fix to propagate into vendor kernels and LTS branches. Because the patch is already in stable review, it should not be a long wait, but the exact timing will vary across distributions and appliance vendors. Administrators should also watch for any related cleanup changes in the NFC stack, because one teardown bug often prompts maintainers to inspect neighboring lifecycle logic.
A second thing to monitor is whether any downstream advisories assign a formal severity score or additional exploitation context. For now, the technical signal is clear enough to justify patching, but scoring can influence enterprise prioritization. A third item is whether the fix lands alongside broader NFC or networking maintenance in your vendor’s next kernel rollup, which could make remediation easier to bundle into routine updates.

• Vendor kernel backports
• Stable branch adoption
• Any sibling NFC cleanup patches
• Enterprise vulnerability scoring updates
• Distribution release notes and kernel changelogs

CVE-2026-23330 is not the sort of Linux kernel flaw that makes for flashy headlines, but it is exactly the kind of bug that keeps kernel engineers awake: a small teardown omission, a hidden reference count dependency, and a cleanup path that had to be made explicit to keep the subsystem honest. In that sense, the fix is reassuring. It shows the Linux project still catches and corrects the subtle lifecycle mistakes before they harden into bigger problems, and it gives downstream vendors a clean patch to carry into supported kernels.

---

Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center