CVE-2024-44954 (GCVE-0-2024-44954)

Vulnerability from cvelistv5 – Published: 2024-09-04 18:35 – Updated: 2026-08-05 11:37

Title

ALSA: line6: Fix racy access to midibuf

Summary

In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.

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-10 17:40 UTC

Assigner

Linux mitre root

References

10 references

URL	Tags
https://git.kernel.org/stable/c/643293b68fbb6c03f…
https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa…
https://git.kernel.org/stable/c/e7e7d2b180d8f297c…
https://git.kernel.org/stable/c/a54da4b787dcac60b…
https://git.kernel.org/stable/c/c80f454a805443c27…
https://git.kernel.org/stable/c/535df7f896a568a8a…
https://git.kernel.org/stable/c/51d87f11dd199bbc6…
https://git.kernel.org/stable/c/15b7a03205b31bc56…
https://lists.debian.org/debian-lts-announce/2025…
https://lists.debian.org/debian-lts-announce/2024…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < 643293b68fbb6c03f5e907736498da17d43f0d81 (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < 40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5 (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < e7e7d2b180d8f297cea6db43ea72402fd33e1a29 (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < a54da4b787dcac60b598da69c9c0072812b8282d (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < c80f454a805443c274394b1db0d1ebf477abd94e (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < 535df7f896a568a8a1564114eaea49d002cb1747 (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < 51d87f11dd199bbc6a85982b088ff27bde53b48a (git) Affected: 705ececd1c60d0f5d6ef2a719008847883516970 , < 15b7a03205b31bc5623378c190d22b7ff60026f1 (git)	guessed
Linux	Linux	Affected: 2.6.30 Unaffected: 0 , < 2.6.30 (semver) Unaffected: 4.19.320 , ≤ 4.19.* (semver) Unaffected: 5.4.282 , ≤ 5.4.* (semver) Unaffected: 5.10.224 , ≤ 5.10.* (semver) Unaffected: 5.15.165 , ≤ 5.15.* (semver) Unaffected: 6.1.105 , ≤ 6.1.* (semver) Unaffected: 6.6.46 , ≤ 6.6.* (semver) Unaffected: 6.10.5 , ≤ 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-44954",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:40:10.329711Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-12T17:33:34.296Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T22:14:04.124Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          },
          {
            "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "sound/usb/line6/driver.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "643293b68fbb6c03f5e907736498da17d43f0d81",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "e7e7d2b180d8f297cea6db43ea72402fd33e1a29",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "a54da4b787dcac60b598da69c9c0072812b8282d",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "c80f454a805443c274394b1db0d1ebf477abd94e",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "535df7f896a568a8a1564114eaea49d002cb1747",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "51d87f11dd199bbc6a85982b088ff27bde53b48a",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "15b7a03205b31bc5623378c190d22b7ff60026f1",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "sound/usb/line6/driver.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.30"
            },
            {
              "lessThan": "2.6.30",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.320",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.282",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.224",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.165",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.105",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.46",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.5",
              "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": "4.19.320",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.282",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.224",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.165",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.105",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.46",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.5",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races."
        }
      ],
      "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 unsynchronized accesses are in `line6_data_received()` (URB completion for the control/MIDI-in endpoint) racing the rawmidi API path, and the driver is only bound when a Line 6 device is already attached \u2014 so a local unprivileged user on such a host drives both halves via `/dev/snd/midiC*D*` (and the hwdep node), writing MIDI/sysex to solicit device replies that generate URB completions while concurrently hammering rawmidi read/trigger. No physical access by the attacker is needed in that deployment (audio workstation, live-performance rig).\nAC:L - The attacker controls both sides of the race \u2014 one thread issues rawmidi/hwdep writes that make the device respond on the interrupt-in endpoint, another thread concurrently exercises the rawmidi API \u2014 and the window can be retried indefinitely at MIDI packet rate. Per the guidance, a race whose both sides the attacker creates is Low.\nPR:L - Only ordinary access to the ALSA rawmidi/hwdep character devices is required, which the console/desktop user gets by default through udev ACLs or `audio` group membership. No CAP_SYS_ADMIN or root is needed.\nUI:N - The attacker performs every step itself \u2014 opening the rawmidi node, soliciting device traffic, and racing the accesses. Presence of the Line 6 device is a property of the affected system (the driver does not load otherwise), not a victim action during the attack.\nS:U - The corrupted ring-buffer state, the heap over-read, and the disclosed data all live in the kernel\u0027s own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - syzbot confirmed \"KMSAN: uninit-value in line6_midibuf_read\" at `midibuf.c:185` \u2014 racy `pos_read`/`pos_write`/`full` make the reader consume bytes never written, so stale contents of the `kmalloc()`ed 1024-byte `midi_buffer.buf` slab object are memcpy\u0027d into `line6-\u003ebuffer_message` and delivered to userspace through `snd_rawmidi_receive()`. A stale `length1 = size - pos_write`/`pos_read` pair also lets the copy index past the end of that allocation, and the leak is repeatable, allowing kernel heap contents (pointers, recycled data) to be harvested.\nI:H - `line6_midibuf_write()` computes `length1 = this-\u003esize - this-\u003epos_write` and then does `memcpy(this-\u003ebuf + this-\u003epos_write, data, length1)` re-reading `pos_write`; with no lock, a concurrent index update makes that copy run past the end of the kmalloc-1024 object with device-supplied MIDI bytes, giving an attacker-influenced heap out-of-bounds write, and corrupted indices also feed bogus data into the rawmidi stream.\nA:H - Out-of-bounds reads and writes on the kmalloc-1024 slab object corrupt adjacent allocations and trip sanitizer/hardening checks, producing oops or panic. The bug is a memory-safety error, which per the guidance is High availability impact."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:37:18.083Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81"
        },
        {
          "url": "https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5"
        },
        {
          "url": "https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"
        },
        {
          "url": "https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d"
        },
        {
          "url": "https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e"
        },
        {
          "url": "https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747"
        },
        {
          "url": "https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a"
        },
        {
          "url": "https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1"
        }
      ],
      "title": "ALSA: line6: Fix racy access to midibuf",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-44954",
    "datePublished": "2024-09-04T18:35:53.730Z",
    "dateReserved": "2024-08-21T05:34:56.666Z",
    "dateUpdated": "2026-08-05T11:37:18.083Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-44954",
      "date": "2026-09-19",
      "epss": "0.00179",
      "percentile": "0.07761"
    },
    "microsoft_vex": {
      "current_release_date": "2026-02-18T14:04:50.000Z",
      "cve": "CVE-2024-44954",
      "id": "msrc_CVE-2024-44954",
      "initial_release_date": "2024-09-01T07:00:00.000Z",
      "product_status:fixed": "3",
      "product_status:known_affected": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "ALSA: line6: Fix racy access to midibuf",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-44954.json",
      "version": "2"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "sound/usb/line6/driver.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "643293b68fbb6c03f5e907736498da17d43f0d81",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "e7e7d2b180d8f297cea6db43ea72402fd33e1a29",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "a54da4b787dcac60b598da69c9c0072812b8282d",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "c80f454a805443c274394b1db0d1ebf477abd94e",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "535df7f896a568a8a1564114eaea49d002cb1747",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "51d87f11dd199bbc6a85982b088ff27bde53b48a",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "15b7a03205b31bc5623378c190d22b7ff60026f1",
                    "status": "affected",
                    "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "sound/usb/line6/driver.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "2.6.30"
                  },
                  {
                    "lessThan": "2.6.30",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.320",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.282",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.224",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.165",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.105",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.46",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.10.*",
                    "status": "unaffected",
                    "version": "6.10.5",
                    "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": "0B4EF915-550B-45E5-B2CA-648FEACD60FC",
                    "versionEndExcluding": "4.19.320",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "21D0A18B-9B7E-4C59-A2A6-8A94BBA4E0FD",
                    "versionEndExcluding": "5.4.282",
                    "versionStartExcluding": "4.20",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "5CCEDF13-293D-4E64-B501-4409D0365AFE",
                    "versionEndExcluding": "5.10.224",
                    "versionStartIncluding": "5.5",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "87C7E3B8-B82C-459E-AE23-FFE2D952481F",
                    "versionEndExcluding": "5.15.165",
                    "versionStartExcluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "89BEB24B-0F37-4C92-A397-564DA7CD8EE9",
                    "versionEndExcluding": "6.1.105",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FA11941E-81FB-484C-B583-881EEB488340",
                    "versionEndExcluding": "6.6.46",
                    "versionStartIncluding": "6.2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "D074AE50-4A5E-499C-A2FD-75FD60DEA560",
                    "versionEndExcluding": "6.10.5",
                    "versionStartIncluding": "6.7",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*",
                    "matchCriteriaId": "8B3CE743-2126-47A3-8B7C-822B502CF119",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*",
                    "matchCriteriaId": "4DEB27E7-30AA-45CC-8934-B89263EF3551",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: line6: Fix racy access to midibuf Puede haber accesos concurrentes a midibuf de line6 tanto desde la devoluci\u00f3n de llamada de finalizaci\u00f3n de URB como desde el acceso a la API rawmidi. Esto podr\u00eda ser la causa de la advertencia KMSAN activada por syzkaller a continuaci\u00f3n (as\u00ed que se indica aqu\u00ed). Este parche protege la llamada midibuf de la ruta de c\u00f3digo anterior con un spinlock para evitar las posibles ejecuciones."
          }
        ],
        "id": "CVE-2024-44954",
        "lastModified": "2026-08-04T11:20:03.913",
        "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": "HIGH",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 4.7,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.0,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-44954",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:40:10.329711Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-09-04T19:15:30.353",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-362"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-04T18:18:02+00:00",
      "cve": "CVE-2024-44954",
      "id": "CVE-2024-44954",
      "initial_release_date": "2024-09-04T00:00:00+00:00",
      "product_status:known_affected": "184",
      "product_status:known_not_affected": "14",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: ALSA: line6: Fix racy access to midibuf",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-44954.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2025-11-03T22:14:04.124Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
              },
              {
                "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-44954",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T17:40:10.329711Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:24.811Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "sound/usb/line6/driver.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "643293b68fbb6c03f5e907736498da17d43f0d81",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "e7e7d2b180d8f297cea6db43ea72402fd33e1a29",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "a54da4b787dcac60b598da69c9c0072812b8282d",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "c80f454a805443c274394b1db0d1ebf477abd94e",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "535df7f896a568a8a1564114eaea49d002cb1747",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "51d87f11dd199bbc6a85982b088ff27bde53b48a",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                },
                {
                  "lessThan": "15b7a03205b31bc5623378c190d22b7ff60026f1",
                  "status": "affected",
                  "version": "705ececd1c60d0f5d6ef2a719008847883516970",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "sound/usb/line6/driver.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "2.6.30"
                },
                {
                  "lessThan": "2.6.30",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.320",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.282",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.224",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.165",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.105",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.46",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.10.*",
                  "status": "unaffected",
                  "version": "6.10.5",
                  "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": "4.19.320",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.4.282",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.10.224",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.15.165",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.1.105",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.46",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.10.5",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.11",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-05-11T20:32:40.110Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81"
            },
            {
              "url": "https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5"
            },
            {
              "url": "https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"
            },
            {
              "url": "https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d"
            },
            {
              "url": "https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e"
            },
            {
              "url": "https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747"
            },
            {
              "url": "https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a"
            },
            {
              "url": "https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1"
            }
          ],
          "title": "ALSA: line6: Fix racy access to midibuf",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-44954",
        "datePublished": "2024-09-04T18:35:53.730Z",
        "dateReserved": "2024-08-21T05:34:56.666Z",
        "dateUpdated": "2026-05-11T20:32:40.110Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2024-44954

