CVE-2026-45933: bpf: Preserve id of register in sync_linked_regs()

Published May 27, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

bpf: Preserve id of register in synclinkedregs()

synclinkedregs() copies the id of knownreg to reg when propagating bounds of knownreg to reg using the off of knownreg, but when knownreg was linked to reg like:

knownreg = reg ; both knownreg and reg get same id knownreg += 4 ; knownreg gets off = 4, and its id gets BPFADDCONST

now when a call to synclinkedregs() happens, let's say with the following:

if knownreg >= 10 goto pc+2

knownreg's new bounds are propagated to reg but now reg gets BPFADDCONST from the copy.

This means if another link to reg is created like:

anotherreg = reg ; anotherreg should get the id of reg but assignscalaridbeforemov() sees BPFADDCONST on reg and assigns a new id to it.

As reg has a new id now, knownreg's link to reg is broken. If we find new bounds for knownreg, they will not be propagated to reg.

This can be seen in the selftest added in the next commit:

0: (85) call bpfgetprandomu32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,varoff=(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,varoff=(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,varoff=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,varoff=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero

When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPFADDCONST (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 synclinkedregs() like off and subregdef.

Affected Software

4 affected components
Linux Linux kernel
Linux Linux kernel>=6.11<6.12.75
Linux Linux kernel>=6.13<6.18.14
Linux Linux kernel>=6.19<6.19.4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Patch the kernel so sync_linked_regs() preserves the scalar ID when syncing linked registers (similar to how off/subreg_def preserve IDs). This prevents the verifier from losing the correct bounds/ID relationship and avoids the div-by-zero path.

    Linux kernel eBPF verifier (register linked-reg ID handling) Preserve register scalar ID in sync_linked_regs() = enabled

Event History

May 27, 2026
CVE Published
via MITRE·12:17 PM
Data Sourced
via MITRE·12:17 PM
DescriptionSeverity
Data Sourced
via NVD·02:17 PM
RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Systems running the Linux kernel are in scope. The issue is in BPF verifier register-state handling, so exposure is tied to the ability to load and verify affected BPF programs.

2

What level of access does an attacker need?

The supplied CVSS vector indicates local access, low attack complexity, low privileges required, and no user interaction. It does not describe a remote attack path.

3

What is the security impact?

The supplied severity information rates the issue high at 7.8, with high confidentiality, integrity, and availability impact in the CVSS vector. The described flaw can break propagation of register bounds after linked register IDs are handled incorrectly.

4

Are fixed versions identified?

No specific fixed kernel versions are provided. The listed stable-kernel references contain the relevant fixes, but the supplied data does not map those commits to release versions.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203