Vulnerability-Lookup

CVE-2024-46803 (GCVE-0-2024-46803)

Vulnerability from cvelistv5 – Published: 2024-09-27 12:35 – Updated: 2026-08-05 11:38

Title

drm/amdkfd: Check debug trap enable before write dbg_ev_file

Summary

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check debug trap enable before write dbg_ev_file In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-29 14:20 UTC

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6971 records in the last 180 days details

References

3 references

URL	Tags
https://git.kernel.org/stable/c/e6ea3b8fe39891533…
https://git.kernel.org/stable/c/820dcbd38a77bd5fd…
https://git.kernel.org/stable/c/547033b593063eb85…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508 , < e6ea3b8fe398915338147fe54dd2db8155fdafd8 (git) Affected: 0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508 , < 820dcbd38a77bd5fdc4236d521c1c122841227d0 (git) Affected: 0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508 , < 547033b593063eb85bfdf9b25a5f1b8fd1911be2 (git)	guessed
Linux	Linux	Affected: 6.5 Unaffected: 0 , < 6.5 (semver) Unaffected: 6.6.50 , ≤ 6.6.* (semver) Unaffected: 6.10.9 , ≤ 6.10.* (semver) Unaffected: 6.11 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-46803",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-29T14:20:52.974033Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-29T14:21:05.556Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "e6ea3b8fe398915338147fe54dd2db8155fdafd8",
              "status": "affected",
              "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
              "versionType": "git"
            },
            {
              "lessThan": "820dcbd38a77bd5fdc4236d521c1c122841227d0",
              "status": "affected",
              "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
              "versionType": "git"
            },
            {
              "lessThan": "547033b593063eb85bfdf9b25a5f1b8fd1911be2",
              "status": "affected",
              "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.5"
            },
            {
              "lessThan": "6.5",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.50",
                  "versionStartIncluding": "6.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.9",
                  "versionStartIncluding": "6.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11",
                  "versionStartIncluding": "6.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Check debug trap enable before write dbg_ev_file\n\nIn interrupt context, write dbg_ev_file will be run by work queue. It\nwill cause write dbg_ev_file execution after debug_trap_disable, which\nwill cause NULL pointer access.\nv2: cancel work \"debug_event_workarea\" before set dbg_ev_file as NULL."
        }
      ],
      "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 vulnerability is reached through the AMDKFD_IOC_DBG_TRAP ioctl on the /dev/kfd character device (and the process-teardown path), requiring local access to the machine. No network or remote protocol handling is involved.\nAC:L - The attacker controls both sides of the race: they flood debug exceptions by submitting shaders that raise SQ traps/bad opcodes/memory violations (queuing the work item from GPU IRQ) while concurrently issuing KFD_IOC_DBG_TRAP_DISABLE in a loop, and can retry indefinitely until the window is hit.\nPR:L - Only an unprivileged local account with access to /dev/kfd is needed \u2014 kfd_open() performs no capability check and the ptrace_parent() gate in kfd_ioctl_set_debug_trap() is bypassed entirely when a process debugs itself (target == p). ROCm systems ship /dev/kfd world- or render-group-accessible, so any local user on an AMD GPU compute node qualifies.\nUI:N - The attacking process performs every step itself \u2014 enabling debug trap, submitting the faulting GPU work, and disabling the trap. No victim action or interaction is required.\nS:U - The corruption and its consequences are confined to the kernel of the same host; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - After fput() drops the last reference, the worker uses a dangling struct file from the filp slab cache, and an attacker who reclaims that object controls the f_op table used by kernel_write \u2014 a use-after-free that can be leveraged into arbitrary kernel memory disclosure.\nI:H - __kernel_write_iter() indirectly calls file-\u003ef_op-\u003ewrite_iter() on the freed struct file, giving a direct control-flow-hijack primitive once the attacker sprays the reclaimed filp object, which translates into arbitrary kernel write and privilege escalation.\nA:H - The commonly observed outcome is a NULL pointer dereference in kernel_write() from a kworker context, oopsing the kernel; the use-after-free variant likewise crashes the machine, and the attacker can trigger it repeatedly."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:38:41.734Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/e6ea3b8fe398915338147fe54dd2db8155fdafd8"
        },
        {
          "url": "https://git.kernel.org/stable/c/820dcbd38a77bd5fdc4236d521c1c122841227d0"
        },
        {
          "url": "https://git.kernel.org/stable/c/547033b593063eb85bfdf9b25a5f1b8fd1911be2"
        }
      ],
      "title": "drm/amdkfd: Check debug trap enable before write dbg_ev_file",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-46803",
    "datePublished": "2024-09-27T12:35:49.185Z",
    "dateReserved": "2024-09-11T15:12:18.281Z",
    "dateUpdated": "2026-08-05T11:38:41.734Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-46803",
      "date": "2026-11-01",
      "epss": "0.00271",
      "percentile": "0.19412"
    },
    "microsoft_vex": {
      "current_release_date": "2026-03-31T14:37:25.000Z",
      "cve": "CVE-2024-46803",
      "id": "msrc_CVE-2024-46803",
      "initial_release_date": "2024-09-01T07:00:00.000Z",
      "product_status:fixed": "2",
      "product_status:known_affected": "2",
      "product_status:under_investigation": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "drm/amdkfd: Check debug trap enable before write dbg_ev_file",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-46803.json",
      "version": "4"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "e6ea3b8fe398915338147fe54dd2db8155fdafd8",
                    "status": "affected",
                    "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "820dcbd38a77bd5fdc4236d521c1c122841227d0",
                    "status": "affected",
                    "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "547033b593063eb85bfdf9b25a5f1b8fd1911be2",
                    "status": "affected",
                    "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.5"
                  },
                  {
                    "lessThan": "6.5",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.50",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.10.*",
                    "status": "unaffected",
                    "version": "6.10.9",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.11",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FAE86900-6239-4D0C-B6C0-70BF7C6BA610",
                    "versionEndExcluding": "6.6.50",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "F4469C96-A86B-4CC3-B2D5-C21B6B72641B",
                    "versionEndExcluding": "6.10.9",
                    "versionStartIncluding": "6.7",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Check debug trap enable before write dbg_ev_file\n\nIn interrupt context, write dbg_ev_file will be run by work queue. It\nwill cause write dbg_ev_file execution after debug_trap_disable, which\nwill cause NULL pointer access.\nv2: cancel work \"debug_event_workarea\" before set dbg_ev_file as NULL."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: comprobar la habilitaci\u00f3n de la trampa de depuraci\u00f3n antes de escribir dbg_ev_file En el contexto de interrupci\u00f3n, la cola de trabajo ejecutar\u00e1 la escritura dbg_ev_file. Esto provocar\u00e1 la ejecuci\u00f3n de la escritura dbg_ev_file despu\u00e9s de debug_trap_disable, lo que provocar\u00e1 el acceso al puntero NULL. v2: cancelar el trabajo \"debug_event_workarea\" antes de establecer dbg_ev_file como NULL."
          }
        ],
        "id": "CVE-2024-46803",
        "lastModified": "2026-08-04T11:20:27.920",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            },
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-46803",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-29T14:20:52.974033Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-09-27T13:15:13.570",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/547033b593063eb85bfdf9b25a5f1b8fd1911be2"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/820dcbd38a77bd5fdc4236d521c1c122841227d0"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/e6ea3b8fe398915338147fe54dd2db8155fdafd8"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-476"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-13T09:15:49+00:00",
      "cve": "CVE-2024-46803",
      "id": "CVE-2024-46803",
      "initial_release_date": "2024-09-27T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: drm/amdkfd: Check debug trap enable before write dbg_ev_file",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-46803.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-46803",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-29T14:20:52.974033Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-29T14:20:54.435Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "e6ea3b8fe398915338147fe54dd2db8155fdafd8",
                  "status": "affected",
                  "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                  "versionType": "git"
                },
                {
                  "lessThan": "820dcbd38a77bd5fdc4236d521c1c122841227d0",
                  "status": "affected",
                  "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                  "versionType": "git"
                },
                {
                  "lessThan": "547033b593063eb85bfdf9b25a5f1b8fd1911be2",
                  "status": "affected",
                  "version": "0ab2d7532b05a3e7c06fd3b0c8bd6b46c1dfb508",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/gpu/drm/amd/amdkfd/kfd_debug.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "6.5"
                },
                {
                  "lessThan": "6.5",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.50",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.10.*",
                  "status": "unaffected",
                  "version": "6.10.9",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.11",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.50",
                      "versionStartIncluding": "6.5",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.10.9",
                      "versionStartIncluding": "6.5",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.11",
                      "versionStartIncluding": "6.5",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Check debug trap enable before write dbg_ev_file\n\nIn interrupt context, write dbg_ev_file will be run by work queue. It\nwill cause write dbg_ev_file execution after debug_trap_disable, which\nwill cause NULL pointer access.\nv2: cancel work \"debug_event_workarea\" before set dbg_ev_file as NULL."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-05-11T20:36:50.768Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/e6ea3b8fe398915338147fe54dd2db8155fdafd8"
            },
            {
              "url": "https://git.kernel.org/stable/c/820dcbd38a77bd5fdc4236d521c1c122841227d0"
            },
            {
              "url": "https://git.kernel.org/stable/c/547033b593063eb85bfdf9b25a5f1b8fd1911be2"
            }
          ],
          "title": "drm/amdkfd: Check debug trap enable before write dbg_ev_file",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-46803",
        "datePublished": "2024-09-27T12:35:49.185Z",
        "dateReserved": "2024-09-11T15:12:18.281Z",
        "dateUpdated": "2026-05-11T20:36:50.768Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