Vulnerability from fkie_nvd - Published: 2024-09-04 19:15 - Updated: 2026-08-04 11:20

Severity

7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.7 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Summary

References

URL	Tags
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29	Patch
af854a3a-2127-422b-91ae-364da2661108	https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
af854a3a-2127-422b-91ae-364da2661108	https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

Impacted products

Vendor	Product	Version
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	6.11
linux	linux_kernel	6.11

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "sound/usb/line6/driver.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "643293b68fbb6c03f5e907736498da17d43f0d81",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "e7e7d2b180d8f297cea6db43ea72402fd33e1a29",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "a54da4b787dcac60b598da69c9c0072812b8282d",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "c80f454a805443c274394b1db0d1ebf477abd94e",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "535df7f896a568a8a1564114eaea49d002cb1747",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "51d87f11dd199bbc6a85982b088ff27bde53b48a",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            },
            {
              "lessThan": "15b7a03205b31bc5623378c190d22b7ff60026f1",
              "status": "affected",
              "version": "705ececd1c60d0f5d6ef2a719008847883516970",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "sound/usb/line6/driver.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.30"
            },
            {
              "lessThan": "2.6.30",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.320",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.282",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.224",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.165",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.105",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.46",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.5",
              "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": "0B4EF915-550B-45E5-B2CA-648FEACD60FC",
              "versionEndExcluding": "4.19.320",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "21D0A18B-9B7E-4C59-A2A6-8A94BBA4E0FD",
              "versionEndExcluding": "5.4.282",
              "versionStartExcluding": "4.20",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "5CCEDF13-293D-4E64-B501-4409D0365AFE",
              "versionEndExcluding": "5.10.224",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "87C7E3B8-B82C-459E-AE23-FFE2D952481F",
              "versionEndExcluding": "5.15.165",
              "versionStartExcluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "89BEB24B-0F37-4C92-A397-564DA7CD8EE9",
              "versionEndExcluding": "6.1.105",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "FA11941E-81FB-484C-B583-881EEB488340",
              "versionEndExcluding": "6.6.46",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D074AE50-4A5E-499C-A2FD-75FD60DEA560",
              "versionEndExcluding": "6.10.5",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "8B3CE743-2126-47A3-8B7C-822B502CF119",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*",
              "matchCriteriaId": "4DEB27E7-30AA-45CC-8934-B89263EF3551",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: line6: Fix racy access to midibuf Puede haber accesos concurrentes a midibuf de line6 tanto desde la devoluci\u00f3n de llamada de finalizaci\u00f3n de URB como desde el acceso a la API rawmidi. Esto podr\u00eda ser la causa de la advertencia KMSAN activada por syzkaller a continuaci\u00f3n (as\u00ed que se indica aqu\u00ed). Este parche protege la llamada midibuf de la ruta de c\u00f3digo anterior con un spinlock para evitar las posibles ejecuciones."
    }
  ],
  "id": "CVE-2024-44954",
  "lastModified": "2026-08-04T11:20:03.913",
  "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": "HIGH",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 4.7,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.0,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-44954",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T17:40:10.329711Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-09-04T19:15:30.353",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-362"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-GH37-H7XR-7HJ2

Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-11-04 00:31

Details

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

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.

Severity

4.7 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-44954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T19:15:30Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: line6: Fix racy access to midibuf\n\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\n\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.",
  "id": "GHSA-gh37-h7xr-7hj2",
  "modified": "2025-11-04T00:31:20Z",
  "published": "2024-09-04T21:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

ICSA-25-226-07

Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00

Summary

Siemens Third-Party Components in SINEC OS

Scope

486 vulnerabilities in this advisory, including CVE-2024-44954.

CVE-2024-44954

Known not affected: 3 products

Open the full advisory

MSRC_CVE-2024-44954

Vulnerability from csaf_microsoft - Published: 2024-09-01 07:00 - Updated: 2026-02-18 14:04

Summary

ALSA: line6: Fix racy access to midibuf

Scope

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

CVE-2024-44954

Fixed: 3 products Known affected: 3 products

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

Open the full advisory

OESA-2024-2181 (CVE-2024-36904)

Vulnerability from osv_openeuler – Published: 2024-09-27 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:

tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().

Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.

To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.

[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfxinetcheck_established+0x10/0x10 tcp_v4_connect+0x278/0x530 inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)

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

drm/amdgpu: change vm->task_info handling

This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.

This patch also does logistical changes required for existing usage of vm->task_info.

V2: Do not block all the prints when task_info not found (Felix)

V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()

V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)

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

drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing

This commit adds null checks for the 'stream' and 'plane' variables in the dcn30_apply_idle_power_optimizations function. These variables were previously assumed to be null at line 922, but they were used later in the code without checking if they were null. This could potentially lead to a null pointer dereference, which would cause a crash.

