CVE-2026-98158: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-98158 is a kernel panic / denial-of-service vulnerability in the Linux kernel's ppp_async driver caused by improper socket buffer (skb) headroom management when processing malformed PPP frames. When a frame with a bad Frame Check Sequence (FCS) is received, the error-recovery path incorrectly zeroes the reused skb's headroom instead of restoring it to the NET_SKB_PAD value provided by dev_alloc_skb(). A subsequent frame beginning with bytes 0xff 0x03 is then reassembled into this zero-headroom buffer; when ppp_receive_nonmp_frame() attempts to prepend a two-byte BPF filter direction tag via skb_push(), it writes one byte below skb->head, triggering a kernel BUG/panic. The vulnerability has been present since Linux 2.6.15 and is fixed in stable releases 6.12.111, 6.18.53, 7.2.7, and 7.3-rc3. A CVSS category estimate of Medium has been assigned (GitHub Advisory, Feedly).

The root cause is an out-of-bounds write (analogous to CWE-787 / CWE-119) in process_input_packet() within drivers/net/ppp/ppp_async.c. The error path executes skb_reserve(skb, -skb_headroom(skb)) to "reset" a reused skb, but this sets headroom to zero rather than the NET_SKB_PAD bytes that dev_alloc_skb() normally provides. Because ap->rpkt still references this skb, the next incoming frame is reassembled into it with no headroom. When ppp_receive_nonmp_frame() later calls skb_push(skb, 2) to prepend the PPP_FILTER_INBOUND_TAG, the push lands below skb->head, triggering skb_under_panic and a fatal kernel BUG at net/core/skbuff.c:214. A secondary impact exists when CCP compression is active: ppp_decompress_frame() passes skb->data - 2 to the decompressor, causing an out-of-bounds read before skb->head. The vulnerability was discovered through fuzzing the PPP receive path with a mutating peer on a pty; a reproducer (repro-ppp-skb.c) panics the kernel in approximately one second (GitHub Advisory).

Successful exploitation results in a kernel panic and immediate system crash (denial of service). An attacker capable of sending two specially crafted PPP frames — first a bad-FCS frame, then a frame beginning with 0xff 0x03 — can reliably crash the target kernel. When CCP compression is enabled, the same headroom deficiency also causes an out-of-bounds read in the decompressor, potentially exposing kernel memory contents. There is no evidence of privilege escalation or remote code execution impact at this time (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation as of the disclosure date (September 25, 2026). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack requires the ability to send PPP frames to an affected system — achievable remotely by a peer on a PPP link (e.g., DSL, VPN, or serial PPP connection) or locally by a user with access to a PPP interface. The EPSS score has not been published yet. The Feedly CVSS category estimate is Medium (GitHub Advisory, Feedly).

1. Identify a target: Locate a Linux system running a kernel version from 2.6.15 up to (but not including) the patched stable releases (6.12.111, 6.18.53, 7.2.7, or 7.3-rc3) with an active PPP async interface (e.g., a DSL modem, serial PPP link, or PPP-over-pty).
2. Establish PPP peer access: Position yourself as the PPP peer — either as a remote endpoint on the same PPP link or locally via a pty-based PPP session — so that you can inject raw PPP frames to the target.
3. Send a bad-FCS frame: Transmit a PPP frame with a deliberately corrupted Frame Check Sequence. This triggers the error path in process_input_packet(), which zeroes the reused skb's headroom and leaves ap->rpkt pointing to the zero-headroom buffer.
4. Send the trigger frame: Immediately send a second PPP frame whose payload begins with bytes 0xff 0x03 (the PPP All-Stations/UI header). This frame is reassembled into the zero-headroom skb.
5. Trigger the panic: When the kernel calls ppp_receive_nonmp_frame() on the reassembled frame, skb_push(skb, 2) writes the BPF filter direction tag one byte below skb->head, triggering skb_under_panic and a fatal kernel BUG, crashing the system (GitHub Advisory).

• Kernel Logs / dmesg: Messages containing skbuff: skb_under_panic with put:2 and a negative data pointer offset; kernel BUG at net/core/skbuff.c:214!; call trace including skb_push, ppp_receive_nonmp_frame, ppp_input, ppp_async_process, tasklet_action_common, handle_softirqs; Kernel panic - not syncing: Fatal exception in interrupt.
• Network: Unexpected PPP frames with bad FCS values arriving on a PPP async interface, particularly followed immediately by frames beginning with bytes 0xff 0x03; unusual peer behavior on PPP links (rapid frame injection).
• System: Sudden, unexplained system reboots or kernel panics on hosts with active PPP async interfaces; crash dump files (vmcore) referencing ppp_async or ppp_receive_nonmp_frame in the stack trace (GitHub Advisory).

Apply the upstream kernel fix, which changes the error path in ppp_async to drop the errored frame and clear ap->rpkt (so the next frame is reassembled into a fresh skb with proper headroom) rather than attempting to reset the reused skb's headroom. Patched stable versions are 6.12.111, 6.18.53, 7.2.7, and 7.3-rc3 (commit IDs: d0fc3dabfe67, 0c53eb14975f, 717137221c7d, 8dc5d98a16fa). As a workaround where upgrading is not immediately possible: disable or remove the ppp_async kernel module (rmmod ppp_async) if async PPP interfaces are not required; implement network-level filtering to block untrusted PPP traffic from reaching affected systems; and prefer ppp_synctty (which already handles errors correctly) where applicable (GitHub Advisory, Feedly).

The vulnerability was announced via the Linux kernel CVE mailing list (linux-cve-announce) on September 25, 2026, and was picked up by standard CVE aggregators (cvefeed.io, vuldb.com, INCIBE-CERT) shortly after. A Reddit post in r/pwnhub included it in a daily CVE brief. No notable independent researcher commentary or significant media coverage beyond routine CVE tracking has been observed (Kernel Announce, INCIBE-CERT).