dbcve.org
Linux KernelOperating system · Linux

CVE-2026-53036

HIGH · 7.8 CVSS v3.1 Published 2026-06-24
Fix available
A fix is available. Upgrade to 6.1.175 / 6.6.141 or later.
See remediation →
80/100
Remediation priority · High
Zero-click Patch available 8 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix off-by-one in check_imm signed range check check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

The arm64 BPF JIT compiler has an off-by-one error in the check_imm macro used to validate branch displacements. The current check admits values in [-2^N, 2^N) but a signed N-bit field only holds [-2^(N-1), 2^(N-1)). For check_imm19(), values in [2^18, 2^19) slip through but cannot be properly encoded, causing the sign bit to flip and forward branches to become backward branches.

MitigationApply the upstream kernel patch which changes the shift from 'bits' to 'bits-1' in the check_imm macro. Update to a kernel version containing this fix.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 3.18, < 6.1.175>= 6.2, < 6.6.141>= 6.7, < 6.12.91>= 6.13, < 6.18.33>= 6.19, < 7.0.10

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Verify system is ARM64 architecture
    Run 'uname -m' or 'arch' command - look for 'aarch64' or 'arm64'
    Affected if Architecture is not aarch64/arm64 - the flaw only affects ARM64 BPF JIT
  2. Confirm BPF JIT is enabled for ARM64
    Check kernel config for CONFIG_BPF_JIT=y and CONFIG_ARCH_HAS_BPF_JIT, or check /proc/sys/net/core/bpf_jit_enable (value should be 1 or 2)
    Affected if BPF JIT is not enabled (value is 0) - the compiler component with the flaw is not active
  3. Check installed kernel version against affected ranges
    Run 'uname -r' or check /proc/version, then compare to: >= 3.18 < 6.1.175, >= 6.2 < 6.6.141, >= 6.7 < 6.12.91, >= 6.13 < 6.18.33, >= 6.19 < 7.0.10
    Affected if Kernel version falls within any of the listed affected ranges - the vulnerable check_imm macro is present
  4. Identify BPF programs using large immediate values on ARM64
    Review BPF programs loaded on the system (via bpftool or /proc/kallsyms for JITted programs) that use immediate values in range [2^18, 2^19) such as 262144-524287 for check_imm19, or [2^20, 2^21) for check_imm26
    Affected if Large immediate values (between 262144-524287 for 19-bit, or 1048576-2097151 for 26-bit fields) are used in BPF programs on affected kernels - these could be incorrectly encoded

A user is affected if they are running an ARM64 system with BPF JIT enabled and a kernel version within the affected ranges, especially if they load BPF programs with large immediate values in the vulnerable ranges.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 6.1.175 / 6.6.141 / 6.12.91 or later
Fixed in 6.1.1756.6.1416.12.91
Vendor patch git.kernel.org →
Interim mitigation

Apply the upstream kernel patch which changes the shift from 'bits' to 'bits-1' in the check_imm macro. Update to a kernel version containing this fix.

Recommended fix High confidence

Linux kernel 6.1.175, 6.6.141, 6.12.91, or 6.18.33 (select based on your current stable branch)

  1. Identify the currently running Linux kernel version using 'uname -r' or 'cat /proc/version'
  2. Determine if the version falls within affected ranges: >= 3.18 and < 6.1.175, >= 6.2 and < 6.6.141, >= 6.7 and < 6.12.91, or >= 6.13 and < 6.18.33
  3. If affected, schedule a maintenance window for the kernel upgrade
  4. Upgrade to a fixed kernel version: 6.1.175 or later for the 6.1.y branch, 6.6.141 or later for the 6.6.y branch, 6.12.91 or later for the 6.12.y branch, or 6.18.33 or later for the 6.13.y+ branches
  5. Reboot the system to load the patched kernel
  6. Verify the fix is applied by checking 'uname -r' shows a version >= the appropriate fixed release
Caveat Kernel upgrade may require rebuilding out-of-tree kernel modules; verify driver compatibility with the new kernel version before upgrading

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Linux Kernel Scoped from the published advisory
  • Consultation1.0 h
  • Implementation1.0 h
  • Testing4.0 h
  • Review / QA2.0 h
8.0 hours of engineering $1,340
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,144.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-53036 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-53036 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data