CVE-2026-45933 (GCVE-0-2026-45933)

Vulnerability from cvelistv5 – Published: 2026-05-27 12:17 – Updated: 2026-05-27 12:17
VLAI
Title
bpf: Preserve id of register in sync_linked_regs()
Summary
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.
Severity
No CVSS data available.
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 58059335e46537de682db84984f7716c813208c4 (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 92a8cb1806adefb263cf096eab6705705cf7eee1 (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 65d114b5270b62aefb820ecd6c3b7caeea8f895d (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < af9e89d8dd39530c8bd14c33ddf6b502df1071b6 (git)
Create a notification for this product.
Linux Linux Affected: 6.11
Unaffected: 0 , < 6.11 (semver)
Unaffected: 6.12.75 , ≤ 6.12.* (semver)
Unaffected: 6.18.14 , ≤ 6.18.* (semver)
Unaffected: 6.19.4 , ≤ 6.19.* (semver)
Unaffected: 7.0 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "58059335e46537de682db84984f7716c813208c4",
              "status": "affected",
              "version": "98d7ca374ba4b39e7535613d40e159f09ca14da2",
              "versionType": "git"
            },
            {
              "lessThan": "92a8cb1806adefb263cf096eab6705705cf7eee1",
              "status": "affected",
              "version": "98d7ca374ba4b39e7535613d40e159f09ca14da2",
              "versionType": "git"
            },
            {
              "lessThan": "65d114b5270b62aefb820ecd6c3b7caeea8f895d",
              "status": "affected",
              "version": "98d7ca374ba4b39e7535613d40e159f09ca14da2",
              "versionType": "git"
            },
            {
              "lessThan": "af9e89d8dd39530c8bd14c33ddf6b502df1071b6",
              "status": "affected",
              "version": "98d7ca374ba4b39e7535613d40e159f09ca14da2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/verifier.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.11"
            },
            {
              "lessThan": "6.11",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.75",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.14",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.19.*",
              "status": "unaffected",
              "version": "6.19.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.75",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.14",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19.4",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s say with the following:\n\nif known_reg \u003e= 10 goto pc+2\n\nknown_reg\u0027s 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\u0027s 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 \u0026= 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 \u003c 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 \u003c 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 \u003e= 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\u0027s 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\u0027s id was changed to 2, r1\u0027s 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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-27T12:17:51.127Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4"
        },
        {
          "url": "https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1"
        },
        {
          "url": "https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d"
        },
        {
          "url": "https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6"
        }
      ],
      "title": "bpf: Preserve id of register in sync_linked_regs()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-45933",
    "datePublished": "2026-05-27T12:17:51.127Z",
    "dateReserved": "2026-05-13T15:03:33.086Z",
    "dateUpdated": "2026-05-27T12:17:51.127Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-45933",
      "date": "2026-05-29",
      "epss": "0.00018",
      "percentile": "0.05077"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-45933\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-05-27T14:17:09.297\",\"lastModified\":\"2026-05-27T14:48:03.013\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s say with the following:\\n\\nif known_reg \u003e= 10 goto pc+2\\n\\nknown_reg\u0027s 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\u0027s 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 \u0026= 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 \u003c 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 \u003c 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 \u003e= 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\u0027s 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\u0027s id was changed to 2, r1\u0027s 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.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.