The null checks ensure that 'stream' and 'plane' are not null before they are used, preventing potential crashes.

Fixes the below static smatch checker: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922)(CVE-2024-43904)

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

ALSA: line6: Fix racy access to midibuf

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

tracefs: Use generic inode RCU for synchronizing freeing

With structure layout randomization enabled for 'struct inode' we need to avoid overlapping any of the RCU-used / initialized-only-once members, e.g. i_lru or i_sb_list to not corrupt related list traversals when making use of the rcu_head.

For an unlucky structure layout of 'struct inode' we may end up with the following splat when running the ftrace selftests:

[<...>] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object]) [<...>] ------------[ cut here ]------------ [<...>] kernel BUG at lib/list_debug.c:54! [<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65 [<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [<...>] RIP: 0010:[<ffffffff84656018>] list_del_entry_valid_or_report+0x138/0x3e0 [<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f [<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283 [<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000 [<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001 [<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25 [<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d [<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000 [<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object] [<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0 [<...>] RSI: __func.47+0x4340/0x4400 [<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object] [<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550] [<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550] [<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550] [<...>] R14: tracefs_inode_cache+0x78/0x4e0 [slab object] [<...>] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000 [<...>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0 [<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [<...>] ASID: 0003 [<...>] Stack: [<...>] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0 [<...>] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f [<...>] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392 [<...>] Call Trace: [<...>] <TASK> [<...>] [<ffffffff818a2315>] ? lock_release+0x175/0x380 fffffe80416afaf0 [<...>] [<ffffffff8248b392>] list_lru_del+0x152/0x740 fffffe80416afb48 [<...>] [<ffffffff8248ba93>] list_lru_del_obj+0x113/0x280 fffffe80416afb88 [<...>] [<ffffffff8940fd19>] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90 [<...>] [<ffffffff8295b244>] iput_final+0x1c4/0x9a0 fffffe80416afbb8 [<...>] [<ffffffff8293a52b>] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8 [<...>] [<ffffffff8293fefc>] __dentry_kill+0x23c/0xf00 fffffe80416afc40 [<...>] [<ffffffff8953a85f>] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48 [<...>] [<ffffffff82949ce5>] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70 [<...>] [<ffffffff82949b71>] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78 [<...>] [<ffffffff82949da8>] shrink_dentry_list+0x288/0x760 fffffe80416afc80 [<...>] [<ffffffff8294ae75>] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8 [<...>] [<ffffffff8953a7c3>] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0 [<...>] [<ffffffff8294ad20>] ? do_one_tre ---truncated---(CVE-2024-44959)

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

Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading

When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.

panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c _dosoftirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---(CVE-2024-44962)

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

x86/mm: Fix pti_clone_pgtable() alignment assumption

Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then

DF from the stack guard.

It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.

These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?

Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)

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

drm/mgag200: Bind I2C lifetime to DRM device

Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.(CVE-2024-44967)

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

s390/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.

Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)

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

mptcp: pm: avoid possible UaF when selecting endp

select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.

A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)

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

bnxt_en: Fix double DMA unmapping for XDP_REDIRECT

Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:

WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0(CVE-2024-44984)

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

tcp: prevent concurrent execution of tcp_sk_exit_batch

Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns.

tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list.

This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns.

This allows the netns exit worker to proceed to call

WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));

without the expected 1 -> 0 transition, which then splats.

At same time, error unwind path that is also running inet_twsk_purge() will splat as well:

WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110

... because refcount_dec() of tw_refcount unexpectedly dropped to 0.

This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check.

Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns.(CVE-2024-44991)

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

iommu: Restore lost return in iommu_report_device_fault()

When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return.

Instead the return was accidently deleted which results in trying to process the fault and an eventual crash.

Deleting the return was a typo, put it back.(CVE-2024-44994)

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

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)

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

vsock: fix recursive ->recvmsg calls

After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen:

vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again

We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg().(CVE-2024-44996)

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

gtp: pull network headers in gtp_dev_xmit()

syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.

Use pskb_inet_may_pull() to fix this issue.

[1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)

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

fs/netfs/fscache_cookie: add missing "n_accesses" check

This fixes a NULL pointer dereference bug due to a data race which looks like this:

BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 worker_thread+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Modules linked in: CR2: 0000000000000008 ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was still running while another process invoked fscache_unuse_cookie(); this led to a fscache_cookie_lru_do_one() call, setting the FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by fscache_cookie_state_machine(), withdrawing the cookie via cachefiles_withdraw_cookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked cachefiles_prepare_write(), which found a NULL pointer in this code line:

struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

struct cachefiles_cache *cache = object->volume->cache;

During cachefiles_prepare_write(), the "n_accesses" counter is non-zero (via fscache_begin_operation()). The cookie must not be withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before switching to FSCACHE_COOKIE_STATE_RELINQUISHING and FSCACHE_COOKIE_STATE_WITHDRAWING (in "case FSCACHE_COOKIE_STATE_FAILED"), but not for FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check. With a non-zero access counter, the function returns and the next fscache_end_cookie_access() call will queue another fscache_cookie_state_machine() call to handle the still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.(CVE-2024-45000)

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

rtla/osnoise: Prevent NULL dereference in error handling

If the "tool->data" allocation fails then there is no need to call osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.(CVE-2024-45002)

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

vfs: Don't evict inode under the inode lru traversing context

The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.

Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:

File A has inode i_reg and an ea inode i_ea
getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
Then, following three processes running like this:

PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state)

Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:

File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
Then, following three processes running like this:
```
PA                PB                        PC
        echo 2 &gt; /proc/sys/vm/drop_caches
         shrink_slab
          prune_dcache_sb
          // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia
          prune_icache_sb
           list_lru_walk_one
            inode_lru_isolate
             ixa-&gt;i_state |= I_FREEING // set inode state
            inode_lru_isolate
             __iget(ib)
             spin_unlock(&amp;ib-&gt;i_lock)
             spin_unlock(lru_lock)
                                           rm file B
                                            ib-&gt;nlink = 0
```
rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state)

Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---(CVE-2024-45003)

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

Input: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

net/mlx5e: Take state lock during tx timeout reporter

mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag.(CVE-2024-45019)

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

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, if all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied.

For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe.

Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first.

new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)

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

btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()

[BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace:

BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20

Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause.

The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio.

This means a double freeing thus causing use-after-free, e.g.:

Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes.
The first run of btrfs_submit_chunk()

2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted.

The second run of btrfs_submit_chunk()

3.1 Call btrfs_map_block(), which by somehow failed Now we call btrfs_bio_end_io() to handle the error

3.2 btrfs_bio_end_io() calls the original endio function Which is end_bbio_data_read(), and it calls bio_put() for the original bio.

Now the original bio is freed.

The submitted first 64K bio finished Now we call into btrfs_check_read_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free.

And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing.

[FIX] Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(), which has the extra check on split bios and do the pr ---truncated---(CVE-2024-46687)

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

tty: serial: fsl_lpuart: mark last busy before uart_add_one_port

With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT.

The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add |-> bus_probe_device |->device_initial_probe |->__device_attach |-> pm_runtime_get_sync(dev->parent); |-> pm_request_idle(dev); |-> pm_runtime_put(dev->parent);

So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang.

To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console.(CVE-2024-46706)

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

drm/amd/display: Skip wbscl_set_scaler_filter if filter is null

Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case.

This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)

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

drm/amdgpu: fix dereference after null check

check the pointer hive before use.(CVE-2024-46720)

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

drm/amdgpu: fix ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)

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

drm/amd/pm: fix the Out-of-bounds read warning

using index i - 1U may beyond element index for mc_data[] when i = 0.(CVE-2024-46731)

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

btrfs: fix qgroup reserve leaks in cow_file_range

In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.

Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.

This results in failures at the unmount stage of the test that look like:

BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked

Cases 2 and 3 in the out_reserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfs_free_qgroup_data.(CVE-2024-46733)

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

smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()

null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) and parse_lease_state() return NULL.

Fix this by check if 'lease_ctx_info' is NULL.

Additionally, remove the redundant parentheses in parse_durable_handle_context().(CVE-2024-46742)

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

Squashfs: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:

squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.
Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.
The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic link size is not larger than expected.

V2: fix spelling mistake.(CVE-2024-46744)

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

Input: uinput - reject requests with unreasonable number of slots

When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)

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

HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup

report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)

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

btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()

Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.(CVE-2024-46751)

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

btrfs: replace BUG_ON() with error handling at update_ref_for_cow()

Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).(CVE-2024-46752)

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

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)

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

eventfs: Use list_del_rcu() for SRCU protected list variable

Chi Zhiling reported:

We found a null pointer accessing in tracefs[1], the reason is that the variable 'ei_child' is set to LIST_POISON1, that means the list was removed in eventfs_remove_rec. so when access the ei_child->is_freed, the panic triggered.

by the way, the following script can reproduce this panic

loop1 (){ while true do echo "p:kp submit_bio" > /sys/kernel/debug/tracing/kprobe_events echo "" > /sys/kernel/debug/tracing/kprobe_events done } loop2 (){ while true do tree /sys/kernel/debug/tracing/events/kprobes/ done } loop1 & loop2

[1]: [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150 [ 1147.968239][T17331] Mem abort info: [ 1147.971739][T17331] ESR = 0x0000000096000004 [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1147.982171][T17331] SET = 0, FnV = 0 [ 1147.985906][T17331] EA = 0, S1PTW = 0 [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault [ 1147.995292][T17331] Data abort info: [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls] [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2 [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650 [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020 [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398 [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398 [ 1148.115969][T17331] sp : ffff80008d56bbd0 [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000 [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100 [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10 [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000 [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0 [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0 [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862 [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068 [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001 [ 1148.198131][T17331] Call trace: [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398 [ 1148.205864][T17331] iterate_dir+0x98/0x188 [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160 [ 1148.215161][T17331] invoke_syscall+0x78/0x108 [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0 [ 1148.224977][T17331] do_el0_svc+0x24/0x38 [ 1148.228974][T17331] el0_svc+0x40/0x168 [ 1148.232798][T17 ---truncated---(CVE-2024-46785)

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

fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF

The fscache_cookie_lru_timer is initialized when the fscache module is inserted, but is not deleted when the fscache module is removed. If timer_reduce() is called before removing the fscache module, the fscache_cookie_lru_timer will be added to the timer list of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the fscache module, as follows:

================================================================== BUG: unable to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: <IRQ> tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 </TASK> Modules linked in: [last unloaded: netfs] ==================================================================

Therefore delete fscache_cookie_lru_timer when removing the fscahe module.(CVE-2024-46786)

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

sch/netem: fix use after free in netem_dequeue

If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails")

Commands to trigger KASAN UaF:

ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF(CVE-2024-46800)

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-36904	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41008	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43904	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44954	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44959	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44962	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44965	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44967	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44969	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44974	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44984	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44991	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44994	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44995	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44996	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44999	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45000	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45002	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45003	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45008	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45019	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45025	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46687	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46706	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46714	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46720	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46723	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46731	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46733	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46742	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46744	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46745	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46747	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46751	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46752	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46759	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46785	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46786	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46800	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "perf-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-44.0.0.50.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "perf-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-44.0.0.50.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-44.0.0.50.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\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n  reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n    - amdgpu_vm_get_task_info: reference counts up task_info before\n      returning this info\n    - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n   - Fix wrong indentation\n   - No debug message for -ENOMEM\n   - Add NULL check for task_info\n   - Do not duplicate the debug messages (ti vs no ti)\n   - Get first reference of task_info in vm_init(), put last\n     in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n   - fix double reference increment in create_task_info\n   - change amdgpu_vm_get_task_info_pasid\n   - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checks for \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; before dereferencing\r\n\r\nThis commit adds null checks for the \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; variables in\nthe dcn30_apply_idle_power_optimizations function. These variables were\npreviously assumed to be null at line 922, but they were used later in\nthe code without checking if they were null. This could potentially lead\nto a null pointer dereference, which would cause a crash.\r\n\r\nThe null checks ensure that \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; are not null before\nthey are used, preventing potential crashes.\r\n\r\nFixes the below static smatch checker:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed \u0026apos;stream\u0026apos; could be null (see line 922)\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed \u0026apos;plane\u0026apos; could be null (see line 922)(CVE-2024-43904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracefs: Use generic inode RCU for synchronizing freeing\r\n\r\nWith structure layout randomization enabled for \u0026apos;struct inode\u0026apos; we need to\navoid overlapping any of the RCU-used / initialized-only-once members,\ne.g. i_lru or i_sb_list to not corrupt related list traversals when making\nuse of the rcu_head.\r\n\r\nFor an unlucky structure layout of \u0026apos;struct inode\u0026apos; we may end up with the\nfollowing splat when running the ftrace selftests:\r\n\r\n[\u0026lt;...\u0026gt;] list_del corruption, ffff888103ee2cb0-\u0026gt;next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])\n[\u0026lt;...\u0026gt;] ------------[ cut here ]------------\n[\u0026lt;...\u0026gt;] kernel BUG at lib/list_debug.c:54!\n[\u0026lt;...\u0026gt;] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[\u0026lt;...\u0026gt;] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65\n[\u0026lt;...\u0026gt;] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n[\u0026lt;...\u0026gt;] RIP: 0010:[\u0026lt;ffffffff84656018\u0026gt;] __list_del_entry_valid_or_report+0x138/0x3e0\n[\u0026lt;...\u0026gt;] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff \u0026lt;0f\u0026gt; 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f\n[\u0026lt;...\u0026gt;] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283\n[\u0026lt;...\u0026gt;] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000\n[\u0026lt;...\u0026gt;] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001\n[\u0026lt;...\u0026gt;] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25\n[\u0026lt;...\u0026gt;] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d\n[\u0026lt;...\u0026gt;] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000\n[\u0026lt;...\u0026gt;] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] RDX: __list_del_entry_valid_or_report+0x108/0x3e0\n[\u0026lt;...\u0026gt;] RSI: __func__.47+0x4340/0x4400\n[\u0026lt;...\u0026gt;] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000\n[\u0026lt;...\u0026gt;] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[\u0026lt;...\u0026gt;] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0\n[\u0026lt;...\u0026gt;] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[\u0026lt;...\u0026gt;] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[\u0026lt;...\u0026gt;] ASID: 0003\n[\u0026lt;...\u0026gt;] Stack:\n[\u0026lt;...\u0026gt;]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0\n[\u0026lt;...\u0026gt;]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f\n[\u0026lt;...\u0026gt;]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392\n[\u0026lt;...\u0026gt;] Call Trace:\n[\u0026lt;...\u0026gt;]  \u0026lt;TASK\u0026gt;\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff818a2315\u0026gt;] ? lock_release+0x175/0x380 fffffe80416afaf0\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8248b392\u0026gt;] list_lru_del+0x152/0x740 fffffe80416afb48\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8248ba93\u0026gt;] list_lru_del_obj+0x113/0x280 fffffe80416afb88\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8940fd19\u0026gt;] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8295b244\u0026gt;] iput_final+0x1c4/0x9a0 fffffe80416afbb8\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8293a52b\u0026gt;] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8293fefc\u0026gt;] __dentry_kill+0x23c/0xf00 fffffe80416afc40\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8953a85f\u0026gt;] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff82949ce5\u0026gt;] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff82949b71\u0026gt;] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff82949da8\u0026gt;] shrink_dentry_list+0x288/0x760 fffffe80416afc80\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8294ae75\u0026gt;] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8953a7c3\u0026gt;] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0\n[\u0026lt;...\u0026gt;]  [\u0026lt;ffffffff8294ad20\u0026gt;] ? do_one_tre\n---truncated---(CVE-2024-44959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading\r\n\r\nWhen unload the btnxpuart driver, its associated timer will be deleted.\nIf the timer happens to be modified at this moment, it leads to the\nkernel call this timer even after the driver unloaded, resulting in\nkernel panic.\nUse timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.\r\n\r\npanic log:\n  Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n  Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic   snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil   snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded:   btnxpuart]\n  CPU: 5 PID: 723 Comm: memtester Tainted: G           O       6.6.23-lts-next-06207-g4aef2658ac28 #1\n  Hardware name: NXP i.MX95 19X19 board (DT)\n  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : 0xffff80007a2cf464\n  lr : call_timer_fn.isra.0+0x24/0x80\n...\n  Call trace:\n   0xffff80007a2cf464\n   __run_timers+0x234/0x280\n   run_timer_softirq+0x20/0x40\n   __do_softirq+0x100/0x26c\n   ____do_softirq+0x10/0x1c\n   call_on_irq_stack+0x24/0x4c\n   do_softirq_own_stack+0x1c/0x2c\n   irq_exit_rcu+0xc0/0xdc\n   el0_interrupt+0x54/0xd8\n   __el0_irq_handler_common+0x18/0x24\n   el0t_64_irq_handler+0x10/0x1c\n   el0t_64_irq+0x190/0x194\n  Code: ???????? ???????? ???????? ???????? (????????)\n  ---[ end trace 0000000000000000 ]---\n  Kernel panic - not syncing: Oops: Fatal exception in interrupt\n  SMP: stopping secondary CPUs\n  Kernel Offset: disabled\n  CPU features: 0x0,c0000000,40028143,1000721b\n  Memory Limit: none\n  ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---(CVE-2024-44962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mgag200: Bind I2C lifetime to DRM device\r\n\r\nManaged cleanup with devm_add_action_or_reset() will release the I2C\nadapter when the underlying Linux device goes away. But the connector\nstill refers to it, so this cleanup leaves behind a stale pointer\nin struct drm_connector.ddc.\r\n\r\nBind the lifetime of the I2C adapter to the connector\u0026apos;s lifetime by\nusing DRM\u0026apos;s managed release. When the DRM device goes away (after\nthe Linux device) DRM will first clean up the connector and then\nclean up the I2C adapter.(CVE-2024-44967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Prevent release of buffer in I/O\r\n\r\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\r\n\r\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: avoid possible UaF when selecting endp\r\n\r\nselect_local_address() and select_signal_address() both select an\nendpoint entry from the list inside an RCU protected section, but return\na reference to it, to be read later on. If the entry is dereferenced\nafter the RCU unlock, reading info could cause a Use-after-Free.\r\n\r\nA simple solution is to copy the required info while inside the RCU\nprotected section to avoid any risk of UaF later. The address ID might\nneed to be modified later to handle the ID0 case later, so a copy seems\nOK to deal with.(CVE-2024-44974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_en: Fix double DMA unmapping for XDP_REDIRECT\r\n\r\nRemove the dma_unmap_page_attrs() call in the driver\u0026apos;s XDP_REDIRECT\ncode path.  This should have been removed when we let the page pool\nhandle the DMA mapping.  This bug causes the warning:\r\n\r\nWARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100\nCPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G        W          6.8.0-1010-gcp #11-Ubuntu\nHardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024\nRIP: 0010:iommu_dma_unmap_page+0xd5/0x100\nCode: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9\nRSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c\nR10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000\nR13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002\nFS:  0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0\n? show_regs+0x6d/0x80\n? __warn+0x89/0x150\n? iommu_dma_unmap_page+0xd5/0x100\n? report_bug+0x16a/0x190\n? handle_bug+0x51/0xa0\n? exc_invalid_op+0x18/0x80\n? iommu_dma_unmap_page+0xd5/0x100\n? iommu_dma_unmap_page+0x35/0x100\ndma_unmap_page_attrs+0x55/0x220\n? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f\nbnxt_rx_xdp+0x237/0x520 [bnxt_en]\nbnxt_rx_pkt+0x640/0xdd0 [bnxt_en]\n__bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]\nbnxt_poll+0xaa/0x1e0 [bnxt_en]\n__napi_poll+0x33/0x1e0\nnet_rx_action+0x18a/0x2f0(CVE-2024-44984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: prevent concurrent execution of tcp_sk_exit_batch\r\n\r\nIts possible that two threads call tcp_sk_exit_batch() concurrently,\nonce from the cleanup_net workqueue, once from a task that failed to clone\na new netns.  In the latter case, error unwinding calls the exit handlers\nin reverse order for the \u0026apos;failed\u0026apos; netns.\r\n\r\ntcp_sk_exit_batch() calls tcp_twsk_purge().\nProblem is that since commit b099ce2602d8 (\u0026quot;net: Batch inet_twsk_purge\u0026quot;),\nthis function picks up twsk in any dying netns, not just the one passed\nin via exit_batch list.\r\n\r\nThis means that the error unwind of setup_net() can \u0026quot;steal\u0026quot; and destroy\ntimewait sockets belonging to the exiting netns.\r\n\r\nThis allows the netns exit worker to proceed to call\r\n\r\nWARN_ON_ONCE(!refcount_dec_and_test(\u0026amp;net-\u0026gt;ipv4.tcp_death_row.tw_refcount));\r\n\r\nwithout the expected 1 -\u0026gt; 0 transition, which then splats.\r\n\r\nAt same time, error unwind path that is also running inet_twsk_purge()\nwill splat as well:\r\n\r\nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210\n...\n refcount_dec include/linux/refcount.h:351 [inline]\n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70\n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221\n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304\n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n setup_net+0x714/0xb40 net/core/net_namespace.c:375\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\r\n\r\n... because refcount_dec() of tw_refcount unexpectedly dropped to 0.\r\n\r\nThis doesn\u0026apos;t seem like an actual bug (no tw sockets got lost and I don\u0026apos;t\nsee a use-after-free) but as erroneous trigger of debug check.\r\n\r\nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge()\nblocks other task from doing final _dec_and_test before mutex-owner has\nremoved all tw sockets of dying netns.(CVE-2024-44991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Restore lost return in iommu_report_device_fault()\r\n\r\nWhen iommu_report_device_fault gets called with a partial fault it is\nsupposed to collect the fault into the group and then return.\r\n\r\nInstead the return was accidently deleted which results in trying to\nprocess the fault and an eventual crash.\r\n\r\nDeleting the return was a typo, put it back.(CVE-2024-44994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 \u2502\n                                 \u25bc\n                              ......\nsetup tc                         \u2502\n    \u2502                            \u25bc\n    \u25bc                      DOWN: napi_disable()\nnapi_disable()(skip)             \u2502\n    \u2502                            \u2502\n    \u25bc                            \u25bc\n  ......                      ......\n    \u2502                            \u2502\n    \u25bc                            \u2502\nnapi_enable()                    \u2502\n                                 \u25bc\n                           UINIT: netif_napi_del()\n                                 \u2502\n                                 \u25bc\n                              ......\n                                 \u2502\n                                 \u25bc\n                           INIT: netif_napi_add()\n                                 \u2502\n                                 \u25bc\n                              ......                 global reset start\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                           UP: napi_enable()(skip)    ......\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                              ......                 napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvsock: fix recursive -\u0026gt;recvmsg calls\r\n\r\nAfter a vsock socket has been added to a BPF sockmap, its prot-\u0026gt;recvmsg\nhas been replaced with vsock_bpf_recvmsg(). Thus the following\nrecursiion could happen:\r\n\r\nvsock_bpf_recvmsg()\n -\u0026gt; __vsock_recvmsg()\n  -\u0026gt; vsock_connectible_recvmsg()\n   -\u0026gt; prot-\u0026gt;recvmsg()\n    -\u0026gt; vsock_bpf_recvmsg() again\r\n\r\nWe need to fix it by calling the original -\u0026gt;recvmsg() without any BPF\nsockmap logic in __vsock_recvmsg().(CVE-2024-44996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/netfs/fscache_cookie: add missing \u0026quot;n_accesses\u0026quot; check\r\n\r\nThis fixes a NULL pointer dereference bug due to a data race which\nlooks like this:\r\n\r\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP PTI\n  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43\n  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n  Workqueue: events_unbound netfs_rreq_write_to_cache_work\n  RIP: 0010:cachefiles_prepare_write+0x30/0xa0\n  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 \u0026lt;48\u0026gt; 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10\n  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286\n  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000\n  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438\n  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001\n  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68\n  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00\n  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __die+0x1f/0x70\n   ? page_fault_oops+0x15d/0x440\n   ? search_module_extables+0xe/0x40\n   ? fixup_exception+0x22/0x2f0\n   ? exc_page_fault+0x5f/0x100\n   ? asm_exc_page_fault+0x22/0x30\n   ? cachefiles_prepare_write+0x30/0xa0\n   netfs_rreq_write_to_cache_work+0x135/0x2e0\n   process_one_work+0x137/0x2c0\n   worker_thread+0x2e9/0x400\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0xcc/0x100\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1b/0x30\n   \u0026lt;/TASK\u0026gt;\n  Modules linked in:\n  CR2: 0000000000000008\n  ---[ end trace 0000000000000000 ]---\r\n\r\nThis happened because fscache_cookie_state_machine() was slow and was\nstill running while another process invoked fscache_unuse_cookie();\nthis led to a fscache_cookie_lru_do_one() call, setting the\nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by\nfscache_cookie_state_machine(), withdrawing the cookie via\ncachefiles_withdraw_cookie(), clearing cookie-\u0026gt;cache_priv.\r\n\r\nAt the same time, yet another process invoked\ncachefiles_prepare_write(), which found a NULL pointer in this code\nline:\r\n\r\n  struct cachefiles_object *object = cachefiles_cres_object(cres);\r\n\r\nThe next line crashes, obviously:\r\n\r\n  struct cachefiles_cache *cache = object-\u0026gt;volume-\u0026gt;cache;\r\n\r\nDuring cachefiles_prepare_write(), the \u0026quot;n_accesses\u0026quot; counter is\nnon-zero (via fscache_begin_operation()).  The cookie must not be\nwithdrawn until it drops to zero.\r\n\r\nThe counter is checked by fscache_cookie_state_machine() before\nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and\nFSCACHE_COOKIE_STATE_WITHDRAWING (in \u0026quot;case\nFSCACHE_COOKIE_STATE_FAILED\u0026quot;), but not for\nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\u0026quot;case\nFSCACHE_COOKIE_STATE_ACTIVE\u0026quot;).\r\n\r\nThis patch adds the missing check.  With a non-zero access counter,\nthe function returns and the next fscache_end_cookie_access() call\nwill queue another fscache_cookie_state_machine() call to handle the\nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD.(CVE-2024-45000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtla/osnoise: Prevent NULL dereference in error handling\r\n\r\nIf the \u0026quot;tool-\u0026gt;data\u0026quot; allocation fails then there is no need to call\nosnoise_free_top() and, in fact, doing so will lead to a NULL dereference.(CVE-2024-45002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n    PA                              PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg-\u0026gt;nlink = 0\n      iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea-\u0026gt;i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n        PA                PB                        PC\n                echo 2 \u0026gt; /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa-\u0026gt;i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib-\u0026gt;nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n      ubifs_iget(ixa-\u0026gt;i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib-\u0026gt;nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          \u2193             ubifs_jnl_write_inode\n     ABBA deadlock \u2190-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Take state lock during tx timeout reporter\r\n\r\nmlx5e_safe_reopen_channels() requires the state lock taken. The\nreferenced changed in the Fixes tag removed the lock to fix another\nissue. This patch adds it back but at a later point (when calling\nmlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the\nFixes tag.(CVE-2024-45019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()\r\n\r\n[BUG]\nThere is an internal report that KASAN is reporting use-after-free, with\nthe following backtrace:\r\n\r\n  BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n  Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45\n  CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n  Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]\n  Call Trace:\n   dump_stack_lvl+0x61/0x80\n   print_address_description.constprop.0+0x5e/0x2f0\n   print_report+0x118/0x216\n   kasan_report+0x11d/0x1f0\n   btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n   process_one_work+0xce0/0x12a0\n   worker_thread+0x717/0x1250\n   kthread+0x2e3/0x3c0\n   ret_from_fork+0x2d/0x70\n   ret_from_fork_asm+0x11/0x20\r\n\r\n  Allocated by task 20917:\n   kasan_save_stack+0x37/0x60\n   kasan_save_track+0x10/0x30\n   __kasan_slab_alloc+0x7d/0x80\n   kmem_cache_alloc_noprof+0x16e/0x3e0\n   mempool_alloc_noprof+0x12e/0x310\n   bio_alloc_bioset+0x3f0/0x7a0\n   btrfs_bio_alloc+0x2e/0x50 [btrfs]\n   submit_extent_page+0x4d1/0xdb0 [btrfs]\n   btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n   btrfs_readahead+0x29a/0x430 [btrfs]\n   read_pages+0x1a7/0xc60\n   page_cache_ra_unbounded+0x2ad/0x560\n   filemap_get_pages+0x629/0xa20\n   filemap_read+0x335/0xbf0\n   vfs_read+0x790/0xcb0\n   ksys_read+0xfd/0x1d0\n   do_syscall_64+0x6d/0x140\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\n  Freed by task 20917:\n   kasan_save_stack+0x37/0x60\n   kasan_save_track+0x10/0x30\n   kasan_save_free_info+0x37/0x50\n   __kasan_slab_free+0x4b/0x60\n   kmem_cache_free+0x214/0x5d0\n   bio_free+0xed/0x180\n   end_bbio_data_read+0x1cc/0x580 [btrfs]\n   btrfs_submit_chunk+0x98d/0x1880 [btrfs]\n   btrfs_submit_bio+0x33/0x70 [btrfs]\n   submit_one_bio+0xd4/0x130 [btrfs]\n   submit_extent_page+0x3ea/0xdb0 [btrfs]\n   btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n   btrfs_readahead+0x29a/0x430 [btrfs]\n   read_pages+0x1a7/0xc60\n   page_cache_ra_unbounded+0x2ad/0x560\n   filemap_get_pages+0x629/0xa20\n   filemap_read+0x335/0xbf0\n   vfs_read+0x790/0xcb0\n   ksys_read+0xfd/0x1d0\n   do_syscall_64+0x6d/0x140\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\n[CAUSE]\nAlthough I cannot reproduce the error, the report itself is good enough\nto pin down the cause.\r\n\r\nThe call trace is the regular endio workqueue context, but the\nfree-by-task trace is showing that during btrfs_submit_chunk() we\nalready hit a critical error, and is calling btrfs_bio_end_io() to error\nout.  And the original endio function called bio_put() to free the whole\nbio.\r\n\r\nThis means a double freeing thus causing use-after-free, e.g.:\r\n\r\n1. Enter btrfs_submit_bio() with a read bio\n   The read bio length is 128K, crossing two 64K stripes.\r\n\r\n2. The first run of btrfs_submit_chunk()\r\n\r\n2.1 Call btrfs_map_block(), which returns 64K\n2.2 Call btrfs_split_bio()\n    Now there are two bios, one referring to the first 64K, the other\n    referring to the second 64K.\n2.3 The first half is submitted.\r\n\r\n3. The second run of btrfs_submit_chunk()\r\n\r\n3.1 Call btrfs_map_block(), which by somehow failed\n    Now we call btrfs_bio_end_io() to handle the error\r\n\r\n3.2 btrfs_bio_end_io() calls the original endio function\n    Which is end_bbio_data_read(), and it calls bio_put() for the\n    original bio.\r\n\r\n    Now the original bio is freed.\r\n\r\n4. The submitted first 64K bio finished\n   Now we call into btrfs_check_read_bio() and tries to advance the bio\n   iter.\n   But since the original bio (thus its iter) is already freed, we\n   trigger the above use-after free.\r\n\r\n   And even if the memory is not poisoned/corrupted, we will later call\n   the original endio function, causing a double freeing.\r\n\r\n[FIX]\nInstead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),\nwhich has the extra check on split bios and do the pr\n---truncated---(CVE-2024-46687)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: fsl_lpuart: mark last busy before uart_add_one_port\r\n\r\nWith \u0026quot;earlycon initcall_debug=1 loglevel=8\u0026quot; in bootargs, kernel\nsometimes boot hang. It is because normal console still is not ready,\nbut runtime suspend is called, so early console putchar will hang\nin waiting TRDE set in UARTSTAT.\r\n\r\nThe lpuart driver has auto suspend delay set to 3000ms, but during\nuart_add_one_port, a child device serial ctrl will added and probed with\nits pm runtime enabled(see serial_ctrl.c).\nThe runtime suspend call path is:\ndevice_add\n     |-\u0026gt; bus_probe_device\n           |-\u0026gt;device_initial_probe\n\t           |-\u0026gt;__device_attach\n                         |-\u0026gt; pm_runtime_get_sync(dev-\u0026gt;parent);\n\t\t\t |-\u0026gt; pm_request_idle(dev);\n\t\t\t |-\u0026gt; pm_runtime_put(dev-\u0026gt;parent);\r\n\r\nSo in the end, before normal console ready, the lpuart get runtime\nsuspended. And earlycon putchar will hang.\r\n\r\nTo address the issue, mark last busy just after pm_runtime_enable,\nthree seconds is long enough to switch from bootconsole to normal\nconsole.(CVE-2024-46706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix dereference after null check\r\n\r\ncheck the pointer hive before use.(CVE-2024-46720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? __warn.cold+0x8e/0xea\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? report_bug+0xff/0x140\n   ? handle_bug+0x3b/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   generic_shutdown_super+0x70/0x160\n   kill_anon_super+0x11/0x40\n   btrfs_kill_super+0x11/0x20 [btrfs]\n   deactivate_locked_super+0x2e/0xa0\n   cleanup_mnt+0xb5/0x150\n   task_work_run+0x57/0x80\n   syscall_exit_to_user_mode+0x121/0x130\n   do_syscall_64+0xab/0x1a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f916847a887\n  ---[ end trace 0000000000000000 ]---\n  BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n   link from disk.  This assigns the corrupted value\n   3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n   this corrupted value to the length variable, which being a\n   signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n   the copied bytes is less than length, which being negative means\n   the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neventfs: Use list_del_rcu() for SRCU protected list variable\r\n\r\nChi Zhiling reported:\r\n\r\n  We found a null pointer accessing in tracefs[1], the reason is that the\n  variable \u0026apos;ei_child\u0026apos; is set to LIST_POISON1, that means the list was\n  removed in eventfs_remove_rec. so when access the ei_child-\u0026gt;is_freed, the\n  panic triggered.\r\n\r\n  by the way, the following script can reproduce this panic\r\n\r\n  loop1 (){\n      while true\n      do\n          echo \u0026quot;p:kp submit_bio\u0026quot; \u0026gt; /sys/kernel/debug/tracing/kprobe_events\n          echo \u0026quot;\u0026quot; \u0026gt; /sys/kernel/debug/tracing/kprobe_events\n      done\n  }\n  loop2 (){\n      while true\n      do\n          tree /sys/kernel/debug/tracing/events/kprobes/\n      done\n  }\n  loop1 \u0026amp;\n  loop2\r\n\r\n  [1]:\n  [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150\n  [ 1147.968239][T17331] Mem abort info:\n  [ 1147.971739][T17331]   ESR = 0x0000000096000004\n  [ 1147.976172][T17331]   EC = 0x25: DABT (current EL), IL = 32 bits\n  [ 1147.982171][T17331]   SET = 0, FnV = 0\n  [ 1147.985906][T17331]   EA = 0, S1PTW = 0\n  [ 1147.989734][T17331]   FSC = 0x04: level 0 translation fault\n  [ 1147.995292][T17331] Data abort info:\n  [ 1147.998858][T17331]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n  [ 1148.005023][T17331]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  [ 1148.010759][T17331]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n  [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges\n  [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP\n  [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls]\n  [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G        W         ------- ----  6.6.43 #2\n  [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650\n  [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020\n  [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398\n  [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398\n  [ 1148.115969][T17331] sp : ffff80008d56bbd0\n  [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000\n  [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100\n  [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10\n  [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000\n  [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0\n  [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0\n  [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862\n  [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068\n  [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001\n  [ 1148.198131][T17331] Call trace:\n  [ 1148.201259][T17331]  eventfs_iterate+0x2c0/0x398\n  [ 1148.205864][T17331]  iterate_dir+0x98/0x188\n  [ 1148.210036][T17331]  __arm64_sys_getdents64+0x78/0x160\n  [ 1148.215161][T17331]  invoke_syscall+0x78/0x108\n  [ 1148.219593][T17331]  el0_svc_common.constprop.0+0x48/0xf0\n  [ 1148.224977][T17331]  do_el0_svc+0x24/0x38\n  [ 1148.228974][T17331]  el0_svc+0x40/0x168\n  [ 1148.232798][T17\n---truncated---(CVE-2024-46785)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF\r\n\r\nThe fscache_cookie_lru_timer is initialized when the fscache module\nis inserted, but is not deleted when the fscache module is removed.\nIf timer_reduce() is called before removing the fscache module,\nthe fscache_cookie_lru_timer will be added to the timer list of\nthe current cpu. Afterwards, a use-after-free will be triggered\nin the softIRQ after removing the fscache module, as follows:\r\n\r\n==================================================================\nBUG: unable to handle page fault for address: fffffbfff803c9e9\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855\nTainted: [W]=WARN\nRIP: 0010:__run_timer_base.part.0+0x254/0x8a0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n tmigr_handle_remote_up+0x627/0x810\n __walk_groups.isra.0+0x47/0x140\n tmigr_handle_remote+0x1fa/0x2f0\n handle_softirqs+0x180/0x590\n irq_exit_rcu+0x84/0xb0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:default_idle+0xf/0x20\n default_idle_call+0x38/0x60\n do_idle+0x2b5/0x300\n cpu_startup_entry+0x54/0x60\n start_secondary+0x20d/0x280\n common_startup_64+0x13e/0x148\n \u0026lt;/TASK\u0026gt;\nModules linked in: [last unloaded: netfs]\n==================================================================\r\n\r\nTherefore delete fscache_cookie_lru_timer when removing the fscahe module.(CVE-2024-46786)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)",
  "id": "OESA-2024-2181",
  "modified": "2026-08-06T11:07:39Z",
  "published": "2024-09-27T11:07:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2181"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43904"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44959"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44962"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44967"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44984"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44991"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44994"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44996"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45000"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46687"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46706"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46714"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46720"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46751"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46752"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46785"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46786"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    }
  ],
  "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-36904",
    "CVE-2024-41008",
    "CVE-2024-43904",
    "CVE-2024-44954",
    "CVE-2024-44959",
    "CVE-2024-44962",
    "CVE-2024-44965",
    "CVE-2024-44967",
    "CVE-2024-44969",
    "CVE-2024-44974",
    "CVE-2024-44984",
    "CVE-2024-44991",
    "CVE-2024-44994",
    "CVE-2024-44995",
    "CVE-2024-44996",
    "CVE-2024-44999",
    "CVE-2024-45000",
    "CVE-2024-45002",
    "CVE-2024-45003",
    "CVE-2024-45008",
    "CVE-2024-45019",
    "CVE-2024-45025",
    "CVE-2024-46687",
    "CVE-2024-46706",
    "CVE-2024-46714",
    "CVE-2024-46720",
    "CVE-2024-46723",
    "CVE-2024-46731",
    "CVE-2024-46733",
    "CVE-2024-46742",
    "CVE-2024-46744",
    "CVE-2024-46745",
    "CVE-2024-46747",
    "CVE-2024-46751",
    "CVE-2024-46752",
    "CVE-2024-46759",
    "CVE-2024-46785",
    "CVE-2024-46786",
    "CVE-2024-46800"
  ]
}

OESA-2024-2217 (CVE-2024-44954)

Vulnerability from osv_openeuler – Published: 2024-10-12 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:

ALSA: line6: Fix racy access to midibuf

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

sched/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 </TASK>

Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)

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

memcg_write_event_control(): fix a user-triggerable oops

we are not guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).(CVE-2024-45021)

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