MSRC_CVE-2024-46803

Vulnerability from csaf_microsoft - Published: 2024-09-01 07:00 - Updated: 2026-03-31 14:37

Summary

drm/amdkfd: Check debug trap enable before write dbg_ev_file

Scope

1 vulnerability in this advisory, including CVE-2024-46803.

CVE-2024-46803

Fixed: 2 products Known affected: 2 products Under investigation: 3 products

https://learn.microsoft.com/en-us/azure/azure-linux/tutoria…

Open the full advisory

OESA-2024-2423 (CVE-2024-46719)

Vulnerability from osv_openeuler – Published: 2024-11-15 11:07 – Updated: 2026-08-06 11:07 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Fix null pointer dereference in trace

ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)

In the Linux kernel, the following vulnerability has been resolved:

x86/tdx: Fix data leak in mmio_read()

The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM.

Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM.

This variable is only needed as an output value. It did not need to be passed to the VMM in the first place.

Do not send the original value of *val to the VMM.

dhansen: clarify what 'val' is used for.

In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Check debug trap enable before write dbg_ev_file

In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.(CVE-2024-46803)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/amdgpu: Check tbo resource pointer

Validate tbo resource pointer, skip if NULL(CVE-2024-46807)

In the Linux kernel, the following vulnerability has been resolved:

