CVE-2026-45933

Home/CVE/In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve id of register in sync_linked_regs()

CVE

In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve id of register in sync_linked_regs()

In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve id of register in sync_linked_regs() copies the id of known_reg to reg when propagating bounds of known_reg to reg using the off of known_reg, but when known_reg was linked to reg like: known_reg = reg.

both known_reg and reg get same id known_reg += 4.

known_reg gets off = 4, and its id gets BPF_ADD_CONST now when a call to sync_linked_regs() happens, let's say with the following: if known_reg >= 10 goto pc+2 known_reg's new bounds are propagated to reg but now reg gets BPF_ADD_CONST from the copy. This means if another link to reg is created like: another_reg = reg.

another_reg should get the id of reg but assign_scalar_id_before_mov() sees BPF_ADD_CONST on reg and assigns a new id to it. As reg has a new id now, known_reg's link to reg is broken. If we find new bounds for known_reg, they will not be propagated to reg. This can be seen in the selftest added in the next commit: 0: (85) call bpf_get_prandom_u32#7.

R0=scalar() 1: (57) r0 &= 255.

R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0.

0xff)) 2: (bf) r1 = r0.

R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0.

0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0.

0xff)) 3: (07) r1 += 4.

R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0.

0x1ff)) 4: (a5) if r1 < 0xa goto pc+4.

R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0.

0x1ff)) 5: (bf) r2 = r0.

R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2.

R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0.

0x1ff)) 7: (35) if r0 >= 0xa goto pc+1.

R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0.

0xf)) 8: (37) r0 /= 0 div by zero When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPF_ADD_CONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken. After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero. Fix this by preserving id in sync_linked_regs() like off and subreg_def.

HIGH · CVSS 7.8 EPSS 0.00014

Schedule remediation

CVSS base score ≥ 7.0

Sigma rules0 YARA rules0

Look this up elsewhere - one-click external pivots

NVD CVE.org CISA Vulners Exploit-DB GitHub PoC VulnCheck KEV GreyNoise

▸ How to read a CVE - triage first, then detect and patch

This page is every public fact about CVE-2026-45933, cross-linked. Its job is to answer one question fast - does this need my attention now? - and then hand you the two things you do about it. Here is how an analyst reads it.

Triage: should I act now? Four signals, and they are not interchangeable:

CVSSseverity - how bad it is IF exploited, 0-10. A high CVSS alone is not urgency; a flaw can be a perfect 10 and never actually be attacked. EPSSprobability - a model’s estimate of the chance it is exploited in the next 30 days, 0-1. This is the “will it actually happen” signal. CISA KEVconfirmed - it is being exploited in the wild right now. The strongest signal on the page; KEV beats any score. Weaponisedavailability - public exploits / PoCs, and especially Metasploit modules rated Excellent / Great. Reliable, packaged exploit code means low-skill attackers can use it today.

How they combine: KEV, or a dependable Metasploit module, means patch now regardless of CVSS. High CVSS + low EPSS + no exploit is real but not an emergency - schedule it. Low CVSS but KEV-listed still gets patched now. The verdict above already weighed these for you; this is how it got there.

Then what - two workflows:

Detectwhen you cannot patch today, follow this CVE to the ATT&CK techniques it enables, then Build a SIEM detection (the green button) - author a rule, test it in Atomic, deploy it. That buys visibility while the patch waits. PatchAffected products / packages tell you if you are exposed; Fixed versions by distribution and Vendor advisories give the exact version that closes it.

Reading order for the panels below: verdict + badges, then Public exploits / Metasploit (is it weaponised), then ATT&CK techniques + Sigma / IDS rules (can I detect it), then Affected products / packages + Fixed versions (am I exposed, what patches it), then Threat actors / IOCs (who uses it), then Scoring & timeline / references (the evidence).

View attack path from CVE-2026-45933

◆

ATT&CK techniques

Techniques this CVE enables - linked via CWECAPECATT&CK. High◆ = named directly in ATT&CK or Nuclei templates.

T1068 · Exploitation for Privilege Escalation

▤ Build a SIEM detection for these techniques

📦

Fixed versions by distribution

The package version that resolves this CVE on each Linux distribution, from the vendor’s published security data. fixed in shows a patched version exists; open means the package is listed as affected with no fix yet.
suse sle15cluster-md-kmp-default open
suse sle15dlm-kmp-default open
suse sle15gfs2-kmp-default open
suse sle15kernel-default open
suse sle15kernel-default-base open
suse sle15kernel-default-devel open
suse sle15kernel-default-extra open
suse sle15kernel-default-livepatch open
suse sle15kernel-default-livepatch-devel open
suse sle15kernel-default-man open
suse sle15kernel-devel open
suse sle15kernel-devel-rt open
suse sle15kernel-macros open
suse sle15kernel-source open
suse sle15kernel-source-rt open
suse sle15ocfs2-kmp-default open
suse sle15reiserfs-kmp-default open

▣

Scoring & Timeline

7.8

HIGH · CVSS v3.1 · 416baaa9-dc9f-4396-8d5f-8c081fb06d67

View on NVD

Attack Vector

Network Adjacent Local Physical

Attack Complexity

Low High

Privileges Required

None Low High

User Interaction

None Required

Scope

Unchanged Changed

Confidentiality

None Low High

Integrity

None Low High

Availability

None Low High

Published to NVD27 May 2026 · 02:17 PM

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

🔗

References & Sources

Source URLs (vendor pages, mailing lists, write-ups). Exploit/PoC links are in their own section above to avoid duplication.

https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4

https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d

https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1

https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6