scsi: aacraid: Fix double-free on probe failure

aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter().

If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member.

After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)

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

usb: dwc3: st: fix probed platform device ref count on probe error path

The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.(CVE-2024-46674)

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

apparmor: fix possible NULL pointer dereference

profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made from __create_missing_ancestors(..) and 'ent->old' is NULL in aa_replace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 </TASK> Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated---(CVE-2024-46721)

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

drm/amdgpu: fix mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)

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

VMCI: Fix use-after-free when removing resource in vmci_resource_remove()

When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields.

It is possible though to create two resources with different types but same handle (same context and resource fields).

When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)

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

uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind

For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only.

Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel.(CVE-2024-46739)

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

binder: fix UAF caused by offsets overwrite

Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted.

Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed):

================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743

CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x19c binder_free_buf+0x128/0x434 binder_thread_write+0x8a4/0x3260 binder_ioctl+0x18f0/0x258c [...]

Allocated by task 743: __kmalloc_cache_noprof+0x110/0x270 binder_new_node+0x50/0x700 binder_transaction+0x413c/0x6da8 binder_thread_write+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...]

Freed by task 745: kfree+0xbc/0x208 binder_thread_read+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ==================================================================

To avoid this issue, let's check that the raw data copy is within the boundaries of the data section.(CVE-2024-46740)

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

