{"cve":"CVE-2026-45933","nvd":{"published":"2026-05-27T14:17:09.297","modified":"2026-10-19T20:18:21.540","status":"Undergoing Analysis","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Preserve id of register in sync_linked_regs()\n\nsync_linked_regs() copies the id of known_reg to reg when propagating\nbounds of known_reg to reg using the off of known_reg, but when\nknown_reg was linked to reg like:\n\nknown_reg = reg         ; both known_reg and reg get same id\nknown_reg += 4          ; known_reg gets off = 4, and its id gets BPF_ADD_CONST\n\nnow when a call to sync_linked_regs() happens, let's say with the following:\n\nif known_reg >= 10 goto pc+2\n\nknown_reg's new bounds are propagated to reg but now reg gets\nBPF_ADD_CONST from the copy.\n\nThis means if another link to reg is created like:\n\nanother_reg = reg       ; another_reg should get the id of reg but\n                          assign_scalar_id_before_mov() sees\n                          BPF_ADD_CONST on reg and assigns a new id to it.\n\nAs reg has a new id now, known_reg's link to reg is broken. If we find\nnew bounds for known_reg, they will not be propagated to reg.\n\nThis can be seen in the selftest added in the next commit:\n\n0: (85) call bpf_get_prandom_u32#7    ; R0=scalar()\n1: (57) r0 &= 255                     ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff))\n2: (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))\n3: (07) r1 += 4                       ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff))\n4: (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))\n5: (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)\n6: (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))\n7: (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))\n8: (37) r0 /= 0\ndiv by zero\n\nWhen 4 is verified, r1's bounds are propagated to r0 but r0 also gets\nBPF_ADD_CONST (bug).\nWhen 5 is verified, r0 gets a new id (2) and its link with r1 is broken.\n\nAfter 6 we know r1 has bounds [14, 259] and therefore r0 should have\nbounds [10, 255], therefore the branch at 7 is always taken. But because\nr0's id was changed to 2, r1's new bounds are not propagated to r0.\nThe verifier still thinks r0 has bounds [6, 255] before 7 and execution\ncan reach div by zero.\n\nFix this by preserving id in sync_linked_regs() like off and subreg_def.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":7.8},"cwes":["CWE-682"],"references":["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"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-21T03:43:09.190223697+00:00"},"epss":{"cve":"CVE-2026-45933","score":0.00196,"percentile":0.09213,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}