← Vulnerability feed

Vulnerability record · CVE-2026-45933 · published 27 May 2026

CVE-2026-45933: Linux kernel vulnerability

Linux · Linux Kernel

In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve id of register in sync_linked_regs() 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.

7.8 CVSS 3.1 High EPSS 0.18% · top 92.8% Undergoing Analysis
7.8CVSS 3.1 base score
0.18%EPSS exploitation probability, 30 days
NoNot in CISA KEV
1Affected product versions listed by NVD
4References
24 Jun 2026Last modified by NVD

Description

In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve id of register in sync_linked_regs() 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.

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

Affected products

1 vulnerable configurations from NVD's CPE data, grouped by vendor and product.

References

LinkTags
https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4 Patch
https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d Patch
https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1 Patch
https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6 Patch

Track CVE-2026-45933 inside VULONE

Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.

Start free Open in platform

Related vulnerabilities

Same products first, then exploited flaws of the same weakness class.

9.8CVE-2025-39682Linux kernel TLS zero-length record handling flaw on rx_listThe Linux kernel TLS receive path mishandles zero-length records that arrive from the rx_list, breaking the assumption that a record type change cann…KEVEPSS 2.9%analysed8.8CVE-2026-53266Linux kernel ebtables SNAT out-of-bounds write in ARP rewriteThe ebtables SNAT target rewrites the ARP sender hardware address via skb_store_bits() without first making that range writable. When the ARP SHA byt…KEVEPSS 0.65%analysed8.8CVE-2023-3079Google Chrome V8 type confusion enables heap corruptionCVE-2023-3079 is a type confusion flaw in the V8 JavaScript engine in Google Chrome before 114.0.5735.110. A crafted HTML page can trigger the confus…KEVEPSS 32%analysed8.8CVE-2013-6282Linux kernel ARM get_user/put_user missing address validationThe get_user and put_user API functions in the Linux kernel before 3.5.5 on v6k and v7 ARM platforms fail to validate certain addresses, allowing cra…KEVEPSS 40%analysed8.4CVE-2022-0185Linux Kernel Filesystem Context Heap Buffer OverflowThe legacy_parse_param function in the Linux kernel's Filesystem Context functionality fails to properly verify supplied parameter lengths, causing a…KEVEPSS 25%analysed8.4CVE-2013-2094Linux Kernel perf_swevent_init Integer Type Flaw Enables Local Privilege EscalationThe perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9 uses an incorrect integer data type, allowing a local user to…KEVEPSS 48%analysed7.8CVE-2026-53362Linux kernel IPv6 UDP paged allocation out-of-bounds write__ip6_append_data() in the Linux kernel mis-accounts fraggap on the paged-allocation path, leaving the linear skb area undersized while pagedlen is o…KEVEPSS 0.71%analysed7.8CVE-2026-31431Linux kernel algif_aead in-place crypto operation flawThe Linux kernel's algif_aead AF_ALG AEAD interface operated in-place on buffers that come from different mappings, a flaw the fix resolves by revert…KEVEPSS 3.4%analysed

Source: NIST National Vulnerability Database (record CVE-2026-45933), CISA KEV, FIRST EPSS (scores of 2026-09-26). This page is refreshed as NVD updates the record.