PCI: Add missing bridge lock to pci_bus_lock()

One of the true positives that the cfg_access_lock lockdep effort identified is this sequence:

WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: <TASK> ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120

Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything but the bridge itself.

For the same motivation as adding:

bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);

to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock().

bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com

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

hwmon: (w83627ehf) Fix underflows seen when writing limit attributes

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

hwmon: (lm95234) Fix underflows seen when writing limit attributes

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

pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv

The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB.

The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash.

The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)

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

can: bcm: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry. Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().

However, removing the bound device resets bcm_sk(sk)->bound to 0 in bcm_notify().

The 2nd connect() tries to allocate a proc entry with the same name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the original proc entry.

Since the proc entry is available only for connect()ed sockets, let's clean up the entry when the bound netdev is unregistered.

[0]: proc_dir_entry 'can-bcm/2456' already registered WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375 Modules linked in: CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375 Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 </TASK> remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'(CVE-2024-46771)

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

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.(CVE-2024-46777)

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

nilfs2: protect references to superblock parameters exposed in sysfs

The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem".

Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it.(CVE-2024-46780)

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

nilfs2: fix missing cleanup on rollforward recovery error

In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug.

It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed.

Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts.(CVE-2024-46781)

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-44954	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44958	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45021	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46673	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46674	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46721	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46722	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46738	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46739	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46740	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46750	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46756	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46758	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46761	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46771	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46777	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46780	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46781	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2410.1.0.0298.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2410.1.0.0298.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2410.1.0.0298.oe2003sp4"
            }
          ],
          "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\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg_write_event_control(): fix a user-triggerable oops\r\n\r\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).(CVE-2024-45021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)",
  "id": "OESA-2024-2217",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2217"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    }
  ],
  "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-44954",
    "CVE-2024-44958",
    "CVE-2024-45021",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46721",
    "CVE-2024-46722",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46750",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46761",
    "CVE-2024-46771",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781"
  ]
}

