CVE-2026-43098

What it actually does

This is a local denial-of-service flaw in the Linux kernel NFC s3fwrn5 UART receive path. The vulnerable receive callback can consume bytes and deliver a complete NFC frame before allocating a new receive socket buffer. If that allocation fails, the function may incorrectly report that zero bytes were accepted while having already consumed data, leaving the receive buffer pointer NULL. A later receive callback can then dereference the NULL pointer during skb_put_u8(), causing a kernel oops or panic and impacting system availability. The CVSS vector indicates local access with low attack complexity and low privileges, with no confidentiality or integrity impact but high availability impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems that use the vulnerable NFC driver, causing service interruption, device reboot, workload disruption, or operational downtime. Risk is highest for systems with Samsung S3FWRN5/S3FWRN82 NFC hardware or enabled NFC UART support; systems without the affected driver or hardware path exposed are unlikely to be practically exploitable. The vulnerability is not listed in CISA KEV, has no known mature exploit, and has a very low and flat EPSS score, so broad internet-scale exploitation is unlikely, but availability-sensitive fleets should still prioritize kernel updates during normal maintenance cycles.

How an attack unfolds

An attacker first needs local access to a system where the affected Linux kernel NFC s3fwrn5 UART driver is present and reachable. The attacker then induces NFC UART receive activity while also creating or relying on memory pressure so that allocation of a new skb can fail at the vulnerable point. In the vulnerable code path, the driver may have already consumed bytes and completed processing of a frame before the failed allocation is handled. Because the callback can return an incorrect byte count and leave recv_skb NULL, the next receive event can attempt to append data to a NULL buffer, triggering a kernel NULL pointer dereference. The practical result is a kernel oops, panic, or hang, depending on kernel configuration, panic-on-oops settings, and service supervision.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the s3fwrn5 NFC receive-buffer allocation logic. No exact fixed package versions were provided in the input, so use the relevant distribution security advisory, vendor kernel errata, or upstream stable kernel changelog for the deployed kernel branch. Where immediate patching is not possible, reduce exposure by disabling NFC if not required, preventing the s3fwrn5/s3fwrn82 driver from loading where operationally safe, removing or disabling unused NFC hardware, and restricting local interactive access to systems with the affected driver. As a compensating control, ensure memory pressure from untrusted local users is constrained through cgroups, service limits, and resource controls, though these measures do not remove the underlying kernel bug.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the s3fwrn5 change described as allocating the receive skb before consuming bytes. Check the active kernel version with uname -a and compare it against the distribution advisory or fixed kernel build. Confirm whether the affected driver is present or loaded using lsmod, modinfo, or kernel configuration checks for s3fwrn5-related NFC support. If NFC is not required, validate that the relevant module is blacklisted or absent and that no affected NFC device is bound to the driver. Review kernel logs after patching or mitigation to ensure there are no recurring oops, panic, NULL pointer dereference, or s3fwrn5 receive-path errors under normal NFC activity.

Typical attack path

1. Identify a Linux system running an affected kernel with the s3fwrn5 NFC UART driver enabled or loaded.
2. Obtain local low-privileged access to the system.
3. Generate NFC receive activity through the affected device path or stimulate the attached NFC controller.
4. Create memory pressure or wait for an allocation failure in the receive-buffer allocation path.
5. Trigger the vulnerable sequence where bytes are consumed, a complete frame is delivered, and the next receive buffer allocation fails.
6. Cause a subsequent receive callback to dereference a NULL receive buffer pointer.
7. Crash or destabilize the kernel, resulting in denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs and crash artifacts for oopses, panics, or NULL pointer dereferences involving the NFC s3fwrn5/s3fwrn82 driver, the serdev receive path, or skb_put_u8. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps collected by kdump, pstore/ramoops records, and kernel panic telemetry from endpoint or fleet management tools. Correlate crash timestamps with local login records, sudo/session activity, container starts, memory-pressure events, OOM messages, NFC device activity, and module load events. Because exploitation requires local access and a specific driver path, look for repeated kernel crashes on systems with NFC enabled, especially where stack traces reference s3fwrn82_uart_read or s3fwrn5. There are no known public exploit-specific network indicators, and absence of these strings does not prove absence of exploitation if crash logging was not retained.

• s3fwrn82_uart_read
• s3fwrn5
• skb_put_u8
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• serdev
• nfc: s3fwrn5
• recv_skb
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /proc/modules

What your security team should do

• Inventory Linux systems for enabled NFC support and the s3fwrn5/s3fwrn82 driver, prioritizing laptops, embedded systems, kiosks, mobile-adjacent devices, and specialized hardware with NFC controllers.
• Patch affected systems through the normal kernel maintenance process, prioritizing availability-critical assets where local users or untrusted workloads can run code.
• Disable or blacklist the affected NFC driver on systems that do not require NFC functionality.
• Restrict local shell, container, and workload access on systems with the affected hardware until patched.
• Monitor kernel logs for NULL pointer dereferences, kernel oopses, panics, and stack traces referencing s3fwrn82_uart_read, skb_put_u8, serdev, or s3fwrn5.
• Apply resource controls to reduce the ability of low-privileged users or workloads to intentionally create memory pressure.
• Track distribution advisories for exact fixed kernel package versions because fixed versions were not provided in the source metadata.