staging: iio: frequency: ad9834: Validate frequency parameter value

In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value.

Modify parameters checking.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)

In the Linux kernel, the following vulnerability has been resolved:

lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()

If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later.

If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.(CVE-2024-47668)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING.

bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30(CVE-2024-47673)

In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 )(r1 + 76) / load _sk_buff-?klzwxh:0021?data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since "r2 <<= 32" is not allowed as "r2" is a packet pointer. To fix thisissue for case r2 = *(s32 )(r1 + 76) / load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/(CVE-2024-47702)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns "implies that stream_enc and dc->bw_vbios might be null". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.(CVE-2024-49920)

In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)

In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 </IRQ> <TASK> asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)

In the Linux kernel, the following vulnerability has been resolved: smb: client: Handle kstrdup failures for passwords In smb3_reconfigure(), after duplicating ctx->password and ctx->password2 with kstrdup(), we need to check for allocation failures. If ses->password allocation fails, return -ENOMEM. If ses->password2 allocation fails, free ses->password, set it to NULL, and return -ENOMEM.(CVE-2024-50120)

In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)

In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx() build_skb() returns NULL in case of a memory allocation failure so handle it inside __octep_oq_process_rx() to avoid NULL pointer dereference. __octep_oq_process_rx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn't break the polling immediately and thus falsely indicate to the octep_napi_poll() that the Rx pressure is going down. As there is no associated skb in this case, don't process the packets and don't push them up the network stack - they are skipped. Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. 'alloc_failures' counter is incremented to mark the skb allocation error in driver statistics. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50145)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix possible double free in smb2_set_ea() Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea' -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem.(CVE-2024-50152)

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then block->state can be NULL. The msm_disp_state_print_regs() function does have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since "dump_addr" is initialized to NULL the above is actually a noop. The code then goes on to dereference dump_addr. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as const. Patchwork: https://patchwork.freedesktop.org/patch/619657/(CVE-2024-50156)

In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)

