cve-2024-41003
Vulnerability from cvelistv5
Published
2024-07-12 12:44
Modified
2024-12-19 09:09
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix reg_set_min_max corruption of fake_reg Juan reported that after doing some changes to buzzer [0] and implementing a new fuzzing strategy guided by coverage, they noticed the following in one of the probes: [...] 13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=scalar() 14: (b7) r0 = 0 ; R0_w=0 15: (b4) w0 = -1 ; R0_w=0xffffffff 16: (74) w0 >>= 1 ; R0_w=0x7fffffff 17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff)) 18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd)) 19: (56) if w6 != 0x7ffffffd goto pc+1 REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0) 19: R6_w=0x7fffffff 20: (95) exit from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: (14) w6 -= 2147483632 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd)) 22: (76) if w6 s>= 0xe goto pc+1 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd)) 23: (95) exit from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: (14) w6 -= 14 ; R6_w=0 [...] What can be seen here is a register invariant violation on line 19. After the binary-or in line 18, the verifier knows that bit 2 is set but knows nothing about the rest of the content which was loaded from a map value, meaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in line 19 the verifier analyzes the branch, it splits the register states in reg_set_min_max() into the registers of the true branch (true_reg1, true_reg2) and the registers of the false branch (false_reg1, false_reg2). Since the test is w6 != 0x7ffffffd, the src_reg is a known constant. Internally, the verifier creates a "fake" register initialized as scalar to the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now, for line 19, it is mathematically impossible to take the false branch of this program, yet the verifier analyzes it. It is impossible because the second bit of r6 will be set due to the prior or operation and the constant in the condition has that bit unset (hex(fd) == binary(1111 1101). When the verifier first analyzes the false / fall-through branch, it will compute an intersection between the var_off of r6 and of the constant. This is because the verifier creates a "fake" register initialized to the value of the constant. The intersection result later refines both registers in regs_refine_cond_op(): [...] t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off)); reg1->var_o ---truncated---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2
Impacted products
Vendor Product Version
Linux Linux Version: 67420501e8681ae18f9f0ea0a69cd2f432100e70
Version: 67420501e8681ae18f9f0ea0a69cd2f432100e70
 Create a notification for this product.
   Linux Linux Version: 6.8
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
   containers: {
      adp: [
         {
            providerMetadata: {
               dateUpdated: "2024-08-02T04:39:56.068Z",
               orgId: "af854a3a-2127-422b-91ae-364da2661108",
               shortName: "CVE",
            },
            references: [
               {
                  tags: [
                     "x_transferred",
                  ],
                  url: "https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b",
               },
               {
                  tags: [
                     "x_transferred",
                  ],
                  url: "https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2",
               },
            ],
            title: "CVE Program Container",
         },
         {
            metrics: [
               {
                  other: {
                     content: {
                        id: "CVE-2024-41003",
                        options: [
                           {
                              Exploitation: "none",
                           },
                           {
                              Automatable: "no",
                           },
                           {
                              "Technical Impact": "partial",
                           },
                        ],
                        role: "CISA Coordinator",
                        timestamp: "2024-09-10T17:01:08.608294Z",
                        version: "2.0.3",
                     },
                     type: "ssvc",
                  },
               },
            ],
            providerMetadata: {
               dateUpdated: "2024-09-11T17:34:18.907Z",
               orgId: "134c704f-9b21-4f2e-91b3-4a467353bcc0",
               shortName: "CISA-ADP",
            },
            title: "CISA ADP Vulnrichment",
         },
      ],
      cna: {
         affected: [
            {
               defaultStatus: "unaffected",
               product: "Linux",
               programFiles: [
                  "include/linux/bpf_verifier.h",
                  "kernel/bpf/verifier.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     lessThan: "41e8ab428a9964df378fa45760a660208712145b",
                     status: "affected",
                     version: "67420501e8681ae18f9f0ea0a69cd2f432100e70",
                     versionType: "git",
                  },
                  {
                     lessThan: "92424801261d1564a0bb759da3cf3ccd69fdf5a2",
                     status: "affected",
                     version: "67420501e8681ae18f9f0ea0a69cd2f432100e70",
                     versionType: "git",
                  },
               ],
            },
            {
               defaultStatus: "affected",
               product: "Linux",
               programFiles: [
                  "include/linux/bpf_verifier.h",
                  "kernel/bpf/verifier.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     status: "affected",
                     version: "6.8",
                  },
                  {
                     lessThan: "6.8",
                     status: "unaffected",
                     version: "0",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "6.9.*",
                     status: "unaffected",
                     version: "6.9.7",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "*",
                     status: "unaffected",
                     version: "6.10",
                     versionType: "original_commit_for_fix",
                  },
               ],
            },
         ],
         descriptions: [
            {
               lang: "en",
               value: "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix reg_set_min_max corruption of fake_reg\n\nJuan reported that after doing some changes to buzzer [0] and implementing\na new fuzzing strategy guided by coverage, they noticed the following in\none of the probes:\n\n  [...]\n  13: (79) r6 = *(u64 *)(r0 +0)         ; R0=map_value(ks=4,vs=8) R6_w=scalar()\n  14: (b7) r0 = 0                       ; R0_w=0\n  15: (b4) w0 = -1                      ; R0_w=0xffffffff\n  16: (74) w0 >>= 1                     ; R0_w=0x7fffffff\n  17: (5c) w6 &= w0                     ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))\n  18: (44) w6 |= 2                      ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))\n  19: (56) if w6 != 0x7ffffffd goto pc+1\n  REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\n  REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\n  REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)\n  19: R6_w=0x7fffffff\n  20: (95) exit\n\n  from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\n  21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\n  21: (14) w6 -= 2147483632             ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))\n  22: (76) if w6 s>= 0xe goto pc+1      ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))\n  23: (95) exit\n\n  from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\n  24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\n  24: (14) w6 -= 14                     ; R6_w=0\n  [...]\n\nWhat can be seen here is a register invariant violation on line 19. After\nthe binary-or in line 18, the verifier knows that bit 2 is set but knows\nnothing about the rest of the content which was loaded from a map value,\nmeaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in\nline 19 the verifier analyzes the branch, it splits the register states\nin reg_set_min_max() into the registers of the true branch (true_reg1,\ntrue_reg2) and the registers of the false branch (false_reg1, false_reg2).\n\nSince the test is w6 != 0x7ffffffd, the src_reg is a known constant.\nInternally, the verifier creates a \"fake\" register initialized as scalar\nto the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,\nfor line 19, it is mathematically impossible to take the false branch of\nthis program, yet the verifier analyzes it. It is impossible because the\nsecond bit of r6 will be set due to the prior or operation and the\nconstant in the condition has that bit unset (hex(fd) == binary(1111 1101).\n\nWhen the verifier first analyzes the false / fall-through branch, it will\ncompute an intersection between the var_off of r6 and of the constant. This\nis because the verifier creates a \"fake\" register initialized to the value\nof the constant. The intersection result later refines both registers in\nregs_refine_cond_op():\n\n  [...]\n  t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));\n  reg1->var_o\n---truncated---",
            },
         ],
         providerMetadata: {
            dateUpdated: "2024-12-19T09:09:51.035Z",
            orgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            shortName: "Linux",
         },
         references: [
            {
               url: "https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b",
            },
            {
               url: "https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2",
            },
         ],
         title: "bpf: Fix reg_set_min_max corruption of fake_reg",
         x_generator: {
            engine: "bippy-5f407fcff5a0",
         },
      },
   },
   cveMetadata: {
      assignerOrgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      assignerShortName: "Linux",
      cveId: "CVE-2024-41003",
      datePublished: "2024-07-12T12:44:39.110Z",
      dateReserved: "2024-07-12T12:17:45.609Z",
      dateUpdated: "2024-12-19T09:09:51.035Z",
      state: "PUBLISHED",
   },
   dataType: "CVE_RECORD",
   dataVersion: "5.1",
   "vulnerability-lookup:meta": {
      nvd: "{\"cve\":{\"id\":\"CVE-2024-41003\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-07-12T13:15:21.180\",\"lastModified\":\"2024-11-21T09:32:02.683\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fix reg_set_min_max corruption of fake_reg\\n\\nJuan reported that after doing some changes to buzzer [0] and implementing\\na new fuzzing strategy guided by coverage, they noticed the following in\\none of the probes:\\n\\n  [...]\\n  13: (79) r6 = *(u64 *)(r0 +0)         ; R0=map_value(ks=4,vs=8) R6_w=scalar()\\n  14: (b7) r0 = 0                       ; R0_w=0\\n  15: (b4) w0 = -1                      ; R0_w=0xffffffff\\n  16: (74) w0 >>= 1                     ; R0_w=0x7fffffff\\n  17: (5c) w6 &= w0                     ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))\\n  18: (44) w6 |= 2                      ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))\\n  19: (56) if w6 != 0x7ffffffd goto pc+1\\n  REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\\n  REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\\n  REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)\\n  19: R6_w=0x7fffffff\\n  20: (95) exit\\n\\n  from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  21: (14) w6 -= 2147483632             ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))\\n  22: (76) if w6 s>= 0xe goto pc+1      ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))\\n  23: (95) exit\\n\\n  from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  24: (14) w6 -= 14                     ; R6_w=0\\n  [...]\\n\\nWhat can be seen here is a register invariant violation on line 19. After\\nthe binary-or in line 18, the verifier knows that bit 2 is set but knows\\nnothing about the rest of the content which was loaded from a map value,\\nmeaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in\\nline 19 the verifier analyzes the branch, it splits the register states\\nin reg_set_min_max() into the registers of the true branch (true_reg1,\\ntrue_reg2) and the registers of the false branch (false_reg1, false_reg2).\\n\\nSince the test is w6 != 0x7ffffffd, the src_reg is a known constant.\\nInternally, the verifier creates a \\\"fake\\\" register initialized as scalar\\nto the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,\\nfor line 19, it is mathematically impossible to take the false branch of\\nthis program, yet the verifier analyzes it. It is impossible because the\\nsecond bit of r6 will be set due to the prior or operation and the\\nconstant in the condition has that bit unset (hex(fd) == binary(1111 1101).\\n\\nWhen the verifier first analyzes the false / fall-through branch, it will\\ncompute an intersection between the var_off of r6 and of the constant. This\\nis because the verifier creates a \\\"fake\\\" register initialized to the value\\nof the constant. The intersection result later refines both registers in\\nregs_refine_cond_op():\\n\\n  [...]\\n  t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));\\n  reg1->var_o\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bpf: Fix reg_set_min_max corrupción de fake_reg Juan informó que después de hacer algunos cambios al buzzer [0] e implementar una nueva estrategia de fuzzing guiada por cobertura, notaron lo siguiente en una de las sondas : [...] 13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=escalar() 14: (b7) r0 = 0 ; R0_w=0 15: (b4) w0 = -1 ; R0_w=0xffffffff 16: (74) w0 >>= 1 ; R0_w=0x7ffffffff 17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=escalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff)) 18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd)) 19: (56) if w6 != 0x7ffffffd goto pc+1 VIOLACIÓN DE INVARIANTES REG (true_reg2) : violación de límites de rango u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) INVARIANTES DEL REG (false_reg1): violación de los límites de rango u64 =[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0) VIOLACIÓN DE INVARIANTES REG (false_reg2): st tnum no está sincronizado con los límites de rango u64 =[0x0, 0xffffffffffffffff] s64=[0x80000000000000000, 0x7ffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7ffffff] var_off=(0x7ffffffff, 0x0) 19: 6_w=0x7fffffff 20: (95) salida del 19 al 21: R0=0x7fffffff R6=escalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx () R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: R0=0x7fffffff R6=escalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32 =0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 21: (14) w6 -= 2147483632; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd)) 22: (76) si w6 s>= 0xe goto pc+1; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd)) 23: (95) salida de 22 a 24: R0=0x7fffffff R6_w= 14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: R0=0x7ffffffff R6_w=14 R7= map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm 24: (14) w6 -= 14 ; R6_w=0 [...] Lo que se puede ver aquí es una violación de invariante de registro en la línea 19. Después del binario o en la línea 18, el verificador sabe que el bit 2 está establecido pero no sabe nada sobre el resto del contenido que fue cargado desde un valor de mapa, es decir, el rango es [2,0x7fffffff] con var_off=(0x2; 0x7ffffffd). Cuando en la línea 19 el verificador analiza la rama, divide los estados de registro en reg_set_min_max() en los registros de la rama verdadera (true_reg1, true_reg2) y los registros de la rama falsa (false_reg1, false_reg2). Dado que la prueba es w6! = 0x7ffffffd, src_reg es una constante conocida. Internamente, el verificador crea un registro \\\"falso\\\" inicializado como escalar al valor de 0x7ffffffd y luego lo pasa a reg_set_min_max(). Ahora, para la línea 19, es matemáticamente imposible tomar la rama falsa de este programa, sin embargo, el verificador la analiza. Es imposible porque el segundo bit de r6 se establecerá debido a la operación anterior o y la constante en la condición tiene ese bit sin configurar (hex(fd) == binario(1111 1101). Cuando el verificador analiza por primera vez el valor falso/caída -a través de la rama, calculará una intersección entre el var_off de r6 y la constante. Esto se debe a que el verificador crea un registro \\\"falso\\\" inicializado con el valor de la constante. El resultado de la intersección luego refina ambos registros en regs_refine_cond_op(): [...] t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}",
      vulnrichment: {
         containers: "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T04:39:56.068Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-41003\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-10T17:01:08.608294Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-11T12:42:21.947Z\"}}], \"cna\": {\"title\": \"bpf: Fix reg_set_min_max corruption of fake_reg\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"67420501e868\", \"lessThan\": \"41e8ab428a99\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"67420501e868\", \"lessThan\": \"92424801261d\", \"versionType\": \"git\"}], \"programFiles\": [\"include/linux/bpf_verifier.h\", \"kernel/bpf/verifier.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.8\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.8\", \"versionType\": \"custom\"}, {\"status\": \"unaffected\", \"version\": \"6.9.7\", \"versionType\": \"custom\", \"lessThanOrEqual\": \"6.9.*\"}, {\"status\": \"unaffected\", \"version\": \"6.10\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"include/linux/bpf_verifier.h\", \"kernel/bpf/verifier.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/41e8ab428a9964df378fa45760a660208712145b\"}, {\"url\": \"https://git.kernel.org/stable/c/92424801261d1564a0bb759da3cf3ccd69fdf5a2\"}], \"x_generator\": {\"engine\": \"bippy-c9c4e1df01b2\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fix reg_set_min_max corruption of fake_reg\\n\\nJuan reported that after doing some changes to buzzer [0] and implementing\\na new fuzzing strategy guided by coverage, they noticed the following in\\none of the probes:\\n\\n  [...]\\n  13: (79) r6 = *(u64 *)(r0 +0)         ; R0=map_value(ks=4,vs=8) R6_w=scalar()\\n  14: (b7) r0 = 0                       ; R0_w=0\\n  15: (b4) w0 = -1                      ; R0_w=0xffffffff\\n  16: (74) w0 >>= 1                     ; R0_w=0x7fffffff\\n  17: (5c) w6 &= w0                     ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))\\n  18: (44) w6 |= 2                      ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))\\n  19: (56) if w6 != 0x7ffffffd goto pc+1\\n  REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\\n  REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)\\n  REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)\\n  19: R6_w=0x7fffffff\\n  20: (95) exit\\n\\n  from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  21: (14) w6 -= 2147483632             ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))\\n  22: (76) if w6 s>= 0xe goto pc+1      ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))\\n  23: (95) exit\\n\\n  from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm\\n  24: (14) w6 -= 14                     ; R6_w=0\\n  [...]\\n\\nWhat can be seen here is a register invariant violation on line 19. After\\nthe binary-or in line 18, the verifier knows that bit 2 is set but knows\\nnothing about the rest of the content which was loaded from a map value,\\nmeaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in\\nline 19 the verifier analyzes the branch, it splits the register states\\nin reg_set_min_max() into the registers of the true branch (true_reg1,\\ntrue_reg2) and the registers of the false branch (false_reg1, false_reg2).\\n\\nSince the test is w6 != 0x7ffffffd, the src_reg is a known constant.\\nInternally, the verifier creates a \\\"fake\\\" register initialized as scalar\\nto the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,\\nfor line 19, it is mathematically impossible to take the false branch of\\nthis program, yet the verifier analyzes it. It is impossible because the\\nsecond bit of r6 will be set due to the prior or operation and the\\nconstant in the condition has that bit unset (hex(fd) == binary(1111 1101).\\n\\nWhen the verifier first analyzes the false / fall-through branch, it will\\ncompute an intersection between the var_off of r6 and of the constant. This\\nis because the verifier creates a \\\"fake\\\" register initialized to the value\\nof the constant. The intersection result later refines both registers in\\nregs_refine_cond_op():\\n\\n  [...]\\n  t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));\\n  reg1->var_o\\n---truncated---\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2024-07-15T06:53:15.103Z\"}}}",
         cveMetadata: "{\"cveId\": \"CVE-2024-41003\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-09-11T17:34:18.907Z\", \"dateReserved\": \"2024-07-12T12:17:45.609Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-07-12T12:44:39.110Z\", \"assignerShortName\": \"Linux\"}",
         dataType: "CVE_RECORD",
         dataVersion: "5.1",
      },
   },
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.