{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-98158 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98158 is a medium-severity memory corruption vulnerability in Linux kernel, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98158 and fix it if it is affected.\n\nWhat it is: CVE-2026-98158 is a medium-severity memory corruption vulnerability in Linux kernel, published on 25 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98158 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98158/ (Markdown: https://insights.sbomify.com/CVE-2026-98158/index.md)","id":"CVE-2026-98158","markdown":"https://insights.sbomify.com/CVE-2026-98158/index.md","name":"CVE-2026-98158","record":{"aliases":["AZL-104685","BELL-CVE-2026-98158","DEBIAN-CVE-2026-98158","GHSA-qfj9-3jj2-w6g8","UBUNTU-CVE-2026-98158"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel PPP","requires_auth":"low_privilege","summary":"A remote attacker can cause a kernel panic and denial of service by sending malformed PPP frames that trigger an out-of-bounds memory access.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-125","name":"Out-of-bounds Read"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nppp_async: drop the errored frame instead of resetting its headroom\n\nppp_receive_nonmp_frame() prepends a two-byte direction tag before running\nthe pass/active BPF filters:\n\n\t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG);\n\nNothing on the receive path guarantees those two bytes of headroom. The\nframe-error path in ppp_async's process_input_packet() resets a reused skb's\nheadroom to zero while claiming to restore it to a freshly allocated state -\nbut a fresh skb from dev_alloc_skb() carries NET_SKB_PAD:\n\n\terr:\n\t\tif (skb) {\n\t\t\t/* make skb appear as freshly allocated */\n\t\t\tskb_trim(skb, 0);\n\t\t\tskb_reserve(skb, - skb_headroom(skb));\n\t\t}\n\nap-\u003erpkt still points at that skb, so the next frame is reassembled into it\nwith no headroom at all. A peer that sends a bad-FCS frame followed by one\nbeginning ff 03 then leaves a single byte of headroom by the time the filter\ntag is pushed, which lands one byte below skb-\u003ehead:\n\n  skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000\n          data:ffff888003c0ffff tail:0x30 end:0x640 dev:\u003cNULL\u003e\n  kernel BUG at net/core/skbuff.c:214!\n  RIP: 0010:skb_panic+0x13e/0x230\n  Call Trace:\n   skb_push+0xbd/0x100\n   ppp_receive_nonmp_frame+0x48a/0x1d10\n   ppp_input+0x4e9/0x2f80\n   ppp_async_process+0x2a/0xe0\n   tasklet_action_common+0x20f/0x8a0\n   handle_softirqs+0x18e/0x590\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nZeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb()\ngives the rest of the receive path. Besides the filter panic above, when CCP\ncompression is enabled ppp_decompress_frame() hands skb-\u003edata - 2 to\n-\u003edecompress()/-\u003eincomp(), which then reads out of bounds before skb-\u003ehead\nfor the same reason.\n\nRather than restore the headroom, drop the errored frame - as ppp_synctty\nalready does on its error path - and clear ap-\u003erpkt so the next frame is\nreassembled into a fresh skb with proper headroom. This is simpler and fixes\nboth the filter under-panic and the CCP out-of-bounds read.\n\nThe original V1 of this patch made room in ppp_receive_nonmp_frame() with\nskb_cow_head(); Eric pointed out that fixing the root cause in the transport\nis the right approach.\n\nFound by fuzzing the PPP receive path with a mutating peer on a pty; it is an\ninteresting (remote) DoS: root configures PPP, the peer supplies two crashing\nframes. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a\nsecond, and returns cleanly with this applied.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"ppp_async: drop the errored frame instead of resetting its headroom","id":"CVE-2026-98158","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"wifi: mt76: mt7921: validate CLC firmware records","id":"CVE-2026-98159"},"packages":[],"prev":{"headline":"EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation","id":"CVE-2026-98157"},"products":["Linux"],"published":"2026-09-25","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A remote attacker can cause a kernel panic and denial of service by sending malformed PPP frames that trigger an out-of-bounds memory access.","url":"https://insights.sbomify.com/CVE-2026-98158/"}