OESA-2024-2218 (CVE-2024-27436)

Vulnerability from osv_openeuler – Published: 2024-10-12 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:

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels it could write outside of the map array.(CVE-2024-27436)

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

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:

DWC3 Gadget                               FFS Application

dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue()

There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.

Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it.

This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")(CVE-2024-36894)

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

scsi: bfa: Ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.(CVE-2024-38560)

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

enic: Validate length of nl attributes in enic_set_vf_port

enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.(CVE-2024-38659)

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

bcache: fix variable length array abuse in btree_iter

btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain.

This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array.(CVE-2024-39482)

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

drivers: core: synchronize really_probe() and dev_uevent()

Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:

Thread #1:

really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }

Thread #2:

dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }

really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:

dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Similar cases are reported by syzkaller in

https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a

But these are regarding the initialization of dev->driver

dev->driver = drv;

As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).

The same issue was reported and tried to be fixed back in 2015 in

https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/

already.(CVE-2024-39501)

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

scsi: qedi: Fix crash while reading debugfs attribute

The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call.

BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d(CVE-2024-40978)

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

ksmbd: discard write access to the directory open

may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory.

list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20(CVE-2024-41030)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)

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

lib: objagg: Fix general protection fault

The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported.

Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects.

Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault 1.

Before fixing the root cause, error out when nesting happens and warn.

