Vulnerability-Lookup

CVE-2024-50014 (GCVE-0-2024-50014)

Vulnerability from cvelistv5 – Published: 2024-10-21 18:54 – Updated: 2026-09-08 08:39

Title

ext4: fix access to uninitialised lock in fc replay path

Summary

In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.

Severity

No CVSS data available.

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-10-22 13:28 UTC

Assigner

Linux mitre root Scorecard

References

6 references

URL	Tags
https://git.kernel.org/stable/c/6e35f560daebe4026…
https://git.kernel.org/stable/c/d157fc20ca5239fd5…
https://git.kernel.org/stable/c/b002031d585a14eed…
https://git.kernel.org/stable/c/23dfdb56581ad92a9…
https://lists.debian.org/debian-lts-announce/2025…
https://cert-portal.siemens.com/productcert/html/…

Impacted products

5 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 01efe93a5aa20a19b390426718dc214898a7c2ec , < 6e35f560daebe40264c95e9a1ab03110d4997df6 (git) Affected: 01efe93a5aa20a19b390426718dc214898a7c2ec , < d157fc20ca5239fd56965a5a8aa1a0e25919891a (git) Affected: 01efe93a5aa20a19b390426718dc214898a7c2ec , < b002031d585a14eed511117dda8c6452a804d508 (git) Affected: 01efe93a5aa20a19b390426718dc214898a7c2ec , < 23dfdb56581ad92a9967bcd720c8c23356af74c1 (git)	guessed
Linux	Linux	Affected: 6.6 Unaffected: 0 , < 6.6 (semver) Unaffected: 6.6.75 , ≤ 6.6.* (semver) Unaffected: 6.10.14 , ≤ 6.10.* (semver) Unaffected: 6.11.3 , ≤ 6.11.* (semver) Unaffected: 6.12 , ≤ * (original_commit_for_fix)	guessed
Siemens	SIMATIC S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIPLUS S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-50014",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-10-22T13:28:16.018937Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-10-22T13:28:48.311Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T20:43:00.666Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "affected": [
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-08T08:39:24.412Z",
          "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
          "shortName": "siemens-SADP"
        },
        "references": [
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
          }
        ],
        "x_adpType": "supplier"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/ext4/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6e35f560daebe40264c95e9a1ab03110d4997df6",
              "status": "affected",
              "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
              "versionType": "git"
            },
            {
              "lessThan": "d157fc20ca5239fd56965a5a8aa1a0e25919891a",
              "status": "affected",
              "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
              "versionType": "git"
            },
            {
              "lessThan": "b002031d585a14eed511117dda8c6452a804d508",
              "status": "affected",
              "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
              "versionType": "git"
            },
            {
              "lessThan": "23dfdb56581ad92a9967bcd720c8c23356af74c1",
              "status": "affected",
              "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/ext4/super.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.6"
            },
            {
              "lessThan": "6.6",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.75",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.14",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.75",
                  "versionStartIncluding": "6.6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.14",
                  "versionStartIncluding": "6.6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11.3",
                  "versionStartIncluding": "6.6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12",
                  "versionStartIncluding": "6.6",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix access to uninitialised lock in fc replay path\n\nThe following kernel trace can be triggered with fstest generic/629 when\nexecuted against a filesystem with fast-commit feature enabled:\n\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0027t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x66/0x90\n register_lock_class+0x759/0x7d0\n __lock_acquire+0x85/0x2630\n ? __find_get_block+0xb4/0x380\n lock_acquire+0xd1/0x2d0\n ? __ext4_journal_get_write_access+0xd5/0x160\n _raw_spin_lock+0x33/0x40\n ? __ext4_journal_get_write_access+0xd5/0x160\n __ext4_journal_get_write_access+0xd5/0x160\n ext4_reserve_inode_write+0x61/0xb0\n __ext4_mark_inode_dirty+0x79/0x270\n ? ext4_ext_replay_set_iblocks+0x2f8/0x450\n ext4_ext_replay_set_iblocks+0x330/0x450\n ext4_fc_replay+0x14c8/0x1540\n ? jread+0x88/0x2e0\n ? rcu_is_watching+0x11/0x40\n do_one_pass+0x447/0xd00\n jbd2_journal_recover+0x139/0x1b0\n jbd2_journal_load+0x96/0x390\n ext4_load_and_init_journal+0x253/0xd40\n ext4_fill_super+0x2cc6/0x3180\n...\n\nIn the replay path there\u0027s an attempt to lock sbi-\u003es_bdev_wb_lock in\nfunction ext4_check_bdev_write_error().  Unfortunately, at this point this\nspinlock has not been initialized yet.  Moving it\u0027s initialization to an\nearlier point in __ext4_fill_super() fixes this splat."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:43:52.724Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6"
        },
        {
          "url": "https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"
        },
        {
          "url": "https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508"
        },
        {
          "url": "https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1"
        }
      ],
      "title": "ext4: fix access to uninitialised lock in fc replay path",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50014",
    "datePublished": "2024-10-21T18:54:05.764Z",
    "dateReserved": "2024-10-21T12:17:06.062Z",
    "dateUpdated": "2026-09-08T08:39:24.412Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-50014",
      "date": "2026-10-08",
      "epss": "0.00224",
      "percentile": "0.1197"
    },
    "fkie_nvd": {
      "configurations": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "652638C5-5F25-4DF3-AD42-DD3252A97152",
                  "versionEndExcluding": "6.10.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
                  "versionEndExcluding": "6.11.3",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix access to uninitialised lock in fc replay path\n\nThe following kernel trace can be triggered with fstest generic/629 when\nexecuted against a filesystem with fast-commit feature enabled:\n\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0027t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x66/0x90\n register_lock_class+0x759/0x7d0\n __lock_acquire+0x85/0x2630\n ? __find_get_block+0xb4/0x380\n lock_acquire+0xd1/0x2d0\n ? __ext4_journal_get_write_access+0xd5/0x160\n _raw_spin_lock+0x33/0x40\n ? __ext4_journal_get_write_access+0xd5/0x160\n __ext4_journal_get_write_access+0xd5/0x160\n ext4_reserve_inode_write+0x61/0xb0\n __ext4_mark_inode_dirty+0x79/0x270\n ? ext4_ext_replay_set_iblocks+0x2f8/0x450\n ext4_ext_replay_set_iblocks+0x330/0x450\n ext4_fc_replay+0x14c8/0x1540\n ? jread+0x88/0x2e0\n ? rcu_is_watching+0x11/0x40\n do_one_pass+0x447/0xd00\n jbd2_journal_recover+0x139/0x1b0\n jbd2_journal_load+0x96/0x390\n ext4_load_and_init_journal+0x253/0xd40\n ext4_fill_super+0x2cc6/0x3180\n...\n\nIn the replay path there\u0027s an attempt to lock sbi-\u003es_bdev_wb_lock in\nfunction ext4_check_bdev_write_error().  Unfortunately, at this point this\nspinlock has not been initialized yet.  Moving it\u0027s initialization to an\nearlier point in __ext4_fill_super() fixes this splat."
        },
        {
          "lang": "es",
          "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el acceso a un bloqueo no inicializado en la ruta de reproducci\u00f3n de fc El siguiente seguimiento del kernel se puede activar con fstest generic/629 cuando se ejecuta contra un sistema de archivos con la funci\u00f3n de confirmaci\u00f3n r\u00e1pida habilitada: INFO: intentando registrar una clave no est\u00e1tica. El c\u00f3digo est\u00e1 bien, pero necesita la anotaci\u00f3n lockdep, o tal vez no inicializ\u00f3 este objeto antes de usarlo. Desactivando el validador de correcci\u00f3n de bloqueo. CPU: 0 PID: 866 Comm: montaje No contaminado 6.10.0+ #11 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas:  dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... En la ruta de reproducci\u00f3n hay un intento de bloquear sbi-\u0026gt;s_bdev_wb_lock en la funci\u00f3n ext4_check_bdev_write_error(). Desafortunadamente, en este punto este spinlock a\u00fan no se ha inicializado. Mover su inicializaci\u00f3n a un punto anterior en __ext4_fill_super() corrige este problema."
        }
      ],
      "id": "CVE-2024-50014",
      "lastModified": "2024-10-28T17:12:16.643",
      "metrics": {
        "cvssMetricV31": [
          {
            "cvssData": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            },
            "exploitabilityScore": 1.8,
            "impactScore": 3.6,
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      },
      "published": "2024-10-21T19:15:04.830",
      "references": [
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"
        }
      ],
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": [
        {
          "description": [
            {
              "lang": "en",
              "value": "CWE-908"
            }
          ],
          "source": "nvd@nist.gov",
          "type": "Primary"
        }
      ]
    },
    "microsoft_vex": {
      "current_release_date": "2026-03-31T15:05:04.000Z",
      "cve": "CVE-2024-50014",
      "id": "msrc_CVE-2024-50014",
      "initial_release_date": "2024-10-01T07:00:00.000Z",
      "product_status:fixed": "2",
      "product_status:known_affected": "2",
      "product_status:under_investigation": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "ext4: fix access to uninitialised lock in fc replay path",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-50014.json",
      "version": "3"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "fs/ext4/super.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "6e35f560daebe40264c95e9a1ab03110d4997df6",
                    "status": "affected",
                    "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "d157fc20ca5239fd56965a5a8aa1a0e25919891a",
                    "status": "affected",
                    "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b002031d585a14eed511117dda8c6452a804d508",
                    "status": "affected",
                    "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "23dfdb56581ad92a9967bcd720c8c23356af74c1",
                    "status": "affected",
                    "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "fs/ext4/super.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.6"
                  },
                  {
                    "lessThan": "6.6",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.75",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.10.*",
                    "status": "unaffected",
                    "version": "6.10.14",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.11.*",
                    "status": "unaffected",
                    "version": "6.11.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.12",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          },
          {
            "affectedData": [
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "652638C5-5F25-4DF3-AD42-DD3252A97152",
                    "versionEndExcluding": "6.10.14",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
                    "versionEndExcluding": "6.11.3",
                    "versionStartIncluding": "6.11",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix access to uninitialised lock in fc replay path\n\nThe following kernel trace can be triggered with fstest generic/629 when\nexecuted against a filesystem with fast-commit feature enabled:\n\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0027t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x66/0x90\n register_lock_class+0x759/0x7d0\n __lock_acquire+0x85/0x2630\n ? __find_get_block+0xb4/0x380\n lock_acquire+0xd1/0x2d0\n ? __ext4_journal_get_write_access+0xd5/0x160\n _raw_spin_lock+0x33/0x40\n ? __ext4_journal_get_write_access+0xd5/0x160\n __ext4_journal_get_write_access+0xd5/0x160\n ext4_reserve_inode_write+0x61/0xb0\n __ext4_mark_inode_dirty+0x79/0x270\n ? ext4_ext_replay_set_iblocks+0x2f8/0x450\n ext4_ext_replay_set_iblocks+0x330/0x450\n ext4_fc_replay+0x14c8/0x1540\n ? jread+0x88/0x2e0\n ? rcu_is_watching+0x11/0x40\n do_one_pass+0x447/0xd00\n jbd2_journal_recover+0x139/0x1b0\n jbd2_journal_load+0x96/0x390\n ext4_load_and_init_journal+0x253/0xd40\n ext4_fill_super+0x2cc6/0x3180\n...\n\nIn the replay path there\u0027s an attempt to lock sbi-\u003es_bdev_wb_lock in\nfunction ext4_check_bdev_write_error().  Unfortunately, at this point this\nspinlock has not been initialized yet.  Moving it\u0027s initialization to an\nearlier point in __ext4_fill_super() fixes this splat."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el acceso a un bloqueo no inicializado en la ruta de reproducci\u00f3n de fc El siguiente seguimiento del kernel se puede activar con fstest generic/629 cuando se ejecuta contra un sistema de archivos con la funci\u00f3n de confirmaci\u00f3n r\u00e1pida habilitada: INFO: intentando registrar una clave no est\u00e1tica. El c\u00f3digo est\u00e1 bien, pero necesita la anotaci\u00f3n lockdep, o tal vez no inicializ\u00f3 este objeto antes de usarlo. Desactivando el validador de correcci\u00f3n de bloqueo. CPU: 0 PID: 866 Comm: montaje No contaminado 6.10.0+ #11 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas:  dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... En la ruta de reproducci\u00f3n hay un intento de bloquear sbi-\u0026gt;s_bdev_wb_lock en la funci\u00f3n ext4_check_bdev_write_error(). Desafortunadamente, en este punto este spinlock a\u00fan no se ha inicializado. Mover su inicializaci\u00f3n a un punto anterior en __ext4_fill_super() corrige este problema."
          }
        ],
        "id": "CVE-2024-50014",
        "lastModified": "2026-07-14T13:17:11.017",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-50014",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-10-22T13:28:16.018937Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-10-21T19:15:04.830",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
          },
          {
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-908"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-13T15:08:27+00:00",
      "cve": "CVE-2024-50014",
      "id": "CVE-2024-50014",
      "initial_release_date": "2024-10-21T00:00:00+00:00",
      "product_status:fixed": "305",
      "product_status:known_affected": "64",
      "product_status:known_not_affected": "48",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: ext4: fix access to uninitialised lock in fc replay path",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-50014.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-09T00:32:31Z",
      "cve": "CVE-2024-50014",
      "id": "CVE-2024-50014",
      "initial_release_date": "2024-10-22T02:50:39Z",
      "product_status:known_affected": "432",
      "product_status:known_not_affected": "340",
      "product_status:recommended": "678",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-50014",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-50014.json",
      "version": "73"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2025-11-03T20:43:00.666Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "affected": [
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-09-08T08:39:24.412Z",
              "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
              "shortName": "siemens-SADP"
            },
            "references": [
              {
                "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
              }
            ],
            "x_adpType": "supplier"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-50014",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-10-22T13:28:16.018937Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-10-22T13:28:19.102Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "fs/ext4/super.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "6e35f560daebe40264c95e9a1ab03110d4997df6",
                  "status": "affected",
                  "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                  "versionType": "git"
                },
                {
                  "lessThan": "d157fc20ca5239fd56965a5a8aa1a0e25919891a",
                  "status": "affected",
                  "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                  "versionType": "git"
                },
                {
                  "lessThan": "b002031d585a14eed511117dda8c6452a804d508",
                  "status": "affected",
                  "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                  "versionType": "git"
                },
                {
                  "lessThan": "23dfdb56581ad92a9967bcd720c8c23356af74c1",
                  "status": "affected",
                  "version": "01efe93a5aa20a19b390426718dc214898a7c2ec",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "fs/ext4/super.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "6.6"
                },
                {
                  "lessThan": "6.6",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.75",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.10.*",
                  "status": "unaffected",
                  "version": "6.10.14",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.11.*",
                  "status": "unaffected",
                  "version": "6.11.3",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.12",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.75",
                      "versionStartIncluding": "6.6",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.10.14",
                      "versionStartIncluding": "6.6",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.11.3",
                      "versionStartIncluding": "6.6",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.12",
                      "versionStartIncluding": "6.6",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix access to uninitialised lock in fc replay path\n\nThe following kernel trace can be triggered with fstest generic/629 when\nexecuted against a filesystem with fast-commit feature enabled:\n\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0027t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x66/0x90\n register_lock_class+0x759/0x7d0\n __lock_acquire+0x85/0x2630\n ? __find_get_block+0xb4/0x380\n lock_acquire+0xd1/0x2d0\n ? __ext4_journal_get_write_access+0xd5/0x160\n _raw_spin_lock+0x33/0x40\n ? __ext4_journal_get_write_access+0xd5/0x160\n __ext4_journal_get_write_access+0xd5/0x160\n ext4_reserve_inode_write+0x61/0xb0\n __ext4_mark_inode_dirty+0x79/0x270\n ? ext4_ext_replay_set_iblocks+0x2f8/0x450\n ext4_ext_replay_set_iblocks+0x330/0x450\n ext4_fc_replay+0x14c8/0x1540\n ? jread+0x88/0x2e0\n ? rcu_is_watching+0x11/0x40\n do_one_pass+0x447/0xd00\n jbd2_journal_recover+0x139/0x1b0\n jbd2_journal_load+0x96/0x390\n ext4_load_and_init_journal+0x253/0xd40\n ext4_fill_super+0x2cc6/0x3180\n...\n\nIn the replay path there\u0027s an attempt to lock sbi-\u003es_bdev_wb_lock in\nfunction ext4_check_bdev_write_error().  Unfortunately, at this point this\nspinlock has not been initialized yet.  Moving it\u0027s initialization to an\nearlier point in __ext4_fill_super() fixes this splat."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-05-11T20:43:52.724Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6"
            },
            {
              "url": "https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"
            },
            {
              "url": "https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508"
            },
            {
              "url": "https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1"
            }
          ],
          "title": "ext4: fix access to uninitialised lock in fc replay path",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-50014",
        "datePublished": "2024-10-21T18:54:05.764Z",
        "dateReserved": "2024-10-21T12:17:06.062Z",
        "dateUpdated": "2026-09-08T08:39:24.412Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

