{"id":"CVE-2026-45933","url":"https://www.cyber-defence.io/tools/cve/CVE-2026-45933","generatedAt":"2026-10-28T09:26:07.781Z","title":"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…","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.","published":"2026-05-27T14:17:09.000Z","lastModified":"2026-10-19T20:18:22.000Z","status":"Undergoing Analysis","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","cvss":{"version":"3.1","score":7.8,"severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"cwe":["CWE-682"],"affected":["linux/linux kernel"],"epss":{"score":0.00196,"percentile":0.09229,"date":"2026-10-27","history":[]},"kev":{"listed":false},"exploits":{"count":0,"verified":false,"firstPublished":null,"source":"Exploit-DB (https://gitlab.com/exploit-database/exploitdb)","entries":[]},"verdict":{"level":"high","text":"High impact if exploited, but EPSS currently rates exploitation as unlikely (0.20%). Schedule it in the normal patch cycle and watch for a rise in EPSS or a public exploit."},"changes":[],"references":[{"url":"https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4","tags":["Patch"],"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d","tags":["Patch"],"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1","tags":["Patch"],"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6","tags":["Patch"],"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"sources":{"nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-45933","epss":"https://www.first.org/epss/","kev":"https://www.cisa.gov/known-exploited-vulnerabilities-catalog","exploitdb":"https://www.exploit-db.com/"},"licence":"CC BY 4.0 — link back to the CVE Explorer if you publish the results; upstream data remains subject to its own terms."}