1 general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-43846)

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

drm/vmwgfx: Fix a deadlock in dma buf fence polling

Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called.

Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)

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

media: xc2028: avoid use-after-free in load_firmware_cb()

syzkaller reported use-after-free in load_firmware_cb() 1. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free.

The process is as follows:

task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2] ... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed

To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return.

 BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

 Call trace:
  load_firmware_cb+0x1310/0x17a0
  request_firmware_work_func+0x128/0x220
  process_one_work+0x770/0x1824
  worker_thread+0x488/0xea0
  kthread+0x300/0x430
  ret_from_fork+0x10/0x20

 Allocated by task 6504:
  kzalloc
  tuner_probe+0xb0/0x1430
  i2c_device_probe+0x92c/0xaf0
  really_probe+0x678/0xcd0
  driver_probe_device+0x280/0x370
  __device_attach_driver+0x220/0x330
  bus_for_each_drv+0x134/0x1c0
  __device_attach+0x1f4/0x410
  device_initial_probe+0x20/0x30
  bus_probe_device+0x184/0x200
  device_add+0x924/0x12c0
  device_register+0x24/0x30
  i2c_new_device+0x4e0/0xc44
  v4l2_i2c_new_subdev_board+0xbc/0x290
  v4l2_i2c_new_subdev+0xc8/0x104
  em28xx_v4l2_init+0x1dd0/0x3770

 Freed by task 6504:
  kfree+0x238/0x4e4
  tuner_remove+0x144/0x1c0
  i2c_device_remove+0xc8/0x290
  __device_release_driver+0x314/0x5fc
  device_release_driver+0x30/0x44
  bus_remove_device+0x244/0x490
  device_del+0x350/0x900
  device_unregister+0x28/0xd0
  i2c_unregister_device+0x174/0x1d0
  v4l2_device_unregister+0x224/0x380
  em28xx_v4l2_init+0x1d90/0x3770

 The buggy address belongs to the object at ffff8000d7ca2000
  which belongs to the cache kmalloc-2k of size 2048
 The buggy address is located 776 bytes inside of
  2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
 The buggy address belongs to the page:
 page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
 flags: 0x7ff800000000100(slab)
 raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
  ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)

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

jfs: fix null ptr deref in dtInsertEntry

[syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time.

[Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL.(CVE-2024-44939)

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

ALSA: line6: Fix racy access to midibuf

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

sched/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

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

drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails

If the dpu_format_populate_layout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pin_count on the GEM object and causes a splat during DRM file closure:

msm_obj->pin_count WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124 hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20

Patchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)

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

Input: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

netem: fix return value if duplicate enqueue fails

There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free.

This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR.

There are two ways for the bug happen:

If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped.
If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped.

In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)

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

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first.

new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)

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

scsi: aacraid: Fix double-free on probe failure

aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter().

If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member.

After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)

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

usb: dwc3: st: fix probed platform device ref count on probe error path

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

ethtool: check device is present when getting link settings

A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg:

 [exception RIP: qed_get_current_link+17]

#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

crash> struct net_device.state ffff9a9d21336000 state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check.

Move this check into ethtool to protect all callers.(CVE-2024-46679)

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

pktgen: use cpus_read_lock() in pg_net_init()

I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests.

We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop.

While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)

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

selinux,smack: don't bypass permissions check in inode_setsecctx hook

Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled.

The end of the kerneldoc comment for __vfs_setxattr_noperm() states:

This function requires the caller to lock the inode's i_mutex before it
is executed. It also assumes that the caller will make the appropriate
permission checks.

nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do.

Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.(CVE-2024-46695)

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

KVM: arm64: Make ICC_SGI_EL1 undef in the absence of a vGICv3

On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_SGI_EL1 registers is trapped to EL2.

We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?).

The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.(CVE-2024-46707)

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

apparmor: fix possible NULL pointer dereference

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

drm/amdgpu: Fix out-of-bounds write warning

Check the ring type value to fix the out-of-bounds write warning(CVE-2024-46725)

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

drm/amd/display: Ensure index calculation will not overflow

[WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size.

This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)

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

drm/amd/display: Assign linear_pitch_alignment even for VM

[Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments(CVE-2024-46732)

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

nvmet-tcp: fix kernel crash if commands allocation fails

If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference.

nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008

Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)