OESA-2024-2426 (CVE-2024-46685)

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

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

pinctrl: single: fix potential NULL dereference in pcs_get_function()

pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function().

Found by code review.(CVE-2024-46685)

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

thunderbolt: Mark XDomain as unplugged when router is removed

I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.(CVE-2024-46702)

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

drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]

[WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1].

This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)

In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)

In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".(CVE-2024-49878)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)

In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.(CVE-2024-49948)

In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)

In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)

In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)

In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { / bit 0: 0 = mods, 1 = sites / unsigned long type; struct static_call_mod mods; struct static_call_site sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)

In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)

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

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

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

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)

In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)

In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)

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-46685	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46702	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46815	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47679	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47726	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49859	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49878	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49896	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49948	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49949	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49960	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49967	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49983	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50002	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50006	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50013	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50014	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50082	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50095	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50131	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50133	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50142	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50154	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.101.0.182.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.101.0.182.oe2203sp1"
            }
          ],
          "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\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer \u0026apos;function\u0026apos;\nwas dereferenced without checking against NULL. Add checking of pointer\n\u0026apos;function\u0026apos; in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthunderbolt: Mark XDomain as unplugged when router is removed\r\n\r\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\r\n\r\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.(CVE-2024-46702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]\r\n\r\n[WHY \u0026amp; HOW]\nnum_valid_sets needs to be checked to avoid a negative index when\naccessing reader_wm_sets[num_valid_sets - 1].\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vfs: fix race between evice_inodes() and find_inode()\u0026amp;iput()  Hi, all  Recently I noticed a bug[1] in btrfs, after digged it into and I believe it\u0026apos;a race in vfs.  Let\u0026apos;s assume there\u0026apos;s a inode (ie ino 261) with i_count 1 is called by iput(), and there\u0026apos;s a concurrent thread calling generic_shutdown_super().  cpu0:                              cpu1: iput() // i_count is 1   -\u0026gt;spin_lock(inode)   -\u0026gt;dec i_count to 0   -\u0026gt;iput_final()                    generic_shutdown_super()     -\u0026gt;__inode_add_lru()               -\u0026gt;evict_inodes()       // cause some reason[2]           -\u0026gt;if (atomic_read(inode-\u0026gt;i_count)) continue;       // return before                  // inode 261 passed the above check       // list_lru_add_obj()             // and then schedule out    -\u0026gt;spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set  btrfs_iget()   // after some function calls   -\u0026gt;find_inode()     // found the above inode 261     -\u0026gt;spin_lock(inode)    // check I_FREEING|I_WILL_FREE    // and passed       -\u0026gt;__iget()     -\u0026gt;spin_unlock(inode)                // schedule back                                         -\u0026gt;spin_lock(inode)                                         // check (I_NEW|I_FREEING|I_WILL_FREE) flags,                                         // passed and set I_FREEING iput()                                  -\u0026gt;spin_unlock(inode)   -\u0026gt;spin_lock(inode)     -\u0026gt;evict()   // dec i_count to 0   -\u0026gt;iput_final()     -\u0026gt;spin_unlock()     -\u0026gt;evict()  Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode-\u0026gt;i_state \u0026amp; I_CLEAR) statement both within clear_inode() and iput().  To fix the bug, recheck the inode-\u0026gt;i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.  If there is any misunderstanding, please let me know, thanks.  [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to check atomic_file in f2fs ioctl interfaces  Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  resource: fix region_intersects() vs add_memory_driver_managed()  On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.  490000000-50fffffff : CXL Window 0   490000000-50fffffff : region0     490000000-50fffffff : dax0.0       490000000-50fffffff : System RAM (kmem)  Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;.  This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource.  This can lead to bugs.  For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,   $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1  dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address  1+0 records in  0+0 records out  0 bytes copied, 0.0283507 s, 0.0 kB/s  the command fails as expected.  However, the error code is wrong.  It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;.  More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.  Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue.  During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.   ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff  WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d  Call Trace:   memremap+0xcb/0x184   xlate_dev_mem_ptr+0x25/0x2f   write_mem+0x94/0xfb   vfs_write+0x128/0x26d   ksys_write+0xac/0xfe   do_syscall_64+0x9a/0xfd   entry_SYSCALL_64_after_hwframe+0x4b/0x53  The details of command execution process are as follows.  In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource.  So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.  Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly.  Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access.  So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above.  To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.  So, we will not miss any matched resources in resource tree anymore.  In the new implementation, an example resource tree  |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --|  will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ),  |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --|  Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT \u0026amp; HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: add more sanity checks to qdisc_pkt_len_init()  One path takes care of SKB_GSO_DODGY, assuming skb-\u0026gt;len is bigger than hdr_len.  virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.  It is possible for an user to provide a malicious \u0026apos;GSO\u0026apos; packet, total length of 80 bytes.  - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8  virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size.  We need to make detect this case to not underflow qdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: avoid potential underflow in qdisc_pkt_len_init() with UFO  After commit 7c6d2ecbda83 (\u0026quot;net: be more gentle about silly gso requests coming from user\u0026quot;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet.  Then commit cf9acc90c80ec (\u0026quot;net: virtio_net_hdr_to_skb: count transport header in UFO\u0026quot;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic :  IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28.  When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;len  Then the following sets gso_segs to 0 :  gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len,                         shinfo-\u0026gt;gso_size);  Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/  qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len;  This leads to the following crash in fq_codel [1]  qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel.  This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug.  [1] [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   70.724561] #PF: supervisor read access in kernel mode [   70.724561] #PF: error_code(0x0000) - not-present page [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ========    0: 24 08                 and    $0x8,%al    2: 49 c1 e1 06           shl    $0x6,%r9    6: 44 89 7c 24 18        mov    %r15d,0x18(%rsp)    b: 45 31 ed              xor    %r13d,%r13d    e: 45 31 c0              xor    %r8d,%r8d   11: 31 ff                 xor    %edi,%edi   13: 89 44 24 14           mov    %eax,0x14(%rsp)   17: 4c 03 8b 90 01 00 00  add    0x190(%rbx),%r9   1e: eb 04                 jmp    0x24   20: 39 ca                 cmp    %ecx,%edx   22: 73 37                 jae    0x5b   24: 4d 8b 39              mov    (%r9),%r15   27: 83 c7 01              add    $0x1,%edi   2a:* 49 8b 17              mov    (%r15),%rdx  \u0026lt;-- trapping instruction   2d: 49 89 11              mov    %rdx,(%r9)   30: 41 8b 57 28           mov    0x28(%r15),%edx   34: 45 8b 5f 34           mov    0x34(%r15),%r11d   38: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   3f: 49                    rex.WB  Code starting with the faulting instruction ===========================================    0: 49 8b 17              mov    (%r15),%rdx    3: 49 89 11              mov    %rdx,(%r9)    6: 41 8b 57 28           mov    0x28(%r15),%edx    a: 45 8b 5f 34           mov    0x34(%r15),%r11d    e: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   15: 49                    rex.WB [   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [   70.724561] CS:  0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix timer use-after-free on failed mount  Syzbot has found an ODEBUG bug in ext4_fill_super  The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi).  When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called.  Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: no need to continue when the number of entries is 1(CVE-2024-49967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free  When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the \u0026apos;ppath\u0026apos; is updated but it is the \u0026apos;path\u0026apos; that is freed, thus potentially triggering a double-free in the following process:  ext4_ext_replay_update_ex   ppath = path   ext4_force_split_extent_at(\u0026amp;ppath)     ext4_split_extent_at       ext4_ext_insert_extent         ext4_ext_create_new_leaf           ext4_ext_grow_indepth             ext4_find_extent               if (depth \u0026gt; path[0].p_maxdepth)                 kfree(path)                 ---\u0026gt; path First freed                 *orig_path = path = NULL    ---\u0026gt; null ppath   kfree(path)                               ---\u0026gt; path double-free !!!  So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Handle module init failure correctly in static_call_del_module()  Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.  If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.  This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.  The problem is that key::mods is not a individual struct member of struct static_call_key, it\u0026apos;s part of a union to save space:          union {                 /* bit 0: 0 = mods, 1 = sites */                 unsigned long type;                 struct static_call_mod *mods;                 struct static_call_site *sites;  };  key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.  As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.  Cure it by checking whether the key has a sites or a mods pointer.  If it\u0026apos;s a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.  If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.  A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can\u0026apos;t match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix i_data_sem unlock order in ext4_ind_migrate()  Fuzzing reports a possible deadlock in jbd2_log_wait_commit.  This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.  This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.  Found by Linux Verification Center (linuxtesting.org) with syzkaller.  Rule: add(CVE-2024-50006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  exfat: fix memory leak in exfat_load_bitmap()  If the first directory entry in the root directory is not a bitmap directory entry, \u0026apos;bh\u0026apos; will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix access to uninitialised lock in fc replay path  The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled:  INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn\u0026apos;t initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x66/0x90  register_lock_class+0x759/0x7d0  __lock_acquire+0x85/0x2630  ? __find_get_block+0xb4/0x380  lock_acquire+0xd1/0x2d0  ? __ext4_journal_get_write_access+0xd5/0x160  _raw_spin_lock+0x33/0x40  ? __ext4_journal_get_write_access+0xd5/0x160  __ext4_journal_get_write_access+0xd5/0x160  ext4_reserve_inode_write+0x61/0xb0  __ext4_mark_inode_dirty+0x79/0x270  ? ext4_ext_replay_set_iblocks+0x2f8/0x450  ext4_ext_replay_set_iblocks+0x330/0x450  ext4_fc_replay+0x14c8/0x1540  ? jread+0x88/0x2e0  ? rcu_is_watching+0x11/0x40  do_one_pass+0x447/0xd00  jbd2_journal_recover+0x139/0x1b0  jbd2_journal_load+0x96/0x390  ext4_load_and_init_journal+0x253/0xd40  ext4_fill_super+0x2cc6/0x3180 ...  In the replay path there\u0026apos;s an attempt to lock sbi-\u0026gt;s_bdev_wb_lock in function ext4_check_bdev_write_error().  Unfortunately, at this point this spinlock has not been initialized yet.  Moving it\u0026apos;s initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race  We\u0026apos;re seeing crashes from rq_qos_wake_function that look like this:    BUG: unable to handle page fault for address: ffffafe180a40084   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0   Oops: Oops: 0002 [#1] PREEMPT SMP PTI   CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40   Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u0026lt;f0\u0026gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00   RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046   RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011   RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084   RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011   R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002   R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003   FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   PKRU: 55555554   Call Trace:    \u0026lt;IRQ\u0026gt;    try_to_wake_up+0x5a/0x6a0    rq_qos_wake_function+0x71/0x80    __wake_up_common+0x75/0xa0    __wake_up+0x36/0x60    scale_up.part.0+0x50/0x110    wb_timer_fn+0x227/0x450    ...  So rq_qos_wake_function() calls wake_up_process(data-\u0026gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock).  p comes from data-\u0026gt;task, and data comes from the waitqueue entry, which is stored on the waiter\u0026apos;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-\u0026gt;task. Meanwhile, the waker was passing the clobbered garbage in data-\u0026gt;task to wake_up_process(), leading to the crash.  What\u0026apos;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this:  rq_qos_wait()                           rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive()                                         data-\u0026gt;got_token = true;                                         list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token)         break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq);   ^- returns immediately because      list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry)      is true ... return, go do something else ...                                         wake_up_process(data-\u0026gt;task)                                           (NO LONGER VALID!)-^  Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue.  The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order.  Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/mad: Improve handling of timed out WRs of mad agent  Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler.  This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes  Trace: -----  BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]  CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE      -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1  Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019  Workqueue: ib_mad1 timeout_sends [ib_core]  RIP: 0010:__do_softirq+0x78/0x2ac  RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246  RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f  RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b  RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000  R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040  FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   \u0026lt;IRQ\u0026gt;   ? show_trace_log_lvl+0x1c4/0x2df   ? show_trace_log_lvl+0x1c4/0x2df   ? __irq_exit_rcu+0xa1/0xc0   ? watchdog_timer_fn+0x1b2/0x210   ? __pfx_watchdog_timer_fn+0x10/0x10   ? __hrtimer_run_queues+0x127/0x2c0   ? hrtimer_interrupt+0xfc/0x210   ? __sysvec_apic_timer_interrupt+0x5c/0x110   ? sysvec_apic_timer_interrupt+0x37/0x90   ? asm_sysvec_apic_timer_interrupt+0x16/0x20   ? __do_softirq+0x78/0x2ac   ? __do_softirq+0x60/0x2ac   __irq_exit_rcu+0xa1/0xc0   sysvec_call_function_single+0x72/0x90   \u0026lt;/IRQ\u0026gt;   \u0026lt;TASK\u0026gt;   asm_sysvec_call_function_single+0x16/0x20  RIP: 0010:_raw_spin_unlock_irq+0x14/0x30  RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247  RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800  RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c  RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000  R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538  R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c   cm_process_send_error+0x122/0x1d0 [ib_cm]   timeout_sends+0x1dd/0x270 [ib_core]   process_one_work+0x1e2/0x3b0   ? __pfx_worker_thread+0x10/0x10   worker_thread+0x50/0x3a0   ? __pfx_worker_thread+0x10/0x10   kthread+0xdd/0x100   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x29/0x50   \u0026lt;/TASK\u0026gt;  Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing: Consider the NULL character when validating the event length  strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.  This commit checks this condition and returns failure for it.(CVE-2024-50131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  LoongArch: Don\u0026apos;t crash in stack_top() for tasks without vDSO  Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash.  This can for example happen when using kunit:   [\u0026lt;9000000000203874\u0026gt;] stack_top+0x58/0xa8  [\u0026lt;90000000002956cc\u0026gt;] arch_pick_mmap_layout+0x164/0x220  [\u0026lt;90000000003c284c\u0026gt;] kunit_vm_mmap_init+0x108/0x12c  [\u0026lt;90000000003c1fbc\u0026gt;] __kunit_add_resource+0x38/0x8c  [\u0026lt;90000000003c2704\u0026gt;] kunit_vm_mmap+0x88/0xc8  [\u0026lt;9000000000410b14\u0026gt;] usercopy_test_init+0xbc/0x25c  [\u0026lt;90000000003c1db4\u0026gt;] kunit_try_run_case+0x5c/0x184  [\u0026lt;90000000003c3d54\u0026gt;] kunit_generic_run_threadfn_adapter+0x24/0x48  [\u0026lt;900000000022e4bc\u0026gt;] kthread+0xc8/0xd4  [\u0026lt;9000000000200ce8\u0026gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  xfrm: validate new SA\u0026apos;s prefixlen using SA family when sel.family is unset  This expands the validation introduced in commit 07bf7908950a (\u0026quot;xfrm: Validate address prefix lengths in the xfrm selector.\u0026quot;)  syzbot created an SA with     usersa.sel.family = AF_UNSPEC     usersa.sel.prefixlen_s = 128     usersa.family = AF_INET  Because of the AF_UNSPEC selector, verify_newsa_info doesn\u0026apos;t put limits on prefixlen_{s,d}. But then copy_from_user_state sets x-\u0026gt;sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that\u0026apos;s how prefixlen is going to be used later on.(CVE-2024-50142)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink().  Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().    \u0026quot;\u0026quot;\u0026quot;   We are seeing a use-after-free from a bpf prog attached to   trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the   bpf_sk_storage_get_tracing kernel helper which does check for null   before using it.   \u0026quot;\u0026quot;\u0026quot;  The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.  Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending.  If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.  The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default.  The scenario would be    1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),      but del_timer_sync() is missed    2. reqsk timer is executed and scheduled again    3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but      reqsk timer still has another one, and inet_csk_accept() does not      clear req-\u0026gt;sk for non-TFO sockets    4. sk is close()d    5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk  Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().  Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]  [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0  Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6  allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)",
  "id": "OESA-2024-2426",
  "modified": "2026-08-06T11:07:54Z",
  "published": "2024-11-15T11:07:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2426"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46702"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46815"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49948"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49967"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49983"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50013"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50133"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50142"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
    }
  ],
  "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-46685",
    "CVE-2024-46702",
    "CVE-2024-46815",
    "CVE-2024-47679",
    "CVE-2024-47726",
    "CVE-2024-49859",
    "CVE-2024-49878",
    "CVE-2024-49896",
    "CVE-2024-49948",
    "CVE-2024-49949",
    "CVE-2024-49960",
    "CVE-2024-49967",
    "CVE-2024-49983",
    "CVE-2024-50002",
    "CVE-2024-50006",
    "CVE-2024-50013",
    "CVE-2024-50014",
    "CVE-2024-50082",
    "CVE-2024-50095",
    "CVE-2024-50131",
    "CVE-2024-50133",
    "CVE-2024-50142",
    "CVE-2024-50154"
  ]
}

