CVE-2026-31525Patch(linux / linux_kernel)

LOWCVSS 7.8 · HIGH

Exploit discussion active in current signal (1 latest mentions)

Immediate actions

  • Patch linux linux_kernel systems immediately
  • Hunt for exploitation attempts and persistence artifacts

Recommended action window: High priority (within 72h)

NVD description

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32_MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result. The verifier's abstract interpretation (scalar32_min_max_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access. Introduce abs_s32() which handles S32_MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers. s32 is the only affected case -- the s64 division/modulo handlers do not use abs().

2.5/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-787

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

AVAILABLE

Momentum

STABLE

Are you affected?

If you run products in this scope, you should treat this CVE as relevant to your environment.

  • linux_kernel

Threat summary

  • Exploit tooling references are present in monitored signal
  • Patch or workaround signal is available
  • 6 mentions across 4 observed days
  • Momentum state: stable

What's happening

  • Exploit tool or code specified in 1 signal
  • Patch or workaround mentioned in 3 signals
  • Technical details provided in 5 signals
  • General: 2 classified signals
  • Disclosure: 1 classified signal
  • Peaked 3d ago at 2 mentions (2026-04-22); latest day: 1
  • 6 total mentions across 4 days

Affected systems

Vendors
Products
linux_kernel

1 version affected across 1 product

Deep dive

