CVE-2026-43098: nfc: s3fwrn5: allocate rx skb before consuming bytes
In the Linux kernel, the following vulnerability has been resolved:
nfc: s3fwrn5: allocate rx skb before consuming bytes
s3fwrn82_uart_read() reports the number of accepted bytes to the serdev
core. The current code consumes bytes into recv_skb and may already
deliver a complete frame before allocating a fresh receive buffer.
If that alloc_skb() fails, the callback returns 0 even though it has
already consumed bytes, and it leaves recv_skb as NULL for the next
receive callback. That breaks the receive_buf() accounting contract and
can also lead to a NULL dereference on the next skb_put_u8().
Allocate the receive skb lazily before consuming the next byte instead.
If allocation fails, return the number of bytes already accepted.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel bug in an NFC driver receive path. Under memory allocation failure, the driver can report that it consumed no bytes after already processing data, then leave its receive buffer unset. The next receive callback can dereference NULL, likely causing a kernel crash on affected systems using this NFC hardware path.
Executive priority
Treat as targeted operational risk unless your fleet uses this NFC driver. Patch through normal kernel maintenance, escalating for devices with NFC hardware enabled or unexplained kernel crashes. Current sources do not support emergency prioritization from exploitation activity.
Technical view
The s3fwrn5 NFC UART receive handler previously consumed bytes into recv_skb and could deliver a complete frame before allocating the next skb. If alloc_skb failed, it returned 0 despite accepted bytes and left recv_skb NULL, violating serdev receive_buf accounting and enabling a NULL dereference on later skb_put_u8().
Likely exposure
Exposure appears limited to Linux systems running affected kernel versions with the s3fwrn5/s3fwrn82 NFC UART driver in use. The source bundle does not identify affected distributions, hardware fleets, attacker prerequisites, or whether default configurations load this driver.
Exploitation context
No active exploitation is cited, and the CVE is not marked KEV. The public description indicates a reliability and kernel crash condition tied to NFC receive handling and allocation failure, but it does not provide exploitability details or attacker positioning.
Researcher notes
The key issue is receive_buf accounting after partial consumption and allocation failure. The fix direction is to allocate the receive skb before consuming the next byte and return the accepted byte count when allocation fails. Source evidence is limited to the CVE record and Linux stable commit references.
Mitigation direction
Update to a kernel build containing the referenced stable fixes.
Check your Linux distribution vendor advisory for patched package versions.
Disable or remove unused NFC s3fwrn5 driver support where acceptable.
Prioritize systems with NFC hardware or kernel modules enabled.
Monitor for kernel oops or crashes involving s3fwrn82_uart_read.
Validation and detection
Inventory Linux kernel versions against the CVE record and vendor advisories.
Confirm whether s3fwrn5 or related NFC UART support is built or loaded.
Verify the running kernel includes one of the referenced stable commits.
Review crash logs for NULL dereference traces in the NFC receive path.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43098 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
8Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 6, 2026, 07:40 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.