{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-49872 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-49872 is a high-severity vulnerability in Linux kernel, published on 1 May 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-49872 and fix it if it is affected.\n\nWhat it is: CVE-2022-49872 is a high-severity vulnerability in Linux kernel, published on 1 May 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-49872 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-2022-49872/ (Markdown: https://insights.sbomify.com/CVE-2022-49872/index.md)","id":"CVE-2022-49872","markdown":"https://insights.sbomify.com/CVE-2022-49872/index.md","name":"CVE-2022-49872","record":{"aliases":["DEBIAN-CVE-2022-49872","GHSA-v832-47wf-r9vp","UBUNTU-CVE-2022-49872"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A logic error in the Linux kernel network stack causes a kernel panic when processing fragmented packets with mixed allocation types, leading to denial of service.","user_interaction":"not_required","vuln_class":"null_dereference"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.5,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: fix panic on frag_list with mixed head alloc types\n\nSince commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when\nsplitting gso_size mangled skb having linear-headed frag_list\"), it is\nallowed to change gso_size of a GRO packet. However, that commit assumes\nthat \"checking the first list_skb member suffices; i.e if either of the\nlist_skb members have non head_frag head, then the first one has too\".\n\nIt turns out this assumption does not hold. We've seen BUG_ON being hit\nin skb_segment when skbs on the frag_list had differing head_frag with\nthe vmxnet3 driver. This happens because __netdev_alloc_skb and\n__napi_alloc_skb can return a skb that is page backed or kmalloced\ndepending on the requested size. As the result, the last small skb in\nthe GRO packet can be kmalloced.\n\nThere are three different locations where this can be fixed:\n\n(1) We could check head_frag in GRO and not allow GROing skbs with\n    different head_frag. However, that would lead to performance\n    regression on normal forward paths with unmodified gso_size, where\n    !head_frag in the last packet is not a problem.\n\n(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating\n    that NETIF_F_SG is undesirable. That would need to eat a bit in\n    sk_buff. Furthermore, that flag can be unset when all skbs on the\n    frag_list are page backed. To retain good performance,\n    bpf_skb_net_grow/shrink would have to walk the frag_list.\n\n(3) Walk the frag_list in skb_segment when determining whether\n    NETIF_F_SG should be cleared. This of course slows things down.\n\nThis patch implements (3). To limit the performance impact in\nskb_segment, the list is walked only for skbs with SKB_GSO_DODGY set\nthat have gso_size changed. Normal paths thus will not hit it.\n\nWe could check only the last skb but since we need to walk the whole\nlist anyway, let's stay on the safe side.","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":"net: gso: fix panic on frag_list with mixed head alloc types","id":"CVE-2022-49872","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"null_dereference","year":"2022"},"n_packages":0,"n_references":8,"next":{"headline":"bpf: Fix wrong reg type conversion in release_reference()","id":"CVE-2022-49873"},"packages":[],"prev":{"headline":"net: tun: Fix memory leaks of napi_get_frags","id":"CVE-2022-49871"},"products":["Linux"],"published":"2025-05-01","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":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A logic error in the Linux kernel network stack causes a kernel panic when processing fragmented packets with mixed allocation types, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2022-49872/"}