OPENSUSE-SU-2024:14500-1

Vulnerability from csaf_opensuse - Published: 2024-11-15 00:00 - Updated: 2026-09-20 21:21

Summary

kernel-devel-6.11.8-1.1 on GA media

Severity

Moderate

Scope

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

CVE-2024-50014

5.5 (Medium)


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

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2025:14705-1

Vulnerability from csaf_opensuse - Published: 2025-01-28 00:00 - Updated: 2026-09-20 21:25

Summary

kernel-devel-longterm-6.12.11-1.1 on GA media

Severity

Moderate

Scope

504 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Recommended: 8 products

Open the full advisory

RHSA-2025:6966

Vulnerability from csaf_opensuse - Published: 2025-05-13 08:28 - Updated: 2026-10-02 17:11

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

406 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

A flaw was found in the Linux kernel. When the ext4 filesystem's fast-commit feature is enabled, a local attacker could trigger a condition where an uninitialized lock is accessed during the filesystem's replay path. This can lead to a system crash, resulting in a denial of service.

5.5 (Medium)


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

Fixed: 305 products

https://access.redhat.com/errata/RHSA-2025:6966

Open the full advisory

SSA-019113

Vulnerability from csaf_siemens - Published: 2026-07-14 00:00 - Updated: 2026-09-08 00:00

