{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2025-22059 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-22059 is a high-severity vulnerability in Linux kernel, published on 16 Apr 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-2025-22059 and fix it if it is affected.\n\nWhat it is: CVE-2025-22059 is a high-severity vulnerability in Linux kernel, published on 16 Apr 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-2025-22059 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-2025-22059/ (Markdown: https://insights.sbomify.com/CVE-2025-22059/index.md)","id":"CVE-2025-22059","markdown":"https://insights.sbomify.com/CVE-2025-22059/index.md","name":"CVE-2025-22059","record":{"aliases":["BELL-CVE-2025-22059","DEBIAN-CVE-2025-22059","GHSA-h26m-qmpx-mvhh","UBUNTU-CVE-2025-22059"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":true,"product_category":"Linux kernel UDP","requires_auth":"none","summary":"Integer overflow in Linux kernel UDP handling allows memory exhaustion and denial of service when specific socket buffer limits are configured.","user_interaction":"not_required","vuln_class":"integer_overflow"},"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":[{"id":"CWE-190","name":"Integer Overflow or Wraparound"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.\n\n__udp_enqueue_schedule_skb() has the following condition:\n\n  if (atomic_read(\u0026sk-\u003esk_rmem_alloc) \u003e sk-\u003esk_rcvbuf)\n          goto drop;\n\nsk-\u003esk_rcvbuf is initialised by net.core.rmem_default and later can\nbe configured by SO_RCVBUF, which is limited by net.core.rmem_max,\nor SO_RCVBUFFORCE.\n\nIf we set INT_MAX to sk-\u003esk_rcvbuf, the condition is always false\nas sk-\u003esk_rmem_alloc is also signed int.\n\nThen, the size of the incoming skb is added to sk-\u003esk_rmem_alloc\nunconditionally.\n\nThis results in integer overflow (possibly multiple times) on\nsk-\u003esk_rmem_alloc and allows a single socket to have skb up to\nnet.core.udp_mem[1].\n\nFor example, if we set a large value to udp_mem[1] and INT_MAX to\nsk-\u003esk_rcvbuf and flood packets to the socket, we can see multiple\noverflows:\n\n  # cat /proc/net/sockstat | grep UDP:\n  UDP: inuse 3 mem 7956736  \u003c-- (7956736 \u003c\u003c 12) bytes \u003e INT_MAX * 15\n                                             ^- PAGE_SHIFT\n  # ss -uam\n  State  Recv-Q      ...\n  UNCONN -1757018048 ...    \u003c-- flipping the sign repeatedly\n         skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)\n\nPreviously, we had a boundary check for INT_MAX, which was removed by\ncommit 6a1f12dd85a8 (\"udp: relax atomic operation on sk-\u003esk_rmem_alloc\").\n\nA complete fix would be to revert it and cap the right operand by\nINT_MAX:\n\n  rmem = atomic_add_return(size, \u0026sk-\u003esk_rmem_alloc);\n  if (rmem \u003e min(size + (unsigned int)sk-\u003esk_rcvbuf, INT_MAX))\n          goto uncharge_drop;\n\nbut we do not want to add the expensive atomic_add_return() back just\nfor the corner case.\n\nCasting rmem to unsigned int prevents multiple wraparounds, but we still\nallow a single wraparound.\n\n  # cat /proc/net/sockstat | grep UDP:\n  UDP: inuse 3 mem 524288  \u003c-- (INT_MAX + 1) \u003e\u003e 12\n\n  # ss -uam\n  State  Recv-Q      ...\n  UNCONN -2147482816 ...   \u003c-- INT_MAX + 831 bytes\n         skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)\n\nSo, let's define rmem and rcvbuf as unsigned int and check skb-\u003etruesize\nonly when rcvbuf is large enough to lower the overflow possibility.\n\nNote that we still have a small chance to see overflow if multiple skbs\nto the same socket are processed on different core at the same time and\neach size does not exceed the limit but the total size does.\n\nNote also that we must ignore skb-\u003etruesize for a small buffer as\nexplained in commit 363dc73acacb (\"udp: be less conservative with\nsock rmem accounting\").","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":"udp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.","id":"CVE-2025-22059","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"integer_overflow","year":"2025"},"n_packages":0,"n_references":4,"next":{"headline":"net: mvpp2: Prevent parser TCAM memory corruption","id":"CVE-2025-22060"},"packages":[],"prev":{"headline":"udp: Fix memory accounting leak.","id":"CVE-2025-22058"},"products":["Linux"],"published":"2025-04-16","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":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"Integer overflow in Linux kernel UDP handling allows memory exhaustion and denial of service when specific socket buffer limits are configured.","url":"https://insights.sbomify.com/CVE-2025-22059/"}