GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

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

Vulnerability from cvelistv5 – Published: 2026-05-27 12:17 – Updated: 2026-08-05 12:28
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
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 58059335e46537de682db84984f7716c813208c4 (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 92a8cb1806adefb263cf096eab6705705cf7eee1 (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < 65d114b5270b62aefb820ecd6c3b7caeea8f895d (git)
Affected: 98d7ca374ba4b39e7535613d40e159f09ca14da2 , < af9e89d8dd39530c8bd14c33ddf6b502df1071b6 (git)
guessed 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)
guessed 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is in the BPF verifier, reached only by loading a crafted BPF program via the bpf() syscall from a local process; remote data never reaches this code.\nAC:L - The attacker writes the exact BPF instruction sequence that deterministically triggers the broken link in sync_linked_regs(); no race or uncontrolled condition is involved.\nPR:L - The verifier runs for all program loads, and socket-filter/cgroup-skb programs are loadable without CAP_BPF when unprivileged_bpf_disabled=0 (a supported default), so any unprivileged local user can reach it.\nUI:N - The attacker loads and runs their own program; no victim action is required.\nS:U - Impact is confined to the kernel\u0027s own security authority \u2014 standard local privilege escalation, no crossing into a separate VM/IOMMU boundary.\nC:H - The verifier can be made to believe a register holds a wrong value, allowing a verified-as-safe out-of-bounds read primitive over kernel memory, yielding arbitrary kernel memory disclosure.\nI:H - The same false-bounds primitive enables an out-of-bounds write the verifier \"proved\" safe, giving an arbitrary kernel write usable for privilege escalation and code-flow hijacking.\nA:H - The resulting out-of-bounds accesses on attacker-controlled values readily corrupt kernel memory and panic/crash the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:28:47.803Z",
        "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-08-05T12:28:47.803Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-45933",
      "date": "2026-09-13",
      "epss": "0.00177",
      "percentile": "0.07451"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-45933\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-05-27T14:17:09.297\",\"lastModified\":\"2026-06-24T17:11:11.247\",\"vulnStatus\":\"Undergoing 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.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"kernel/bpf/verifier.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"98d7ca374ba4b39e7535613d40e159f09ca14da2\",\"lessThan\":\"58059335e46537de682db84984f7716c813208c4\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"98d7ca374ba4b39e7535613d40e159f09ca14da2\",\"lessThan\":\"92a8cb1806adefb263cf096eab6705705cf7eee1\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"98d7ca374ba4b39e7535613d40e159f09ca14da2\",\"lessThan\":\"65d114b5270b62aefb820ecd6c3b7caeea8f895d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"98d7ca374ba4b39e7535613d40e159f09ca14da2\",\"lessThan\":\"af9e89d8dd39530c8bd14c33ddf6b502df1071b6\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"kernel/bpf/verifier.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.11\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.11\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.75\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.14\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.19.4\",\"lessThanOrEqual\":\"6.19.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.0\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.11\",\"versionEndExcluding\":\"6.12.75\",\"matchCriteriaId\":\"A05DCA5C-0E7E-47B5-899A-41DDF296199E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.18.14\",\"matchCriteriaId\":\"BF463CB7-1F58-4607-B847-77ED23E4B9B7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.19\",\"versionEndExcluding\":\"6.19.4\",\"matchCriteriaId\":\"672A3E79-EC03-479D-8503-361DFBDC8092\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/65d114b5270b62aefb820ecd6c3b7caeea8f895d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/92a8cb1806adefb263cf096eab6705705cf7eee1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/af9e89d8dd39530c8bd14c33ddf6b502df1071b6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-07-02T21:32:00+00:00",
      "cve": "CVE-2026-45933",
      "id": "CVE-2026-45933",
      "initial_release_date": "2026-05-27T00:00:00+00:00",
      "product_status:known_affected": "184",
      "product_status:known_not_affected": "90",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: bpf: Preserve id of register in sync_linked_regs()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45933.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-11T01:14:05Z",
      "cve": "CVE-2026-45933",
      "id": "CVE-2026-45933",
      "initial_release_date": "2026-05-28T03:55:55Z",
      "product_status:first_fixed": "2",
      "product_status:known_not_affected": "370",
      "product_status:recommended": "145",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-45933",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-45933.json",
      "version": "8"
    }
  }
}



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.