Summary

SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6

Scope

431 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Known affected: 5 products

Open the full advisory

SUSE-SU-2024:3983-1

Vulnerability from csaf_suse - Published: 2024-11-13 10:12 - Updated: 2026-09-20 17:10

Summary

Security update for the Linux Kernel

Severity

Important

Scope

204 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Recommended: 59 products

Open the full advisory

SUSE-SU-2024:3985-1

Vulnerability from csaf_suse - Published: 2024-11-13 10:13 - Updated: 2026-09-20 17:10

Summary

Security update for the Linux Kernel

Severity

Important

Scope

211 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Recommended: 50 products

Open the full advisory

SUSE-SU-2024:4314-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:23 - Updated: 2026-09-20 17:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

241 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Recommended: 41 products

Open the full advisory

SUSE-SU-2024:4316-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:24 - Updated: 2026-09-20 17:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

228 vulnerabilities in this advisory, including CVE-2024-50014.

CVE-2024-50014

5.5 (Medium)


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

Recommended: 49 products

Open the full advisory

SUSE-SU-2024:4318-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:33 - Updated: 2026-09-20 17:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2024-50014

5.5 (Medium)


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

Recommended: 222 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

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

Related by attack behaviour

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

Action not permitted

CVE-2024-50014 (GCVE-0-2024-50014)

OESA-2024-2426 (CVE-2024-46685)

Tags

Sightings

Nomenclature

Related by attack behaviour