Activity timeline6 mentions / 4d
01122Mentions · 2026-04-22: 2Mentions · 2026-05-30: 2Mentions · 2026-05-31: 1Mentions · 2026-06-01: 1Exploit Tool / Code · 2026-05-30: 1Patch / Workaround · 2026-04-22: 1Patch / Workaround · 2026-05-30: 2Technical Details · 2026-04-22: 2Technical Details · 2026-05-30: 2Technical Details · 2026-05-31: 104-2205-3005-3106-01
Signal classification3 categories
Patch
350.0%
General
233.3%
Disclosure
116.7%
Referenced assets9 URLs
Classification over time
DateTotalLabels
2026-04-222
Disclosure1Patch1
2026-05-302
Patch2
2026-05-311
General1
2026-06-011
General1
Full discourse6 posts
  • Jenny Qu@GuanniQu
    Patch

    found a verifier/interpreter mismatch in the Linux BPF subsystem (CVE-2026-31525, CVSS 7.8). arbitrary kernel read/write; become root, escape containers, disable SELinux, read TLS keys out of other processes' memory. anyway, it starts with the math bars, the absolute value. computers store negative numbers in two's complement. the smallest 32-bit signed integer is -2,147,483,648, and the largest positive is +2,147,483,647. there is no +2,147,483,648, since it simply does not fit. so when you call abs(-2,147,483,648), the C specification thinks about it for a moment, says "undefined," and leaves the room. on x86 and arm64, what you actually get back is -2,147,483,648. you asked for the absolute value of a negative number, you got back the same negative number. thank you computer :D the BPF interpreter implements signed 32-bit division (BPF_ALU | BPF_DIV/MOD, off == 1, added in ec0e2da95f72) by decomposing it into unsigned division: take abs() of both operands, divide via do_div(), reapply the sign. the handler in ___bpf_prog_run (kernel/bpf/core.c): AX = abs((s32)DST); AX = do_div(AX, abs((s32)SRC)); and look, the kernel even documents this. include/linux/math.h: "the return value is undefined when the input is the minimum value of the type." when DST = 0x80000000 (S32_MIN), abs() tries to negate it. -(-2,147,483,648) overflows s32, the C spec calls it undefined behavior, and the CPU hands back 0x80000000 unchanged. still negative. abs() had one job. this s32 then gets assigned into AX, a u64 BPF register. s32 → u64 sign-extends: 0x80000000 becomes 0xFFFFFFFF80000000. that's 18,446,744,071,562,067,968. you wanted 2,147,483,648, you got 18.4 quintillion; a rounding error of about 18.4 quintillion. do_div() is a 64-by-32-bit unsigned division macro and it operates on this full u64 numerator. the quotient is off by a factor of 2³². the smod path has the same problem since do_div() modifies the dividend in place and returns the remainder, both wrong. 8 call sites across sdiv32/smod32 src/imm handlers, all quietly producing nonsense whenever S32_MIN shows up. the BPF verifier is the safety system that statically analyzes every BPF program before allowing it to run. it exists specifically to guarantee that nothing bad can happen. scalar32_min_max_sdiv() in kernel/bpf/verifier.c tracks value ranges through abstract interpretation. it handles signed division correctly, including S32_MIN. computes tight, mathematically correct bounds. the interpreter, as we've established, computes whatever it feels like. so the verifier thinks register R0 is in range X. the interpreter puts value Y in R0. the safety system and the execution engine disagree about what a program does. in BPF security research, this is where you set down your coffee. concretely: load S32_MIN into R1, load 2 into R2, execute SDIV32 R1 R2. verifier determines R1 ∈ [-1,073,741,824, -1,073,741,824]. interpreter computes do_div(0xFFFFFFFF80000000, 2) = 0x7FFFFFFFC0000000, reapplies the sign, produces a completely unrelated value. use R1 as an index into a BPF map. verifier approves the access, bounds check passes against its calculated range. interpreter uses the actual value. out-of-bounds read/write on a kernel data structure. on every Linux machine running the BPF interpreter. the root cause of all of this: the absolute value function doesn't handle one number. one specific number, out of 4.2 billion possible inputs, and it's the one that gives you kernel read/write. the fix is: c static u32 abs_s32(s32 x) { return x >= 0 ? (u32)x : -(u32)x; } cast to u32 before negating. -(u32)0x80000000 = 0x80000000 unsigned. correct absolute value, no overflow, no undefined behavior. the kind of function you'd assume already exists somewhere in 30 million lines of kernel code. it did not. I got to write it. :D I reported this, wrote the patch, got it through 5 revisions of review. acked by Yonghong Song and Mykyta Yatsenko. now patched in stable 6.6, 6.12, 6.18, 6.19. if you haven't updated your kernel: maybe do that.

    Post summary

    The post discloses CVE‑2026‑31525, explaining how a verifier/interpreter mismatch in the Linux BPF subsystem allows kernel read/write and root escalation, and provides a patch for affected kernels.

    8551036718463.9K
    2.2K followersView on X
  • Jenny Qu@GuanniQu
    Patch

    CVE-2026-31525 | CVSS 7.8 patch: https://lore.kernel.org/bpf/20260311011116.2108005-2-qguanni@gmail.com/ mainline: https://github.com/torvalds/linux/commit/c77b30bd1dcb61f66c640ff7d2757816210c7cb0 buggy commit: https://github.com/torvalds/linux/commit/ec0e2da95f72 writeup: https://www.sentinelone.com/vulnerability-database/cve-2026-31525/

    Post summary

    CVE-2026-31525 is addressed by a publicly available patch and mainline commits; no PoC or active exploitation is reported.

    12034203.3K
    2.2K followersView on X
  • OS開発者@hacker_infra
    General

    https://access.redhat.com/security/cve/cve-2026-31525 RHEL系は10 だけが影響を受ける。しかも、Fix deferred 緊急性はないのだろう。 https://ubuntu.com/security/CVE-2026-31525 ubuntuもmediumだからそれほどでもなさそう

    Post summary

    The post references Red Hat and Ubuntu advisories for CVE‑2026‑31525, noting that only RHEL 10 is affected with a deferred fix and that the Ubuntu severity is medium, but provides no evidence of PoC, exploit, or active attacks.

    03033942
    2.8K followersView on X
  • CVETrends@CVEShield
    General

    Top 5 Trending CVEs: 1 - CVE-2026-45585 2 - CVE-2025-36911 3 - CVE-2026-31525 4 - CVE-2026-0257 5 - CVE-2026-28910 #cve #cvetrends #cveshield #cybersecurity https://www.cveshield.com/dashboard

    Post summary

    The post merely lists a set of trending CVE identifiers and provides a link to a dashboard, lacking detailed or actionable information.

    00011154
    1.7K followersView on X
  • Vulmon Vulnerability Feed@VulmonFeeds
    Disclosure

    CVE-2026-31525 Undefined Behavior in Linux Kernel BPF Interpreter sdiv/smod for INT_MIN https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-31525

    Post summary

    The post announces CVE-2026-31525, describing an undefined behavior in the Linux kernel BPF interpreter related to INT_MIN operations.

    0000179
    4.0K followersView on X
  • CVE@CVEnew
    Patch

    CVE-2026-31525 In the Linux kernel, the following vulnerability has been resolved: bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN The BPF interpreter's signed 32… https://www.cve.org/CVERecord?id=CVE-2026-31525

    Post summary

    CVE-2026-31525 has been fixed in the Linux kernel; the issue involved undefined behavior in the BPF interpreter’s signed division/mod for INT_MIN.

    0000078
    57.2K followersView on X
CPE platform detail5 entries

5 of 5 entries

PartVendorProductVersionTarget SWTarget HW
OSlinuxlinux_kernel---
OSlinuxlinux_kernel7.0--
OSlinuxlinux_kernel7.0--
OSlinuxlinux_kernel7.0--
OSlinuxlinux_kernel7.0--

Explore more