{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-99127 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-99127 is a vulnerability in Linux, published on 28 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-99127 and fix it if it is affected.\n\nWhat it is: CVE-2026-99127 is a vulnerability in Linux, published on 28 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-99127 in the wild and no public exploit code.\n\nAffected product: Linux. 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-99127/ (Markdown: https://insights.sbomify.com/CVE-2026-99127/index.md)","id":"CVE-2026-99127","markdown":"https://insights.sbomify.com/CVE-2026-99127/index.md","name":"CVE-2026-99127","record":{"aliases":["AZL-111236","BELL-CVE-2026-99127","DEBIAN-CVE-2026-99127","GHSA-4j2x-r727-jfq6","UBUNTU-CVE-2026-99127"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: keep frag_offset aligned for odd-sized requests\n\npage_pool_alloc_frag_netmem() rounds the requested fragment size with\n\n\tsize = ALIGN(size, dma_get_cache_alignment());\n\ndma_get_cache_alignment() returns 1 unless the architecture defines\nARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not.\nThere the ALIGN() is a no-op and pool-\u003efrag_offset advances by the raw,\nunrounded size.\n\nA single caller asking for an odd size then leaves frag_offset misaligned\nfor every fragment carved out of that page afterwards.  The pool is shared,\nso the damage is not confined to the caller that caused it.\n\nThe per-cpu system_page_pool used by generic XDP hits this.\nskb_pp_cow_data() allocates its fragments with the raw packet length:\n\n\tsize = min_t(u32, len, PAGE_SIZE);\n\ttruesize = size;\n\tpage = page_pool_dev_alloc(pool, \u0026page_off, \u0026truesize);\n\nleaving frag_offset odd for whatever is carved out of that page next.  Its\nown head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the\nXDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared\npool that pays: page_pool_dev_alloc_va() returns a misaligned buffer,\nnapi_build_skb() installs it as skb-\u003ehead, and skb_shinfo(skb) ==\nskb-\u003ehead + skb-\u003eend is misaligned with it.\n\nskb_shinfo()-\u003edataref is a 4-byte atomic_t at offset 0x20, so the\natomic_inc() in __skb_clone() straddles a cache line.  On x86 with split\nlock detection -- fatal for kernel split locks by default -- this panics\nthe machine:\n\n  Oops: Split lock detected\n  RIP: 0010:skb_clone+0x154/0x1e0\n  Call Trace:\n   \u003cIRQ\u003e\n   raw_local_deliver+0x1ed/0x2c0\n   ip_protocol_deliver_rcu+0x54/0x1c0\n   ip_local_deliver_finish+0x85/0x100\n   ip_local_deliver+0x67/0x100\n   __netif_receive_skb_one_core+0x85/0xa0\n   process_backlog+0x87/0x130\n\nReproduced by attaching any generic-mode XDP program to loopback and\nopening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone\nevery locally delivered UDP packet; ordinary DNS traffic then triggers it,\nroughly once per 2500 clones.  Observed on 6.12.101 and 7.1.8.\n\nTracing page_pool_alloc_frag_netmem() over one such run shows the\namplification -- two odd-sized requests, nine misaligned offsets:\n\n  requested size \u0026 7:   0: 17035    5: 1    7: 1\n  frag_offset \u0026 7:      0: 17028    3: 1    4: 1    5: 1    6: 1    7: 5\n\nand skb_pp_cow_data() returning heads that were aligned on entry:\n\n  head 0xffff8f4c86aeac00 -\u003e 0xffff8f4c53a9a9c4 (\u00267=4)\n  head 0xffff8f4d6a8a42c0 -\u003e 0xffff8f4c4f7b7a45 (\u00267=5)\n\nRound the fragment size up to at least the alignment struct skb_shared_info\nrequires, so fragments are always suitably aligned for the objects callers\nbuild on them.  Architectures needing a larger DMA alignment keep it.\n\nThis also makes the remainder computed in page_pool_alloc_netmem(),\n\n\t*size = max_size - *offset;\n\naligned, since max_size is a power of two -- which fixes the matching\nmisalignment of skb-\u003eend.\n\nVerified with a controlled A/B under QEMU/KVM: same tree, same config,\nsame compiler, same rootfs and identical traffic, differing only by this\npatch.  A SEC(\"xdp.frags\") XDP_PASS program on lo plus UDP datagrams\nlarger than max_head_size drives skb_pp_cow_data()'s fragment loop, which\npasses raw packet lengths to the pool.  Measured at the return of\nskb_pp_cow_data():\n\n                          unpatched   patched\n  skb_pp_cow_data calls       40800     40800\n  misaligned skb-\u003ehead         1120         0\n  dataref at line offset \u003e60     80         0\n\nThe last row counts the accesses that actually fault:\nskb_shinfo()-\u003edataref sits at head+end+0x20 and is a 4-byte atomic, so\n`lock incl` splits a 64-byte cache line only when that address lands at\noffset 61..63.  All 80 occurrences were at offset 61; the panic reported\nabove was at offset 62.  Eliminating the misalignment removes every one\nof them.\n\nSame class of bug as commit 3bed3cc4156e (\"net: Do not allocate page\nfragments t\n---truncated---","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":"page_pool: keep frag_offset aligned for odd-sized requests","id":"CVE-2026-99127","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"sctp: validate chunk length in the inqueue parser","id":"CVE-2026-99128"},"packages":[],"prev":{"headline":"s390/ctcm: Prevent XID null dereference","id":"CVE-2026-99126"},"products":["Linux"],"published":"2026-10-28","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-28","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-99127/"}