In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.(CVE-2024-50186)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46719	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46794	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46803	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46807	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47663	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47668	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47673	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47693	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47702	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47726	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50082	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50095	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50120	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50131	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50145	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50152	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50156	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50184	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50186	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "perf-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-54.0.0.57.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-54.0.0.57.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "perf-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-54.0.0.57.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-54.0.0.57.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/tdx: Fix data leak in mmio_read()\r\n\r\nThe mmio_read() function makes a TDVMCALL to retrieve MMIO data for an\naddress from the VMM.\r\n\r\nSean noticed that mmio_read() unintentionally exposes the value of an\ninitialized variable (val) on the stack to the VMM.\r\n\r\nThis variable is only needed as an output value. It did not need to be\npassed to the VMM in the first place.\r\n\r\nDo not send the original value of *val to the VMM.\r\n\r\n[ dhansen: clarify what \u0026apos;val\u0026apos; is used for. ](CVE-2024-46794)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: Check debug trap enable before write dbg_ev_file\r\n\r\nIn interrupt context, write dbg_ev_file will be run by work queue. It\nwill cause write dbg_ev_file execution after debug_trap_disable, which\nwill cause NULL pointer access.\nv2: cancel work \u0026quot;debug_event_workarea\u0026quot; before set dbg_ev_file as NULL.(CVE-2024-46803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/amdgpu: Check tbo resource pointer\r\n\r\nValidate tbo resource pointer, skip if NULL(CVE-2024-46807)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: iio: frequency: ad9834: Validate frequency parameter value\r\n\r\nIn ad9834_write_frequency() clk_get_rate() can return 0. In such case\nad9834_calc_freqreg() call will lead to division by zero. Checking\n\u0026apos;if (fout \u0026gt; (clk_freq / 2))\u0026apos; doesn\u0026apos;t protect in case of \u0026apos;fout\u0026apos; is 0.\nad9834_write_frequency() is called from ad9834_write(), where fout is\ntaken from text buffer, which can contain any value.\r\n\r\nModify parameters checking.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fail verification for sign-extension of packet data/data_end/data_meta  syzbot reported a kernel crash due to   commit 1f1e864b6555 (\u0026quot;bpf: Handle sign-extenstin ctx member accesses\u0026quot;). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field.  The original code looks like:         r2 = *(s32 *)(r1 + 76) /* load __sk_buff-\u0026gt;data */         r3 = *(u32 *)(r1 + 80) /* load __sk_buff-\u0026gt;data_end */         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto +1         ... Note that __sk_buff-\u0026gt;data load has 32-bit sign extension.  After verification and convert_ctx_accesses(), the final asm code looks like:         r2 = *(u64 *)(r1 +208)         r2 = (s32)r2         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1         ... Note that \u0026apos;r2 = (s32)r2\u0026apos; may make the kernel __sk_buff-\u0026gt;data address invalid which may cause runtime failure.  Currently, in C code, typically we have         void *data = (void *)(long)skb-\u0026gt;data;         void *data_end = (void *)(long)skb-\u0026gt;data_end;         ... and it will generate         r2 = *(u64 *)(r1 +208)         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1  If we allow sign-extension,         void *data = (void *)(long)(int)skb-\u0026gt;data;         void *data_end = (void *)(long)skb-\u0026gt;data_end;         ... the generated code looks like         r2 = *(u64 *)(r1 +208)         r2 \u0026lt;\u0026lt;= 32         r2 s\u0026gt;\u0026gt;= 32         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1 and this will cause verification failure since \u0026quot;r2 \u0026lt;\u0026lt;= 32\u0026quot; is not allowed as \u0026quot;r2\u0026quot; is a packet pointer.  To fix this issue for case   r2 = *(s32 *)(r1 + 76) /* load __sk_buff-\u0026gt;data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail.    [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/(CVE-2024-47702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before multiple uses  [WHAT \u0026amp; HOW] Poniters, such as stream_enc and dc-\u0026gt;bw_vbios, are null checked previously in the same function, so Coverity warns \u0026quot;implies that stream_enc and dc-\u0026gt;bw_vbios might be null\u0026quot;. They are used multiple times in the subsequent code and need to be checked.  This fixes 10 FORWARD_NULL issues reported by Coverity.(CVE-2024-49920)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race  We\u0026apos;re seeing crashes from rq_qos_wake_function that look like this:    BUG: unable to handle page fault for address: ffffafe180a40084   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0   Oops: Oops: 0002 [#1] PREEMPT SMP PTI   CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40   Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u0026lt;f0\u0026gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00   RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046   RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011   RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084   RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011   R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002   R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003   FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   PKRU: 55555554   Call Trace:    \u0026lt;IRQ\u0026gt;    try_to_wake_up+0x5a/0x6a0    rq_qos_wake_function+0x71/0x80    __wake_up_common+0x75/0xa0    __wake_up+0x36/0x60    scale_up.part.0+0x50/0x110    wb_timer_fn+0x227/0x450    ...  So rq_qos_wake_function() calls wake_up_process(data-\u0026gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock).  p comes from data-\u0026gt;task, and data comes from the waitqueue entry, which is stored on the waiter\u0026apos;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-\u0026gt;task. Meanwhile, the waker was passing the clobbered garbage in data-\u0026gt;task to wake_up_process(), leading to the crash.  What\u0026apos;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this:  rq_qos_wait()                           rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive()                                         data-\u0026gt;got_token = true;                                         list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token)         break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq);   ^- returns immediately because      list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry)      is true ... return, go do something else ...                                         wake_up_process(data-\u0026gt;task)                                           (NO LONGER VALID!)-^  Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue.  The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order.  Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/mad: Improve handling of timed out WRs of mad agent  Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler.  This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes  Trace: -----  BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]  CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE      -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1  Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019  Workqueue: ib_mad1 timeout_sends [ib_core]  RIP: 0010:__do_softirq+0x78/0x2ac  RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246  RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f  RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b  RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000  R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040  FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   \u0026lt;IRQ\u0026gt;   ? show_trace_log_lvl+0x1c4/0x2df   ? show_trace_log_lvl+0x1c4/0x2df   ? __irq_exit_rcu+0xa1/0xc0   ? watchdog_timer_fn+0x1b2/0x210   ? __pfx_watchdog_timer_fn+0x10/0x10   ? __hrtimer_run_queues+0x127/0x2c0   ? hrtimer_interrupt+0xfc/0x210   ? __sysvec_apic_timer_interrupt+0x5c/0x110   ? sysvec_apic_timer_interrupt+0x37/0x90   ? asm_sysvec_apic_timer_interrupt+0x16/0x20   ? __do_softirq+0x78/0x2ac   ? __do_softirq+0x60/0x2ac   __irq_exit_rcu+0xa1/0xc0   sysvec_call_function_single+0x72/0x90   \u0026lt;/IRQ\u0026gt;   \u0026lt;TASK\u0026gt;   asm_sysvec_call_function_single+0x16/0x20  RIP: 0010:_raw_spin_unlock_irq+0x14/0x30  RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247  RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800  RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c  RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000  R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538  R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c   cm_process_send_error+0x122/0x1d0 [ib_cm]   timeout_sends+0x1dd/0x270 [ib_core]   process_one_work+0x1e2/0x3b0   ? __pfx_worker_thread+0x10/0x10   worker_thread+0x50/0x3a0   ? __pfx_worker_thread+0x10/0x10   kthread+0xdd/0x100   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x29/0x50   \u0026lt;/TASK\u0026gt;  Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: Handle kstrdup failures for passwords  In smb3_reconfigure(), after duplicating ctx-\u0026gt;password and ctx-\u0026gt;password2 with kstrdup(), we need to check for allocation failures.  If ses-\u0026gt;password allocation fails, return -ENOMEM. If ses-\u0026gt;password2 allocation fails, free ses-\u0026gt;password, set it to NULL, and return -ENOMEM.(CVE-2024-50120)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing: Consider the NULL character when validating the event length  strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.  This commit checks this condition and returns failure for it.(CVE-2024-50131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()  build_skb() returns NULL in case of a memory allocation failure so handle it inside __octep_oq_process_rx() to avoid NULL pointer dereference.  __octep_oq_process_rx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn\u0026apos;t break the polling immediately and thus falsely indicate to the octep_napi_poll() that the Rx pressure is going down. As there is no associated skb in this case, don\u0026apos;t process the packets and don\u0026apos;t push them up the network stack - they are skipped.  Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. \u0026apos;alloc_failures\u0026apos; counter is incremented to mark the skb allocation error in driver statistics.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50145)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix possible double free in smb2_set_ea()  Clang static checker(scan-build) warning\uff1a fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.  1304 |         kfree(ea);       |         ^~~~~~~~~  There is a double free in such case: \u0026apos;ea is initialized to NULL\u0026apos; -\u0026gt; \u0026apos;first successful memory allocation for ea\u0026apos; -\u0026gt; \u0026apos;something failed, goto sea_exit\u0026apos; -\u0026gt; \u0026apos;first memory release for ea\u0026apos; -\u0026gt; \u0026apos;goto replay_again\u0026apos; -\u0026gt; \u0026apos;second goto sea_exit before allocate memory for ea\u0026apos; -\u0026gt; \u0026apos;second memory release for ea resulted in double free\u0026apos;.  Re-initialie \u0026apos;ea\u0026apos; to NULL near to the replay_again label, it can fix this double free problem.(CVE-2024-50152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()  If the allocation in msm_disp_state_dump_regs() failed then `block-\u0026gt;state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with:    if (*reg)     dump_addr = *reg;  ...but since \u0026quot;dump_addr\u0026quot; is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`.  Make the function print \u0026quot;Registers not stored\u0026quot; when it sees a NULL to solve this. Since we\u0026apos;re touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`.  Patchwork: https://patchwork.freedesktop.org/patch/619657/(CVE-2024-50156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  virtio_pmem: Check device status before requesting flush  If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang.  So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: explicitly clear the sk pointer, when pf-\u0026gt;create fails  We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\u0026quot;net: do not leave a dangling sk pointer, when socket creation fails\u0026quot;). The problem is that commit did not fully address the problem, as some pf-\u0026gt;create implementations do not use sk_common_release in their error paths.  For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object.  While we could chase all the pf-\u0026gt;create implementations and make sure they NULL the freed sk object on error from the socket, we can\u0026apos;t guarantee future protocols will not make the same mistake.  So it is easier to just explicitly NULL the sk pointer upon return from pf-\u0026gt;create in __sock_create. We do know that pf-\u0026gt;create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.(CVE-2024-50186)",
  "id": "OESA-2024-2423",
  "modified": "2026-08-06T11:07:54Z",
  "published": "2024-11-15T11:07:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2423"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46719"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46803"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46807"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47663"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47702"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50120"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50145"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50152"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50156"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50186"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-46719",
    "CVE-2024-46794",
    "CVE-2024-46803",
    "CVE-2024-46807",
    "CVE-2024-47663",
    "CVE-2024-47668",
    "CVE-2024-47673",
    "CVE-2024-47693",
    "CVE-2024-47702",
    "CVE-2024-47726",
    "CVE-2024-49920",
    "CVE-2024-50082",
    "CVE-2024-50095",
    "CVE-2024-50120",
    "CVE-2024-50131",
    "CVE-2024-50145",
    "CVE-2024-50152",
    "CVE-2024-50156",
    "CVE-2024-50184",
    "CVE-2024-50186"
  ]
}

SUSE-SU-2024:3984-1

Vulnerability from csaf_suse - Published: 2024-11-13 10:13 - Updated: 2026-10-25 17:06

Summary

Security update for the Linux Kernel

Severity

Important

Scope

282 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 51 products

Open the full advisory

SUSE-SU-2024:3986-1

Vulnerability from csaf_suse - Published: 2024-11-13 10:13 - Updated: 2026-11-01 10:32

Summary

Security update for the Linux Kernel

Severity

Important

Scope

268 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 42 products

Open the full advisory

SUSE-SU-2024:4318-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:33 - Updated: 2026-11-01 10:32

Summary

Security update for the Linux Kernel

Severity

Important

Scope

506 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 222 products

Open the full advisory

SUSE-SU-2024:4387-1

Vulnerability from csaf_suse - Published: 2024-12-19 15:39 - Updated: 2026-11-01 10:32

Summary

Security update for the Linux Kernel

Severity

Important

Scope

490 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 8 products

Open the full advisory

SUSE-SU-2025:20163-1

Vulnerability from csaf_suse - Published: 2025-03-27 12:56 - Updated: 2026-11-01 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

507 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 5 products

Open the full advisory

SUSE-SU-2025:20164-1

Vulnerability from csaf_suse - Published: 2025-03-27 15:23 - Updated: 2026-11-01 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

507 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 13 products

Open the full advisory

SUSE-SU-2025:20246-1

Vulnerability from csaf_suse - Published: 2025-03-27 12:56 - Updated: 2026-11-01 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

507 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 8 products

Open the full advisory

SUSE-SU-2025:20247-1

Vulnerability from csaf_suse - Published: 2025-03-27 14:05 - Updated: 2026-11-01 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

507 vulnerabilities in this advisory, including CVE-2024-46803.

CVE-2024-46803

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 19 products

Open the full advisory

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2024-46803 (GCVE-0-2024-46803)

OESA-2024-2423 (CVE-2024-46719)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour