{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/qedi/qedi_debugfs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "56bec63a7fc87ad50b3373a87517dc9770eef9e0",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "21c963de2e86e88f6a8ca556bcebb8e62ab8e901",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "144d76a676b630e321556965011b00e2de0b40a7",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "397a8990c377ee4b61d6df768e61dff9e316d46b",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "eaddb86637669f6bad89245ee63f8fb2bfb50241",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "fa85b016a56b9775a3fe41e5d26e666945963b46",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "e2f433ea7d0ff77998766a088a287337fb43ad75",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            },
            {
              "lessThan": "28027ec8e32ecbadcd67623edb290dad61e735b5",
              "status": "affected",
              "version": "ace7f46ba5fde7273207c7122b0650ceb72510e0",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/qedi/qedi_debugfs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.10"
            },
            {
              "lessThan": "4.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.317",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.279",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.221",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.162",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.96",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.36",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "affectedData": [
        {
          "defaultStatus": "unknown",
          "product": "RUGGEDCOM RST2428P",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "AD25C2E5-C116-4160-BA6D-CE9B0D10AE3E",
              "versionEndExcluding": "4.19.317",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "F4E38E58-1B9F-4DF2-AD3D-A8BEAA2959D8",
              "versionEndExcluding": "5.4.279",
              "versionStartIncluding": "4.20",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "659E1520-6345-41AF-B893-A7C0647585A0",
              "versionEndExcluding": "5.10.221",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "10A39ACC-3005-40E8-875C-98A372D1FFD5",
              "versionEndExcluding": "5.15.162",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "61E887B4-732A-40D2-9983-CC6F281EBFB7",
              "versionEndExcluding": "6.1.96",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E1046C95-860A-45B0-B718-2B29F65BFF10",
              "versionEndExcluding": "6.6.36",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "0A047AF2-94AC-4A3A-B32D-6AB930D8EF1C",
              "versionEndExcluding": "6.9.7",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedi: Fix crash while reading debugfs attribute\n\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\n\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\n\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qedi: soluciona el fallo al leer el atributo debugfs La funci\u00f3n qedi_dbg_do_not_recover_cmd_read() invoca sprintf() directamente en un puntero __user, lo que provoca el fallo. Para solucionar este problema, use un peque\u00f1o b\u00fafer de pila local para sprintf() y luego llame a simple_read_from_buffer(), que a su vez realiza la llamada copy_to_user(). ERROR: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Ups: 0002 [#1] PREEMPT SMP PTI Nombre de hardware: HPE ProLi hormiga DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 15/06/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: 18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007ffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 000000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 PKRU: 5554 Seguimiento de llamadas:  ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x22/0x30? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] 0x80 vfs_read+0xa5/0x2e0? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90? count_memcg_event_mm+0x3d/0x60? handle_mm_fault+0x196/0x2f0? do_user_addr_fault+0x267/0x890? exc_page_fault+0x69/0x150 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d"
    }
  ],
  "id": "CVE-2024-40978",
  "lastModified": "2026-06-17T07:47:00.360",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.1,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.2,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-40978",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T17:02:30.760177Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-07-12T13:15:19.410",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-125"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-40978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:19Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedi: Fix crash while reading debugfs attribute\n\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\n\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\n\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d",
  "id": "GHSA-xvxh-jmmc-4vxm",
  "modified": "2026-05-12T12:32:02Z",
  "published": "2024-07-12T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "bpftool-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "bpftool-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2408.1.0.0288.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: musb: tusb6010: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47181)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix memory ordering between normal and ordered work functions\r\n\r\nOrdered work functions aren\u0026apos;t guaranteed to be handled by the same thread\nwhich executed the normal work functions. The only way execution between\nnormal/ordered functions is synchronized is via the WORK_DONE_BIT,\nunfortunately the used bitops don\u0026apos;t guarantee any ordering whatsoever.\r\n\r\nThis manifested as seemingly inexplicable crashes on ARM64, where\nasync_chunk::inode is seen as non-null in async_cow_submit which causes\nsubmit_compressed_extents to be called and crash occurs because\nasync_chunk::inode suddenly became NULL. The call trace was similar to:\r\n\r\n    pc : submit_compressed_extents+0x38/0x3d0\n    lr : async_cow_submit+0x50/0xd0\n    sp : ffff800015d4bc20\r\n\r\n    \u0026lt;registers omitted for brevity\u0026gt;\r\n\r\n    Call trace:\n     submit_compressed_extents+0x38/0x3d0\n     async_cow_submit+0x50/0xd0\n     run_ordered_work+0xc8/0x280\n     btrfs_work_helper+0x98/0x250\n     process_one_work+0x1f0/0x4ac\n     worker_thread+0x188/0x504\n     kthread+0x110/0x114\n     ret_from_fork+0x10/0x18\r\n\r\nFix this by adding respective barrier calls which ensure that all\naccesses preceding setting of WORK_DONE_BIT are strictly ordered before\nsetting the flag. At the same time add a read barrier after reading of\nWORK_DONE_BIT in run_ordered_work which ensures all subsequent loads\nwould be strictly ordered after reading the bit. This in turn ensures\nare all accesses before WORK_DONE_BIT are going to be strictly ordered\nbefore any access that can occur in ordered_func.(CVE-2021-47189)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa2-eth: fix use-after-free in dpaa2_eth_remove\r\n\r\nAccess to netdev after free_netdev() will cause use-after-free bug.\nMove debug log before free_netdev() call to avoid it.(CVE-2021-47204)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: host: ohci-tmio: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47206)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvsock: remove vsock from connected table when connect is interrupted by a signal\r\n\r\nvsock_connect() expects that the socket could already be in the\nTCP_ESTABLISHED state when the connecting task wakes up with a signal\npending. If this happens the socket will be in the connected table, and\nit is not removed when the socket state is reset. In this situation it\u0026apos;s\ncommon for the process to retry connect(), and if the connection is\nsuccessful the socket will be added to the connected table a second\ntime, corrupting the list.\r\n\r\nPrevent this by calling vsock_remove_connected() if a signal is received\nwhile waiting for a connection. This is harmless if the socket is not in\nthe connected table, and if it is in the table then removing it will\nprevent list corruption from a double add.\r\n\r\nNote for backporting: this patch requires d5afa82c977e (\u0026quot;vsock: correct\nremoval of socket from the list\u0026quot;), which is in all current stable trees\nexcept 4.9.y.(CVE-2022-48786)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: at86rf230: Stop leaking skb\u0026apos;s\r\n\r\nUpon error the ieee802154_xmit_complete() helper is not called. Only\nieee802154_wake_queue() is called manually. In the Tx case we then leak\nthe skb structure.\r\n\r\nFree the skb structure upon error before returning when appropriate.\r\n\r\nAs the \u0026apos;is_tx = 0\u0026apos; cannot be moved in the complete handler because of a\npossible race between the delay in switching to STATE_RX_AACK_ON and a\nnew interrupt, we introduce an intermediate \u0026apos;was_tx\u0026apos; boolean just for\nthis purpose.\r\n\r\nThere is no Fixes tag applying here, many changes have been made on this\narea and the issue kind of always existed.(CVE-2022-48794)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt_ioctl: fix array_index_nospec in vt_setactivate\r\n\r\narray_index_nospec ensures that an out-of-bounds value is set to zero\non the transient path. Decreasing the value by one afterwards causes\na transient integer underflow. vsa.console should be decreased first\nand then sanitized with array_index_nospec.\r\n\r\nKasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh\nRazavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU\nAmsterdam.(CVE-2022-48804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: f_fs: Fix use-after-free for epfile\r\n\r\nConsider a case where ffs_func_eps_disable is called from\nffs_func_disable as part of composition switch and at the\nsame time ffs_epfile_release get called from userspace.\nffs_epfile_release will free up the read buffer and call\nffs_data_closed which in turn destroys ffs-\u0026gt;epfiles and\nmark it as NULL. While this was happening the driver has\nalready initialized the local epfile in ffs_func_eps_disable\nwhich is now freed and waiting to acquire the spinlock. Once\nspinlock is acquired the driver proceeds with the stale value\nof epfile and tries to free the already freed read buffer\ncausing use-after-free.\r\n\r\nFollowing is the illustration of the race:\r\n\r\n      CPU1                                  CPU2\r\n\r\n   ffs_func_eps_disable\n   epfiles (local copy)\n\t\t\t\t\tffs_epfile_release\n\t\t\t\t\tffs_data_closed\n\t\t\t\t\tif (last file closed)\n\t\t\t\t\tffs_data_reset\n\t\t\t\t\tffs_data_clear\n\t\t\t\t\tffs_epfiles_destroy\nspin_lock\ndereference epfiles\r\n\r\nFix this races by taking epfiles local copy \u0026amp; assigning it under\nspinlock and if epfiles(local) is null then update it in ffs-\u0026gt;epfiles\nthen finally destroy it.\nExtending the scope further from the race, protecting the ep related\nstructures, and concurrent accesses.(CVE-2022-48822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: aiptek - properly check endpoint type\r\n\r\nSyzbot reported warning in usb_submit_urb() which is caused by wrong\nendpoint type. There was a check for the number of endpoints, but not\nfor the type of endpoint.\r\n\r\nFix it by replacing old desc.bNumEndpoints check with\nusb_find_common_endpoints() helper for finding endpoints\r\n\r\nFail log:\r\n\r\nusb 5-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nWorkqueue: usb_hub_wq hub_event\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830\n input_open_device+0x1bb/0x320 drivers/input/input.c:629\n kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593(CVE-2022-48836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nMIPS: smp: fill in sibling and core maps earlier\r\n\r\nAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),\n2-core 2-thread-per-core interAptiv (CPS-driven) started emitting\nthe following:\r\n\r\n[    0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))\n[    0.048183] ------------[ cut here ]------------\n[    0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240\n[    0.048220] Modules linked in:\n[    0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f\n[    0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1\n[    0.048278]         830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000\n[    0.048307]         00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000\n[    0.048334]         00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34\n[    0.048361]         817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933\n[    0.048389]         ...\n[    0.048396] Call Trace:\n[    0.048399] [\u0026lt;8105a7bc\u0026gt;] show_stack+0x3c/0x140\n[    0.048424] [\u0026lt;8131c2a0\u0026gt;] dump_stack_lvl+0x60/0x80\n[    0.048440] [\u0026lt;8108b5c0\u0026gt;] __warn+0xc0/0xf4\n[    0.048454] [\u0026lt;8108b658\u0026gt;] warn_slowpath_fmt+0x64/0x10c\n[    0.048467] [\u0026lt;810bd418\u0026gt;] sched_core_cpu_starting+0x198/0x240\n[    0.048483] [\u0026lt;810c6514\u0026gt;] sched_cpu_starting+0x14/0x80\n[    0.048497] [\u0026lt;8108c0f8\u0026gt;] cpuhp_invoke_callback_range+0x78/0x140\n[    0.048510] [\u0026lt;8108d914\u0026gt;] notify_cpu_starting+0x94/0x140\n[    0.048523] [\u0026lt;8106593c\u0026gt;] start_secondary+0xbc/0x280\n[    0.048539]\n[    0.048543] ---[ end trace 0000000000000000 ]---\n[    0.048636] Synchronize counters for CPU 1: done.\r\n\r\n...for each but CPU 0/boot.\nBasic debug printks right before the mentioned line say:\r\n\r\n[    0.048170] CPU: 1, smt_mask:\r\n\r\nSo smt_mask, which is sibling mask obviously, is empty when entering\nthe function.\nThis is critical, as sched_core_cpu_starting() calculates\ncore-scheduling parameters only once per CPU start, and it\u0026apos;s crucial\nto have all the parameters filled in at that moment (at least it\nuses cpu_smt_mask() which in fact is `\u0026amp;cpu_sibling_map[cpu]` on\nMIPS).\r\n\r\nA bit of debugging led me to that set_cpu_sibling_map() performing\nthe actual map calculation, was being invocated after\nnotify_cpu_start(), and exactly the latter function starts CPU HP\ncallback round (sched_core_cpu_starting() is basically a CPU HP\ncallback).\nWhile the flow is same on ARM64 (maps after the notifier, although\nbefore calling set_cpu_online()), x86 started calculating sibling\nmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see\n[0] for the reference). Neither me nor my brief tests couldn\u0026apos;t find\nany potential caveats in calculating the maps right after performing\ndelay calibration, but the WARN splat is now gone.\nThe very same debug prints now yield exactly what I expected from\nthem:\r\n\r\n[    0.048433] CPU: 1, smt_mask: 0-1\r\n\r\n[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef(CVE-2022-48845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: gdm724x: fix use after free in gdm_lte_rx()\r\n\r\nThe netif_rx_ni() function frees the skb so we can\u0026apos;t dereference it to\nsave the skb-\u0026gt;len.(CVE-2022-48851)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFC: port100: fix use-after-free in port100_send_complete\r\n\r\nSyzbot reported UAF in port100_send_complete(). The root case is in\nmissing usb_kill_urb() calls on error handling path of -\u0026gt;probe function.\r\n\r\nport100_send_complete() accesses devm allocated memory which will be\nfreed on probe failure. We should kill this urbs before returning an\nerror from probe function to prevent reported use-after-free\r\n\r\nFail log:\r\n\r\nBUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935\nRead of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold+0x83/0xdf mm/kasan/report.c:459\n port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935\n __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670\r\n\r\n...\r\n\r\nAllocated by task 1255:\n kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\n kasan_set_track mm/kasan/common.c:45 [inline]\n set_alloc_info mm/kasan/common.c:436 [inline]\n ____kasan_kmalloc mm/kasan/common.c:515 [inline]\n ____kasan_kmalloc mm/kasan/common.c:474 [inline]\n __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524\n alloc_dr drivers/base/devres.c:116 [inline]\n devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823\n devm_kzalloc include/linux/device.h:209 [inline]\n port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502\r\n\r\nFreed by task 1255:\n kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\n kasan_set_track+0x21/0x30 mm/kasan/common.c:45\n kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370\n ____kasan_slab_free mm/kasan/common.c:366 [inline]\n ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328\n kasan_slab_free include/linux/kasan.h:236 [inline]\n __cache_free mm/slab.c:3437 [inline]\n kfree+0xf8/0x2b0 mm/slab.c:3794\n release_nodes+0x112/0x1a0 drivers/base/devres.c:501\n devres_release_all+0x114/0x190 drivers/base/devres.c:530\n really_probe+0x626/0xcc0 drivers/base/dd.c:670(CVE-2022-48857)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: Fix double free in of_parse_phandle_with_args_map\r\n\r\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of \u0026quot;new\u0026quot; is\nNULL on the first iteration of the inner loop.\r\n\r\nMake sure that this is true in all iterations of the outer\nloop by setting \u0026quot;new\u0026quot; to NULL after its value is assigned to \u0026quot;cur\u0026quot;.\r\n\r\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.(CVE-2023-52679)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s drm/exynos device driver in\u00a0exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\n(CVE-2024-22386)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: add a proper sanity check for endpoints\r\n\r\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\r\n\r\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\r\n\r\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\r\n\r\n[2] Related syzkaller crashes:(CVE-2024-38567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstm class: Fix a double free in stm_register_device()\r\n\r\nThe put_device(\u0026amp;stm-\u0026gt;dev) call will trigger stm_device_release() which\nfrees \u0026quot;stm\u0026quot; so the vfree(stm) on the next line is a double free.(CVE-2024-38627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: davinci: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u0026gt;\ndavinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\r\n\r\nIn lio_vf_rep_copy_packet() pg_info-\u0026gt;page is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\r\n\r\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t  octeon_droq_dispatch_pkt\n\t   octeon_create_recv_info\n\t    ...search in the dispatch_list...\n\t     -\u0026gt;disp_fn(rdisp-\u0026gt;rinfo, ...)\n\t      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u0026gt;page to NULL.\nSo this check looks unneeded and doesn\u0026apos;t solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can\u0026apos;t do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\r\n\r\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\r\n\r\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\r\n\r\nThis should take care of KASAN reports like this:\r\n\r\nunreferenced object 0xffff00000668d800 (size 128):\n  comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419552 (age 1836.444s)\n  hex dump (first 32 bytes):\n    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....\n    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....\u0026gt;...........\n  backtrace:\n    [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n    [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n    [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n    [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n    [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n    [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n    [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n    [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n    [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n    [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n    [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n    [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n    [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n    [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n  comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419553 (age 1836.440s)\n  hex dump (first 32 bytes):\n    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....\n    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6\u0026apos;.......Xy.....\n  backtrace:\n    [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n    [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n    [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n    [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n    [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n    [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n    [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n    [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n    [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n    [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n    [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n    [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n    [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n    [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-40942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Avoid blocking in RCU read-side critical section\r\n\r\nA panic happens in ima_match_policy:\r\n\r\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\nPGD 42f873067 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 5 PID: 1286325 Comm: kubeletmonit.sh\nKdump: loaded Tainted: P\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n               BIOS 0.0.0 02/06/2015\nRIP: 0010:ima_match_policy+0x84/0x450\nCode: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39\n      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d\n      f2 b9 f4 00 0f 84 9c 01 00 00 \u0026lt;44\u0026gt; 85 73 10 74 ea\n      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f\nRSP: 0018:ff71570009e07a80 EFLAGS: 00010207\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200\nRDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000\nRBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739\nR10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970\nR13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001\nFS:  00007f5195b51740(0000)\nGS:ff3e278b12d40000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ima_get_action+0x22/0x30\n process_measurement+0xb0/0x830\n ? page_add_file_rmap+0x15/0x170\n ? alloc_set_pte+0x269/0x4c0\n ? prep_new_page+0x81/0x140\n ? simple_xattr_get+0x75/0xa0\n ? selinux_file_open+0x9d/0xf0\n ima_file_check+0x64/0x90\n path_openat+0x571/0x1720\n do_filp_open+0x9b/0x110\n ? page_counter_try_charge+0x57/0xc0\n ? files_cgroup_alloc_fd+0x38/0x60\n ? __alloc_fd+0xd4/0x250\n ? do_sys_open+0x1bd/0x250\n do_sys_open+0x1bd/0x250\n do_syscall_64+0x5d/0x1d0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nCommit c7423dbdbc9e (\u0026quot;ima: Handle -ESTALE returned by\nima_filter_rule_match()\u0026quot;) introduced call to ima_lsm_copy_rule within a\nRCU read-side critical section which contains kmalloc with GFP_KERNEL.\nThis implies a possible sleep and violates limitations of RCU read-side\ncritical sections on non-PREEMPT systems.\r\n\r\nSleeping within RCU read-side critical section might cause\nsynchronize_rcu() returning early and break RCU protection, allowing a\nUAF to happen.\r\n\r\nThe root cause of this issue could be described as follows:\n|\tThread A\t|\tThread B\t|\n|\t\t\t|ima_match_policy\t|\n|\t\t\t|  rcu_read_lock\t|\n|ima_lsm_update_rule\t|\t\t\t|\n|  synchronize_rcu\t|\t\t\t|\n|\t\t\t|    kmalloc(GFP_KERNEL)|\n|\t\t\t|      sleep\t\t|\n==\u0026gt; synchronize_rcu returns early\n|  kfree(entry)\t\t|\t\t\t|\n|\t\t\t|    entry = entry-\u0026gt;next|\n==\u0026gt; UAF happens and entry now becomes NULL (or could be anything).\n|\t\t\t|    entry-\u0026gt;action\t|\n==\u0026gt; Accessing entry might cause panic.\r\n\r\nTo fix this issue, we are converting all kmalloc that is called within\nRCU read-side critical section to use GFP_ATOMIC.\r\n\r\n[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL dereference in rt6_probe()\r\n\r\nsyzbot caught a NULL dereference in rt6_probe() [1]\r\n\r\nBail out if  __in6_dev_get() returns NULL.\r\n\r\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n  find_rr_leaf net/ipv6/route.c:853 [inline]\n  rt6_select net/ipv6/route.c:897 [inline]\n  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n  pol_lookup_func include/net/ip6_fib.h:616 [inline]\n  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x6b6/0x1140 fs/read_write.c:590\n  ksys_write+0x1f8/0x260 fs/read_write.c:643\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last  enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last  enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n  spin_unlock_bh include/linux/spinlock.h:396 [inline]\n  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n  process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n  process_scheduled_works kernel/workqueue.c:2706 [inline]\n  worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n  kthread+0x288/0x310 kernel/kthread.c:388\n  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\r\n\r\nsyzbot found hanging tasks waiting on rtnl_lock [1]\r\n\r\nA reproducer is available in the syzbot bug.\r\n\r\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\r\n\r\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\r\n\r\n[1]\r\n\r\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u0026lt;TASK\u0026gt;\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)",
  "id": "OESA-2024-1944",
  "modified": "2026-08-06T11:07:24Z",
  "published": "2024-08-02T11:07:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47181"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47204"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47206"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48786"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48822"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48836"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48845"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48851"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22386"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38627"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995"
    }
  ],
  "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-2021-47181",
    "CVE-2021-47189",
    "CVE-2021-47204",
    "CVE-2021-47206",
    "CVE-2022-48786",
    "CVE-2022-48794",
    "CVE-2022-48804",
    "CVE-2022-48822",
    "CVE-2022-48828",
    "CVE-2022-48836",
    "CVE-2022-48845",
    "CVE-2022-48851",
    "CVE-2022-48857",
    "CVE-2023-52679",
    "CVE-2024-22386",
    "CVE-2024-37078",
    "CVE-2024-38567",
    "CVE-2024-38611",
    "CVE-2024-38627",
    "CVE-2024-39475",
    "CVE-2024-39484",
    "CVE-2024-39506",
    "CVE-2024-40942",
    "CVE-2024-40947",
    "CVE-2024-40960",
    "CVE-2024-40978",
    "CVE-2024-40981",
    "CVE-2024-40988",
    "CVE-2024-40995"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "perf-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-41.0.0.48.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-41.0.0.48.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-41.0.0.48.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "perf-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-41.0.0.48.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-41.0.0.48.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-41.0.0.48.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.(CVE-2024-36934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\r\n\r\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\r\n\r\nsyzbot reported:\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: mask irqs in timeout path before hard reset\r\n\r\nThere is a race condition in which a rendering job might take just long\nenough to trigger the drm sched job timeout handler but also still\ncomplete before the hard reset is done by the timeout handler.\nThis runs into race conditions not expected by the timeout handler.\nIn some very specific cases it currently may result in a refcount\nimbalance on lima_pm_idle, with a stack dump such as:\r\n\r\n[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0\n...\n[10136.669628] Call trace:\n[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0\n[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0\n[10136.669656]  lima_gp_irq_handler+0xa8/0x120\n[10136.669666]  __handle_irq_event_percpu+0x48/0x160\n[10136.669679]  handle_irq_event+0x4c/0xc0\r\n\r\nWe can prevent that race condition entirely by masking the irqs at the\nbeginning of the timeout handler, at which point we give up on waiting\nfor that job entirely.\nThe irqs will be enabled again at the next hard reset which is already\ndone as a recovery by the timeout handler.(CVE-2024-40976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()\r\n\r\nxattr in ocfs2 maybe \u0026apos;non-indexed\u0026apos;, which saved with additional space\nrequested.  It\u0026apos;s better to check if the memory is out of bound before\nmemcmp, although this possibility mainly comes from crafted poisonous\nimages.(CVE-2024-41016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: SOF: Intel: hda: fix null deref on system suspend entry\r\n\r\nWhen system enters suspend with an active stream, SOF core\ncalls hw_params_upon_resume(). On Intel platforms with HDA DMA used\nto manage the link DMA, this leads to call chain of\r\n\r\n   hda_dsp_set_hw_params_upon_resume()\n -\u0026gt; hda_dsp_dais_suspend()\n -\u0026gt; hda_dai_suspend()\n -\u0026gt; hda_ipc4_post_trigger()\r\n\r\nA bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first,\nwhich clears hext_stream-\u0026gt;link_substream, and then hda_ipc4_post_trigger()\nis called with a NULL snd_pcm_substream pointer.(CVE-2024-41037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Init the count variable in collecting hot-reset devices\r\n\r\nThe count variable is used without initialization, it results in mistakes\nin the device counting and crashes the userspace if the get hot reset info\npath is triggered.(CVE-2024-41052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: Avoid address calculations via out of bounds array indexing\r\n\r\nreq-\u0026gt;n_channels must be set before req-\u0026gt;channels[] can be used.\r\n\r\nThis patch fixes one of the issues encountered in [1].\r\n\r\n[   83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4\n[   83.964258] index 0 is out of range for type \u0026apos;struct ieee80211_channel *[]\u0026apos;\n[...]\n[   83.964264] Call Trace:\n[   83.964267]  \u0026lt;TASK\u0026gt;\n[   83.964269]  dump_stack_lvl+0x3f/0xc0\n[   83.964274]  __ubsan_handle_out_of_bounds+0xec/0x110\n[   83.964278]  ieee80211_prep_hw_scan+0x2db/0x4b0\n[   83.964281]  __ieee80211_start_scan+0x601/0x990\n[   83.964291]  nl80211_trigger_scan+0x874/0x980\n[   83.964295]  genl_family_rcv_msg_doit+0xe8/0x160\n[   83.964298]  genl_rcv_msg+0x240/0x270\n[...]\r\n\r\n[1] https://bugzilla.kernel.org/show_bug.cgi?id=218810(CVE-2024-41071)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fabrics: use reserved tag for reg read/write command\r\n\r\nIn some scenarios, if too many commands are issued by nvme command in\nthe same time by user tasks, this may exhaust all tags of admin_q. If\na reset (nvme reset or IO timeout) occurs before these commands finish,\nreconnect routine may fail to update nvme regs due to insufficient tags,\nwhich will cause kernel hang forever. In order to workaround this issue,\nmaybe we can let reg_read32()/reg_read64()/reg_write32() use reserved\ntags. This maybe safe for nvmf:\r\n\r\n1. For the disable ctrl path,  we will not issue connect command\n2. For the enable ctrl / fw activate path, since connect and reg_xx()\n   are called serially.\r\n\r\nSo the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix null pointer dereference on error\r\n\r\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\r\n\r\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\r\n\r\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nDo not access ata_port struct members unconditionally.(CVE-2024-41098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Fix improper extts handling\r\n\r\nExtts events are disabled and enabled by the application ts2phc.\nHowever, in case where the driver is removed when the application is\nrunning, a specific extts event remains enabled and can cause a kernel\ncrash.\nAs a side effect, when the driver is reloaded and application is started\nagain, remaining extts event for the channel from a previous run will\nkeep firing and the message \u0026quot;extts on unexpected channel\u0026quot; might be\nprinted to the user.\r\n\r\nTo avoid that, extts events shall be disabled when PTP is released.(CVE-2024-42139)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: fix crashes from deferred split racing folio migration\r\n\r\nEven on 6.10-rc6, I\u0026apos;ve been seeing elusive \u0026quot;Bad page state\u0026quot;s (often on\nflags when freeing, yet the flags shown are not bad: PG_locked had been\nset and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from\ndeferred_split_scan()\u0026apos;s folio_put(), and a variety of other BUG and WARN\nsymptoms implying double free by deferred split and large folio migration.\r\n\r\n6.7 commit 9bcef5973e31 (\u0026quot;mm: memcg: fix split queue list crash when large\nfolio migration\u0026quot;) was right to fix the memcg-dependent locking broken in\n85ce2c517ade (\u0026quot;memcontrol: only transfer the memcg data for migration\u0026quot;),\nbut missed a subtlety of deferred_split_scan(): it moves folios to its own\nlocal list to work on them without split_queue_lock, during which time\nfolio-\u0026gt;_deferred_list is not empty, but even the \u0026quot;right\u0026quot; lock does nothing\nto secure the folio and the list it is on.\r\n\r\nFortunately, deferred_split_scan() is careful to use folio_try_get(): so\nfolio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()\nwhile the old folio\u0026apos;s reference count is temporarily frozen to 0 - adding\nsuch a freeze in the !mapping case too (originally, folio lock and\nunmapping and no swap cache left an anon folio unreachable, so no freezing\nwas needed there: but the deferred split queue offers a way to reach it).(CVE-2024-42234)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/mm: Add NULL pointer check to crst_table_free() base_crst_free()\r\n\r\ncrst_table_free() used to work with NULL pointers before the conversion\nto ptdescs.  Since crst_table_free() can be called with a NULL pointer\n(error handling in crst_table_upgrade() add an explicit check.\r\n\r\nAlso add the same check to base_crst_free() for consistency reasons.\r\n\r\nIn real life this should not happen, since order two GFP_KERNEL\nallocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used.(CVE-2024-42235)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: cs_dsp: Validate payload length before processing block\r\n\r\nMove the payload length check in cs_dsp_load() and cs_dsp_coeff_load()\nto be done before the block is processed.\r\n\r\nThe check that the length of a block payload does not exceed the number\nof remaining bytes in the firwmware file buffer was being done near the\nend of the loop iteration. However, some code before that check used the\nlength field without validating it.(CVE-2024-42237)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: cs_dsp: Return error if block header overflows file\r\n\r\nReturn an error from cs_dsp_power_up() if a block header is longer\nthan the amount of data left in the file.\r\n\r\nThe previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop\nwhile there was enough data left in the file for a valid region. This\nprotected against overrunning the end of the file data, but it didn\u0026apos;t\nabort the file processing with an error.(CVE-2024-42238)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fail bpf_timer_cancel when callback is being cancelled\r\n\r\nGiven a schedule:\r\n\r\ntimer1 cb\t\t\ttimer2 cb\r\n\r\nbpf_timer_cancel(timer2);\tbpf_timer_cancel(timer1);\r\n\r\nBoth bpf_timer_cancel calls would wait for the other callback to finish\nexecuting, introducing a lockup.\r\n\r\nAdd an atomic_t count named \u0026apos;cancelling\u0026apos; in bpf_hrtimer. This keeps\ntrack of all in-flight cancellation requests for a given BPF timer.\nWhenever cancelling a BPF timer, we must check if we have outstanding\ncancellation requests, and if so, we must fail the operation with an\nerror (-EDEADLK) since cancellation is synchronous and waits for the\ncallback to finish executing. This implies that we can enter a deadlock\nsituation involving two or more timer callbacks executing in parallel\nand attempting to cancel one another.\r\n\r\nNote that we avoid incrementing the cancelling counter for the target\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\na callback, to avoid spurious errors. The whole point of detecting\ncur-\u0026gt;cancelling and returning -EDEADLK is to not enter a busy wait loop\n(which may or may not lead to a lockup). This does not apply in case the\ncaller is in a non-callback context, the other side can continue to\ncancel as it sees fit without running into errors.\r\n\r\nBackground on prior attempts:\r\n\r\nEarlier versions of this patch used a bool \u0026apos;cancelling\u0026apos; bit and used the\nfollowing pattern under timer-\u0026gt;lock to publish cancellation status.\r\n\r\nlock(t-\u0026gt;lock);\nt-\u0026gt;cancelling = true;\nmb();\nif (cur-\u0026gt;cancelling)\n\treturn -EDEADLK;\nunlock(t-\u0026gt;lock);\nhrtimer_cancel(t-\u0026gt;timer);\nt-\u0026gt;cancelling = false;\r\n\r\nThe store outside the critical section could overwrite a parallel\nrequests t-\u0026gt;cancelling assignment to true, to ensure the parallely\nexecuting callback observes its cancellation status.\r\n\r\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\nis done, but lack of serialization introduced races. Another option was\nexplored where bpf_timer_start would clear the bit when (re)starting the\ntimer under timer-\u0026gt;lock. This would ensure serialized access to the\ncancelling bit, but may allow it to be cleared before in-flight\nhrtimer_cancel has finished executing, such that lockups can occur\nagain.\r\n\r\nThus, we choose an atomic counter to keep track of all outstanding\ncancellation requests and use it to prevent lockups in case callbacks\nattempt to cancel each other while executing in parallel.(CVE-2024-42239)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/bhi: Avoid warning in #DB handler due to BHI mitigation\r\n\r\nWhen BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set\nthen entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the\nclear_bhb_loop() before the TF flag is cleared. This causes the #DB handler\n(exc_debug_kernel()) to issue a warning because single-step is used outside the\nentry_SYSENTER_compat() function.\r\n\r\nTo address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY\nafter making sure the TF flag is cleared.\r\n\r\nThe problem can be reproduced with the following sequence:\r\n\r\n  $ cat sysenter_step.c\n  int main()\n  { asm(\u0026quot;pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter\u0026quot;); }\r\n\r\n  $ gcc -o sysenter_step sysenter_step.c\r\n\r\n  $ ./sysenter_step\n  Segmentation fault (core dumped)\r\n\r\nThe program is expected to crash, and the #DB handler will issue a warning.\r\n\r\nKernel log:\r\n\r\n  WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160\n  ...\n  RIP: 0010:exc_debug_kernel+0xd2/0x160\n  ...\n  Call Trace:\n  \u0026lt;#DB\u0026gt;\n   ? show_regs+0x68/0x80\n   ? __warn+0x8c/0x140\n   ? exc_debug_kernel+0xd2/0x160\n   ? report_bug+0x175/0x1a0\n   ? handle_bug+0x44/0x90\n   ? exc_invalid_op+0x1c/0x70\n   ? asm_exc_invalid_op+0x1f/0x30\n   ? exc_debug_kernel+0xd2/0x160\n   exc_debug+0x43/0x50\n   asm_exc_debug+0x1e/0x40\n  RIP: 0010:clear_bhb_loop+0x0/0xb0\n  ...\n  \u0026lt;/#DB\u0026gt;\n  \u0026lt;TASK\u0026gt;\n   ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d\n  \u0026lt;/TASK\u0026gt;\r\n\r\n  [ bp: Massage commit message. ](CVE-2024-42240)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/shmem: disable PMD-sized page cache if needed\r\n\r\nFor shmem files, it\u0026apos;s possible that PMD-sized page cache can\u0026apos;t be\nsupported by xarray.  For example, 512MB page cache on ARM64 when the base\npage size is 64KB can\u0026apos;t be supported by xarray.  It leads to errors as the\nfollowing messages indicate when this sort of xarray entry is split.\r\n\r\nWARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6   \\\nnft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject        \\\nnft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4  \\\nip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs  \\\nlibcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \\\nnet_failover virtio_console virtio_blk failover dimlib virtio_mmio\nCPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : xas_split_alloc+0xf8/0x128\nlr : split_huge_page_to_list_to_order+0x1c4/0x720\nsp : ffff8000882af5f0\nx29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768\nx26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858\nx23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000\nx20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000\nx14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020\nx11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c\nx8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0\nx5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0\nx2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000\nCall trace:\n xas_split_alloc+0xf8/0x128\n split_huge_page_to_list_to_order+0x1c4/0x720\n truncate_inode_partial_folio+0xdc/0x160\n shmem_undo_range+0x2bc/0x6a8\n shmem_fallocate+0x134/0x430\n vfs_fallocate+0x124/0x2e8\n ksys_fallocate+0x4c/0xa0\n __arm64_sys_fallocate+0x24/0x38\n invoke_syscall.constprop.0+0x7c/0xd8\n do_el0_svc+0xb4/0xd0\n el0_svc+0x44/0x1d8\n el0t_64_sync_handler+0x134/0x150\n el0t_64_sync+0x17c/0x180\r\n\r\nFix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger\nthan MAX_PAGECACHE_ORDER.  As Matthew Wilcox pointed, the page cache in a\nshmem file isn\u0026apos;t represented by a multi-index entry and doesn\u0026apos;t have this\nlimitation when the xarry entry is split until commit 6b24ca4a1a8d (\u0026quot;mm:\nUse multi-index entries in the page cache\u0026quot;).(CVE-2024-42241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray\r\n\r\nPatch series \u0026quot;mm/filemap: Limit page cache size to that supported by\nxarray\u0026quot;, v2.\r\n\r\nCurrently, xarray can\u0026apos;t support arbitrary page cache size.  More details\ncan be found from the WARN_ON() statement in xas_split_alloc().  In our\ntest whose code is attached below, we hit the WARN_ON() on ARM64 system\nwhere the base page size is 64KB and huge page size is 512MB.  The issue\nwas reported long time ago and some discussions on it can be found here\n[1].\r\n\r\n[1] https://www.spinics.net/lists/linux-xfs/msg75404.html\r\n\r\nIn order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one\nsupported by xarray and avoid PMD-sized page cache if needed.  The code\nchanges are suggested by David Hildenbrand.\r\n\r\nPATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray\nPATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path\nPATCH[4] avoids PMD-sized page cache for shmem files if needed\r\n\r\nTest program\n============\n# cat test.c\n#define _GNU_SOURCE\n#include \u0026lt;stdio.h\u0026gt;\n#include \u0026lt;stdlib.h\u0026gt;\n#include \u0026lt;unistd.h\u0026gt;\n#include \u0026lt;string.h\u0026gt;\n#include \u0026lt;fcntl.h\u0026gt;\n#include \u0026lt;errno.h\u0026gt;\n#include \u0026lt;sys/syscall.h\u0026gt;\n#include \u0026lt;sys/mman.h\u0026gt;\r\n\r\n#define TEST_XFS_FILENAME\t\u0026quot;/tmp/data\u0026quot;\n#define TEST_SHMEM_FILENAME\t\u0026quot;/dev/shm/data\u0026quot;\n#define TEST_MEM_SIZE\t\t0x20000000\r\n\r\nint main(int argc, char **argv)\n{\n\tconst char *filename;\n\tint fd = 0;\n\tvoid *buf = (void *)-1, *p;\n\tint pgsize = getpagesize();\n\tint ret;\r\n\r\n\tif (pgsize != 0x10000) {\n\t\tfprintf(stderr, \u0026quot;64KB base page size is required\\n\u0026quot;);\n\t\treturn -EPERM;\n\t}\r\n\r\n\tsystem(\u0026quot;echo force \u0026gt; /sys/kernel/mm/transparent_hugepage/shmem_enabled\u0026quot;);\n\tsystem(\u0026quot;rm -fr /tmp/data\u0026quot;);\n\tsystem(\u0026quot;rm -fr /dev/shm/data\u0026quot;);\n\tsystem(\u0026quot;echo 1 \u0026gt; /proc/sys/vm/drop_caches\u0026quot;);\r\n\r\n\t/* Open xfs or shmem file */\n\tfilename = TEST_XFS_FILENAME;\n\tif (argc \u0026gt; 1 \u0026amp;\u0026amp; !strcmp(argv[1], \u0026quot;shmem\u0026quot;))\n\t\tfilename = TEST_SHMEM_FILENAME;\r\n\r\n\tfd = open(filename, O_CREAT | O_RDWR | O_TRUNC);\n\tif (fd \u0026lt; 0) {\n\t\tfprintf(stderr, \u0026quot;Unable to open \u0026lt;%s\u0026gt;\\n\u0026quot;, filename);\n\t\treturn -EIO;\n\t}\r\n\r\n\t/* Extend file size */\n\tret = ftruncate(fd, TEST_MEM_SIZE);\n\tif (ret) {\n\t\tfprintf(stderr, \u0026quot;Error %d to ftruncate()\\n\u0026quot;, ret);\n\t\tgoto cleanup;\n\t}\r\n\r\n\t/* Create VMA */\n\tbuf = mmap(NULL, TEST_MEM_SIZE,\n\t\t   PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);\n\tif (buf == (void *)-1) {\n\t\tfprintf(stderr, \u0026quot;Unable to mmap \u0026lt;%s\u0026gt;\\n\u0026quot;, filename);\n\t\tgoto cleanup;\n\t}\r\n\r\n\tfprintf(stdout, \u0026quot;mapped buffer at 0x%p\\n\u0026quot;, buf);\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);\n        if (ret) {\n\t\tfprintf(stderr, \u0026quot;Unable to madvise(MADV_HUGEPAGE)\\n\u0026quot;);\n\t\tgoto cleanup;\n\t}\r\n\r\n\t/* Populate VMA */\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE);\n\tif (ret) {\n\t\tfprintf(stderr, \u0026quot;Error %d to madvise(MADV_POPULATE_WRITE)\\n\u0026quot;, ret);\n\t\tgoto cleanup;\n\t}\r\n\r\n\t/* Punch the file to enforce xarray split */\n\tret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,\n        \t\tTEST_MEM_SIZE - pgsize, pgsize);\n\tif (ret)\n\t\tfprintf(stderr, \u0026quot;Error %d to fallocate()\\n\u0026quot;, ret);\r\n\r\ncleanup:\n\tif (buf != (void *)-1)\n\t\tmunmap(buf, TEST_MEM_SIZE);\n\tif (fd \u0026gt; 0)\n\t\tclose(fd);\r\n\r\n\treturn 0;\n}\r\n\r\n# gcc test.c -o test\n# cat /proc/1/smaps | grep KernelPageSize | head -n 1\nKernelPageSize:       64 kB\n# ./test shmem\n   :\n------------[ cut here ]------------\nWARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \\\nnft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \\\nnft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \\\nip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon          \\\ndrm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64  \\\nvirtio_net sha1_ce net_failover failover virtio_console virtio_blk \\\ndimlib virtio_mmio\nCPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TC\n---truncated---(CVE-2024-42243)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: ma35d1: Add a NULL check for of_node\r\n\r\nThe pdev-\u0026gt;dev.of_node can be NULL if the \u0026quot;serial\u0026quot; node is absent.\nAdd a NULL check to return an error in such cases.(CVE-2024-42248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: add missing lock protection when polling\r\n\r\nAdd missing lock protection in poll routine when iterating xarray,\notherwise:\r\n\r\nEven with RCU read lock held, only the slot of the radix tree is\nensured to be pinned there, while the data structure (e.g. struct\ncachefiles_req) stored in the slot has no such guarantee.  The poll\nroutine will iterate the radix tree and dereference cachefiles_req\naccordingly.  Thus RCU read lock is not adequate in this case and\nspinlock is needed here.(CVE-2024-42250)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: pca953x: fix pca953x_irq_bus_sync_unlock race\r\n\r\nEnsure that `i2c_lock\u0026apos; is held when setting interrupt latch and mask in\npca953x_irq_bus_sync_unlock() in order to avoid races.\r\n\r\nThe other (non-probe) call site pca953x_gpio_set_multiple() ensures the\nlock is held before calling pca953x_write_regs().\r\n\r\nThe problem occurred when a request raced against irq_bus_sync_unlock()\napproximately once per thousand reboots on an i.MX8MP based system.\r\n\r\n * Normal case\r\n\r\n   0-0022: write register AI|3a {03,02,00,00,01} Input latch P0\n   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0\n   0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n   0-0022: write register AI|12 {fc,00,00,00,00} Config P3\r\n\r\n * Race case\r\n\r\n   0-0022: write register AI|08 {ff,00,00,00,00} Output P3\n   0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***\n   0-0022: write register AI|12 {fc,00,00,00,00} Config P3\n   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0(CVE-2024-42253)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines\r\n\r\nYves-Alexis Perez reported commit 4ef9ad19e176 (\u0026quot;mm: huge_memory: don\u0026apos;t\nforce huge page alignment on 32 bit\u0026quot;) didn\u0026apos;t work for x86_32 [1].  It is\nbecause x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT.\r\n\r\n!CONFIG_64BIT should cover all 32 bit machines.\r\n\r\n[1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/(CVE-2024-42258)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\r\n\r\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\r\n\r\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\r\n\r\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\r\n\r\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\u0026quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset\u0026quot;)\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966]  [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330]  [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336]  [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341]  [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345]  [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815]  [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820]  [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826]  [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832]  [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841]  [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321]  [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: act_ct: take care of padding in struct zones_ht_key\r\n\r\nBlamed commit increased lookup key size from 2 bytes to 16 bytes,\nbecause zones_ht_key got a struct net pointer.\r\n\r\nMake sure rhashtable_lookup() is not using the padding bytes\nwhich are not initialized.\r\n\r\n BUG: KMSAN: uninit-value in rht_ptr_rcu include/linux/rhashtable.h:376 [inline]\n BUG: KMSAN: uninit-value in __rhashtable_lookup include/linux/rhashtable.h:607 [inline]\n BUG: KMSAN: uninit-value in rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n BUG: KMSAN: uninit-value in rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]\n BUG: KMSAN: uninit-value in tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329\n  rht_ptr_rcu include/linux/rhashtable.h:376 [inline]\n  __rhashtable_lookup include/linux/rhashtable.h:607 [inline]\n  rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]\n  tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329\n  tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408\n  tcf_action_init_1+0x6cc/0xb30 net/sched/act_api.c:1425\n  tcf_action_init+0x458/0xf00 net/sched/act_api.c:1488\n  tcf_action_add net/sched/act_api.c:2061 [inline]\n  tc_ctl_action+0x4be/0x19d0 net/sched/act_api.c:2118\n  rtnetlink_rcv_msg+0x12fc/0x1410 net/core/rtnetlink.c:6647\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2550\n  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6665\n  netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]\n  netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1357\n  netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1901\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  ____sys_sendmsg+0x877/0xb60 net/socket.c:2597\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2651\n  __sys_sendmsg net/socket.c:2680 [inline]\n  __do_sys_sendmsg net/socket.c:2689 [inline]\n  __se_sys_sendmsg net/socket.c:2687 [inline]\n  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2687\n  x64_sys_call+0x2dd6/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:47\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nLocal variable key created at:\n  tcf_ct_flow_table_get+0x4a/0x2260 net/sched/act_ct.c:324\n  tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408(CVE-2024-42272)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-pci: add missing condition check for existence of mapped data\r\n\r\nnvme_map_data() is called when request has physical segments, hence\nthe nvme_unmap_data() should have same condition to avoid dereference.(CVE-2024-42276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: sprd: Avoid NULL deref in sprd_iommu_hw_en\r\n\r\nIn sprd_iommu_cleanup() before calling function sprd_iommu_hw_en()\ndom-\u0026gt;sdev is equal to NULL, which leads to null dereference.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42277)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer\r\n\r\nWhile transmitting with rx_len == 0, the RX FIFO is not going to be\nemptied in the interrupt handler. A subsequent transfer could then\nread crap from the previous transfer out of the RX FIFO into the\nstart RX buffer. The core provides a register that will empty the RX and\nTX FIFOs, so do that before each transfer.(CVE-2024-42279)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add a per-VF limit on number of FDIR filters\r\n\r\nWhile the iavf driver adds a s/w limit (128) on the number of FDIR\nfilters that the VF can request, a malicious VF driver can request more\nthan that and exhaust the resources for other VFs.\r\n\r\nAdd a similar limit in ice.(CVE-2024-42291)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix deadlock between sd_remove \u0026amp; sd_release\r\n\r\nOur test report the following hung task:\r\n\r\n[ 2538.459400] INFO: task \u0026quot;kworker/0:0\u0026quot;:7 blocked for more than 188 seconds.\n[ 2538.459427] Call trace:\n[ 2538.459430]  __switch_to+0x174/0x338\n[ 2538.459436]  __schedule+0x628/0x9c4\n[ 2538.459442]  schedule+0x7c/0xe8\n[ 2538.459447]  schedule_preempt_disabled+0x24/0x40\n[ 2538.459453]  __mutex_lock+0x3ec/0xf04\n[ 2538.459456]  __mutex_lock_slowpath+0x14/0x24\n[ 2538.459459]  mutex_lock+0x30/0xd8\n[ 2538.459462]  del_gendisk+0xdc/0x350\n[ 2538.459466]  sd_remove+0x30/0x60\n[ 2538.459470]  device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459474]  device_release_driver+0x18/0x28\n[ 2538.459478]  bus_remove_device+0x15c/0x174\n[ 2538.459483]  device_del+0x1d0/0x358\n[ 2538.459488]  __scsi_remove_device+0xa8/0x198\n[ 2538.459493]  scsi_forget_host+0x50/0x70\n[ 2538.459497]  scsi_remove_host+0x80/0x180\n[ 2538.459502]  usb_stor_disconnect+0x68/0xf4\n[ 2538.459506]  usb_unbind_interface+0xd4/0x280\n[ 2538.459510]  device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459514]  device_release_driver+0x18/0x28\n[ 2538.459518]  bus_remove_device+0x15c/0x174\n[ 2538.459523]  device_del+0x1d0/0x358\n[ 2538.459528]  usb_disable_device+0x84/0x194\n[ 2538.459532]  usb_disconnect+0xec/0x300\n[ 2538.459537]  hub_event+0xb80/0x1870\n[ 2538.459541]  process_scheduled_works+0x248/0x4dc\n[ 2538.459545]  worker_thread+0x244/0x334\n[ 2538.459549]  kthread+0x114/0x1bc\r\n\r\n[ 2538.461001] INFO: task \u0026quot;fsck.\u0026quot;:15415 blocked for more than 188 seconds.\n[ 2538.461014] Call trace:\n[ 2538.461016]  __switch_to+0x174/0x338\n[ 2538.461021]  __schedule+0x628/0x9c4\n[ 2538.461025]  schedule+0x7c/0xe8\n[ 2538.461030]  blk_queue_enter+0xc4/0x160\n[ 2538.461034]  blk_mq_alloc_request+0x120/0x1d4\n[ 2538.461037]  scsi_execute_cmd+0x7c/0x23c\n[ 2538.461040]  ioctl_internal_command+0x5c/0x164\n[ 2538.461046]  scsi_set_medium_removal+0x5c/0xb0\n[ 2538.461051]  sd_release+0x50/0x94\n[ 2538.461054]  blkdev_put+0x190/0x28c\n[ 2538.461058]  blkdev_release+0x28/0x40\n[ 2538.461063]  __fput+0xf8/0x2a8\n[ 2538.461066]  __fput_sync+0x28/0x5c\n[ 2538.461070]  __arm64_sys_close+0x84/0xe8\n[ 2538.461073]  invoke_syscall+0x58/0x114\n[ 2538.461078]  el0_svc_common+0xac/0xe0\n[ 2538.461082]  do_el0_svc+0x1c/0x28\n[ 2538.461087]  el0_svc+0x38/0x68\n[ 2538.461090]  el0t_64_sync_handler+0x68/0xbc\n[ 2538.461093]  el0t_64_sync+0x1a8/0x1ac\r\n\r\n  T1:\t\t\t\tT2:\n  sd_remove\n  del_gendisk\n  __blk_mark_disk_dead\n  blk_freeze_queue_start\n  ++q-\u0026gt;mq_freeze_depth\n  \t\t\t\tbdev_release\n \t\t\t\tmutex_lock(\u0026amp;disk-\u0026gt;open_mutex)\n  \t\t\t\tsd_release\n \t\t\t\tscsi_execute_cmd\n \t\t\t\tblk_queue_enter\n \t\t\t\twait_event(!q-\u0026gt;mq_freeze_depth)\n  mutex_lock(\u0026amp;disk-\u0026gt;open_mutex)\r\n\r\nSCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in\nthis scenario. This is a classic ABBA deadlock. To fix the deadlock,\nmake sure we don\u0026apos;t try to acquire disk-\u0026gt;open_mutex after freezing\nthe queue.(CVE-2024-42294)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix return value of f2fs_convert_inline_inode()\r\n\r\nIf device is readonly, make f2fs_convert_inline_inode()\nreturn EROFS instead of zero, otherwise it may trigger\npanic during writeback of inline inode\u0026apos;s dirty page as\nbelow:\r\n\r\n f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888\n f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369\n do_writepages+0x359/0x870 mm/page-writeback.c:2634\n filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397\n __filemap_fdatawrite_range mm/filemap.c:430 [inline]\n file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788\n f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276\n generic_write_sync include/linux/fs.h:2806 [inline]\n f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977\n call_write_iter include/linux/fs.h:2114 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xa72/0xc90 fs/read_write.c:590\n ksys_write+0x1a0/0x2c0 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-42296)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: fsl: fsl_qmc_audio: Check devm_kasprintf() returned value\r\n\r\ndevm_kasprintf() can return a NULL pointer on failure but this returned\nvalue is not checked.\r\n\r\nFix this lack and check the returned value.(CVE-2024-42298)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imx-pxp: Fix ERR_PTR dereference in pxp_probe()\r\n\r\ndevm_regmap_init_mmio() can fail, add a check and bail out in case of\nerror.(CVE-2024-42303)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: fix potential null pointer use in destroy_workqueue in init_cifs error path\r\n\r\nDan Carpenter reported a Smack static checker warning:\n   fs/smb/client/cifsfs.c:1981 init_cifs()\n   error: we previously assumed \u0026apos;serverclose_wq\u0026apos; could be null (see line 1895)\r\n\r\nThe patch which introduced the serverclose workqueue used the wrong\noredering in error paths in init_cifs() for freeing it on errors.(CVE-2024-42307)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix extent map use-after-free when adding pages to compressed bio\r\n\r\nAt add_ra_bio_pages() we are accessing the extent map to calculate\n\u0026apos;add_size\u0026apos; after we dropped our reference on the extent map, resulting\nin a use-after-free. Fix this by computing \u0026apos;add_size\u0026apos; before dropping our\nextent map reference.(CVE-2024-42314)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n       CPU0                CPU1\n       ----                ----\n  kswapd\n   balance_pgdat\n    lock(fs_reclaim)\n                      exfat_iterate\n                       lock(\u0026amp;sbi-\u0026gt;s_lock)\n                       exfat_readdir\n                        exfat_get_uniname_from_ext_entry\n                         exfat_get_dentry_set\n                          __exfat_get_dentry_set\n                           kmalloc_array\n                            ...\n                            lock(fs_reclaim)\n    ...\n    evict\n     exfat_evict_inode\n      lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/mglru: fix div-by-zero in vmpressure_calc_level()\r\n\r\nevict_folios() uses a second pass to reclaim folios that have gone through\npage writeback and become clean before it finishes the first pass, since\nfolio_rotate_reclaimable() cannot handle those folios due to the\nisolation.\r\n\r\nThe second pass tries to avoid potential double counting by deducting\nscan_control-\u0026gt;nr_scanned.  However, this can result in underflow of\nnr_scanned, under a condition where shrink_folio_list() does not increment\nnr_scanned, i.e., when folio_trylock() fails.\r\n\r\nThe underflow can cause the divisor, i.e., scale=scanned+reclaimed in\nvmpressure_calc_level(), to become zero, resulting in the following crash:\r\n\r\n  [exception RIP: vmpressure_work_fn+101]\n  process_one_work at ffffffffa3313f2b\r\n\r\nSince scan_control-\u0026gt;nr_scanned has no established semantics, the potential\ndouble counting has minimal risks.  Therefore, fix the problem by not\ndeducting scan_control-\u0026gt;nr_scanned in evict_folios().(CVE-2024-42316)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/huge_memory: avoid PMD-size page cache if needed\r\n\r\nxarray can\u0026apos;t support arbitrary page cache size.  the largest and supported\npage cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71\n(\u0026quot;mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray\u0026quot;).  However,\nit\u0026apos;s possible to have 512MB page cache in the huge memory\u0026apos;s collapsing\npath on ARM64 system whose base page size is 64KB.  512MB page cache is\nbreaking the limitation and a warning is raised when the xarray entry is\nsplit as shown in the following example.\r\n\r\n[root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize\nKernelPageSize:       64 kB\n[root@dhcp-10-26-1-207 ~]# cat /tmp/test.c\n   :\nint main(int argc, char **argv)\n{\n\tconst char *filename = TEST_XFS_FILENAME;\n\tint fd = 0;\n\tvoid *buf = (void *)-1, *p;\n\tint pgsize = getpagesize();\n\tint ret = 0;\r\n\r\n\tif (pgsize != 0x10000) {\n\t\tfprintf(stdout, \u0026quot;System with 64KB base page size is required!\\n\u0026quot;);\n\t\treturn -EPERM;\n\t}\r\n\r\n\tsystem(\u0026quot;echo 0 \u0026gt; /sys/devices/virtual/bdi/253:0/read_ahead_kb\u0026quot;);\n\tsystem(\u0026quot;echo 1 \u0026gt; /proc/sys/vm/drop_caches\u0026quot;);\r\n\r\n\t/* Open the xfs file */\n\tfd = open(filename, O_RDONLY);\n\tassert(fd \u0026gt; 0);\r\n\r\n\t/* Create VMA */\n\tbuf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0);\n\tassert(buf != (void *)-1);\n\tfprintf(stdout, \u0026quot;mapped buffer at 0x%p\\n\u0026quot;, buf);\r\n\r\n\t/* Populate VMA */\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE);\n\tassert(ret == 0);\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ);\n\tassert(ret == 0);\r\n\r\n\t/* Collapse VMA */\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);\n\tassert(ret == 0);\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE);\n\tif (ret) {\n\t\tfprintf(stdout, \u0026quot;Error %d to madvise(MADV_COLLAPSE)\\n\u0026quot;, errno);\n\t\tgoto out;\n\t}\r\n\r\n\t/* Split xarray entry. Write permission is needed */\n\tmunmap(buf, TEST_MEM_SIZE);\n\tbuf = (void *)-1;\n\tclose(fd);\n\tfd = open(filename, O_RDWR);\n\tassert(fd \u0026gt; 0);\n\tfallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,\n \t\t  TEST_MEM_SIZE - pgsize, pgsize);\nout:\n\tif (buf != (void *)-1)\n\t\tmunmap(buf, TEST_MEM_SIZE);\n\tif (fd \u0026gt; 0)\n\t\tclose(fd);\r\n\r\n\treturn ret;\n}\r\n\r\n[root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test\n[root@dhcp-10-26-1-207 ~]# /tmp/test\n ------------[ cut here ]------------\n WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\n Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib    \\\n nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct      \\\n nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4      \\\n ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse   \\\n xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net  \\\n sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio\n CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9\n Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\n pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : xas_split_alloc+0xf8/0x128\n lr : split_huge_page_to_list_to_order+0x1c4/0x780\n sp : ffff8000ac32f660\n x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0\n x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d\n x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000\n x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c\n x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8\n x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40\n x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000\n Call trace:\n  xas_split_alloc+0xf8/0x128\n  split_huge_page_to_list_to_order+0x1c4/0x780\n  truncate_inode_partial_folio+0xdc/0x160\n  truncate_inode_pages_range+0x1b4/0x4a8\n  truncate_pagecache_range+0x84/0xa\n---truncated---(CVE-2024-42317)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error checks in dasd_copy_pair_store()\r\n\r\ndasd_add_busid() can return an error via ERR_PTR() if an allocation\nfails. However, two callsites in dasd_copy_pair_store() do not check\nthe result, potentially resulting in a NULL pointer dereference. Fix\nthis by checking the result with IS_ERR() and returning the error up\nthe stack.(CVE-2024-42320)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: flow_dissector: use DEBUG_NET_WARN_ON_ONCE\r\n\r\nThe following splat is easy to reproduce upstream as well as in -stable\nkernels. Florian Westphal provided the following commit:\r\n\r\n  d1dab4f71d37 (\u0026quot;net: add and use __skb_get_hash_symmetric_net\u0026quot;)\r\n\r\nbut this complementary fix has been also suggested by Willem de Bruijn\nand it can be easily backported to -stable kernel which consists in\nusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splat\ngiven __skb_get_hash() is used by the nftables tracing infrastructure to\nto identify packets in traces.\r\n\r\n[69133.561393] ------------[ cut here ]------------\n[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/\n[...]\n[69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379\n[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0\n[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff\nff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff \u0026lt;0f\u0026gt; 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8\n[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246\n[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19\n[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418\n[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000\n[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400\n[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28\n[69133.562020] FS:  00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[69133.562027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0\n[69133.562040] Call Trace:\n[69133.562044]  \u0026lt;IRQ\u0026gt;\n[69133.562049]  ? __warn+0x9f/0x1a0\n[ 1211.841384]  ? __skb_flow_dissect+0x107e/0x2860\n[...]\n[ 1211.841496]  ? bpf_flow_dissect+0x160/0x160\n[ 1211.841753]  __skb_get_hash+0x97/0x280\n[ 1211.841765]  ? __skb_get_hash_symmetric+0x230/0x230\n[ 1211.841776]  ? mod_find+0xbf/0xe0\n[ 1211.841786]  ? get_stack_info_noinstr+0x12/0xe0\n[ 1211.841798]  ? bpf_ksym_find+0x56/0xe0\n[ 1211.841807]  ? __rcu_read_unlock+0x2a/0x70\n[ 1211.841819]  nft_trace_init+0x1b9/0x1c0 [nf_tables]\n[ 1211.841895]  ? nft_trace_notify+0x830/0x830 [nf_tables]\n[ 1211.841964]  ? get_stack_info+0x2b/0x80\n[ 1211.841975]  ? nft_do_chain_arp+0x80/0x80 [nf_tables]\n[ 1211.842044]  nft_do_chain+0x79c/0x850 [nf_tables](CVE-2024-42321)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: missing check virtio\r\n\r\nTwo missing check in virtio_net_hdr_to_skb() allowed syzbot\nto crash kernels again\r\n\r\n1. After the skb_segment function the buffer may become non-linear\n(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere\nthe __skb_linearize function will not be executed, then the buffer will\nremain non-linear. Then the condition (offset \u0026gt;= skb_headlen(skb))\nbecomes true, which causes WARN_ON_ONCE in skb_checksum_help.\r\n\r\n2. The struct sk_buff and struct virtio_net_hdr members must be\nmathematically related.\n(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) may be 0 if division is without remainder.\r\n\r\noffset+2 (4191) \u0026gt; skb_headlen() (1116)\nWARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nModules linked in:\nCPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nRIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nCode: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 \u0026lt;0f\u0026gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef\nRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209\nRDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001\nRBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c\nR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d\nFS:  0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777\n ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584\n ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]\n __ip_finish_output net/ipv4/ip_output.c:308 [inline]\n __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:451 [inline]\n ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]\n sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3545 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x257/0x380 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n __sys_sendto+0x255/0x340 net/socket.c:2190\n __do_sys_sendto net/socket.c:2202 [inline]\n __se_sys_sendto net/socket.c:2198 [inline]\n __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: amd: Adjust error handling in case of absent codec device\r\n\r\nacpi_get_first_physical_node() can return NULL in several cases (no such\ndevice, ACPI table error, reference count drop to 0, etc).\nExisting check just emit error message, but doesn\u0026apos;t perform return.\nThen this NULL pointer is passed to devm_acpi_dev_add_driver_gpios()\nwhere it is dereferenced.\r\n\r\nAdjust this error handling by adding error code return.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix a possible null pointer dereference\r\n\r\nIn function lpfc_xcvr_data_show, the memory allocation with kmalloc might\nfail, thereby making rdp_context a null pointer. In the following context\nand functions that use this pointer, there are dereferencing operations,\nleading to null pointer dereference.\r\n\r\nTo fix this issue, a null pointer check should be added. If it is null,\nuse scnprintf to notify the user and return len.(CVE-2024-43821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: Fix the sorting functionality in iio_gts_build_avail_time_table\r\n\r\nThe sorting in iio_gts_build_avail_time_table is not working as intended.\nIt could result in an out-of-bounds access when the time is zero.\r\n\r\nHere are more details:\r\n\r\n1. When the gts-\u0026gt;itime_table[i].time_us is zero, e.g., the time\nsequence is `3, 0, 1`, the inner for-loop will not terminate and do\nout-of-bound writes. This is because once `times[j] \u0026gt; new`, the value\n`new` will be added in the current position and the `times[j]` will be\nmoved to `j+1` position, which makes the if-condition always hold.\nMeanwhile, idx will be added one, making the loop keep running without\ntermination and out-of-bound write.\n2. If none of the gts-\u0026gt;itime_table[i].time_us is zero, the elements\nwill just be copied without being sorted as described in the comment\n\u0026quot;Sort times from all tables to one and remove duplicates\u0026quot;.\r\n\r\nFor more details, please refer to\nhttps://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.(CVE-2024-43825)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: pass explicit offset/count to trace events\r\n\r\nnfs_folio_length is unsafe to use without having the folio locked and a\ncheck for a NULL -\u0026gt;f_mapping that protects against truncations and can\nlead to kernel crashes.  E.g. when running xfstests generic/065 with\nall nfs trace points enabled.\r\n\r\nFollow the model of the XFS trace points and pass in an expl\u0456cit offset\nand length.  This has the additional benefit that these values can\nbe more accurate as some of the users touch partial folio ranges.(CVE-2024-43826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/qxl: Add check for drm_cvt_mode\r\n\r\nAdd check for the return value of drm_cvt_mode() and return the error if\nit fails in order to avoid NULL pointer dereference.(CVE-2024-43829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/uv: Don\u0026apos;t call folio_wait_writeback() without a folio reference\r\n\r\nfolio_wait_writeback() requires that no spinlocks are held and that\na folio reference is held, as documented. After we dropped the PTL, the\nfolio could get freed concurrently. So grab a temporary reference.(CVE-2024-43832)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l: async: Fix NULL pointer dereference in adding ancillary links\r\n\r\nIn v4l2_async_create_ancillary_links(), ancillary links are created for\nlens and flash sub-devices. These are sub-device to sub-device links and\nif the async notifier is related to a V4L2 device, the source sub-device\nof the ancillary link is NULL, leading to a NULL pointer dereference.\nCheck the notifier\u0026apos;s sd field is non-NULL in\nv4l2_async_create_ancillary_links().\r\n\r\n[Sakari Ailus: Reword the subject and commit messages slightly.](CVE-2024-43833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT\r\n\r\nWhen loading a EXT program without specifying `attr-\u0026gt;attach_prog_fd`,\nthe `prog-\u0026gt;aux-\u0026gt;dst_prog` will be null. At this time, calling\nresolve_prog_type() anywhere will result in a null pointer dereference.\r\n\r\nExample stack trace:\r\n\r\n[    8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n[    8.108262] Mem abort info:\n[    8.108384]   ESR = 0x0000000096000004\n[    8.108547]   EC = 0x25: DABT (current EL), IL = 32 bits\n[    8.108722]   SET = 0, FnV = 0\n[    8.108827]   EA = 0, S1PTW = 0\n[    8.108939]   FSC = 0x04: level 0 translation fault\n[    8.109102] Data abort info:\n[    8.109203]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[    8.109399]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[    8.109614]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[    8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000\n[    8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000\n[    8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[    8.112783] Modules linked in:\n[    8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1\n[    8.113230] Hardware name: linux,dummy-virt (DT)\n[    8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    8.113429] pc : may_access_direct_pkt_data+0x24/0xa0\n[    8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8\n[    8.113798] sp : ffff80008283b9f0\n[    8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001\n[    8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000\n[    8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000\n[    8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff\n[    8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720\n[    8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720\n[    8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4\n[    8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f\n[    8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c\n[    8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000\n[    8.114126] Call trace:\n[    8.114159]  may_access_direct_pkt_data+0x24/0xa0\n[    8.114202]  bpf_check+0x3bc/0x28c0\n[    8.114214]  bpf_prog_load+0x658/0xa58\n[    8.114227]  __sys_bpf+0xc50/0x2250\n[    8.114240]  __arm64_sys_bpf+0x28/0x40\n[    8.114254]  invoke_syscall.constprop.0+0x54/0xf0\n[    8.114273]  do_el0_svc+0x4c/0xd8\n[    8.114289]  el0_svc+0x3c/0x140\n[    8.114305]  el0t_64_sync_handler+0x134/0x150\n[    8.114331]  el0t_64_sync+0x168/0x170\n[    8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)\n[    8.118672] ---[ end trace 0000000000000000 ]---\r\n\r\nOne way to fix it is by forcing `attach_prog_fd` non-empty when\nbpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`\nAPI broken which use verifier log to probe prog type and will log\nnothing if we reject invalid EXT prog before bpf_check().\r\n\r\nAnother way is by adding null check in resolve_prog_type().\r\n\r\nThe issue was introduced by commit 4a9c7bbe2ed4 (\u0026quot;bpf: Resolve to\nprog-\u0026gt;aux-\u0026gt;dst_prog-\u0026gt;type only for BPF_PROG_TYPE_EXT\u0026quot;) which wanted\nto correct type resolution for BPF_PROG_TYPE_TRACING programs. Before\nthat, the type resolution of BPF_PROG_TYPE_EXT prog actually follows\nthe logic below:\r\n\r\n  prog-\u0026gt;aux-\u0026gt;dst_prog ? prog-\u0026gt;aux-\u0026gt;dst_prog-\u0026gt;type : prog-\u0026gt;type;\r\n\r\nIt implies that when EXT program is not yet attached to `dst_prog`,\nthe prog type should be EXT itself. This code worked fine in the past.\nSo just keep using it.\r\n\r\nFix this by returning `prog-\u0026gt;type` for BPF_PROG_TYPE_EXT if `dst_prog`\nis not present in resolve_prog_type().(CVE-2024-43837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter()\r\n\r\nIn rtw89_sta_info_get_iter() \u0026apos;status-\u0026gt;he_gi\u0026apos; is compared to array size.\nBut then \u0026apos;rate-\u0026gt;he_gi\u0026apos; is used as array index instead of \u0026apos;status-\u0026gt;he_gi\u0026apos;.\nThis can lead to go beyond array boundaries in case of \u0026apos;rate-\u0026gt;he_gi\u0026apos; is\nnot equal to \u0026apos;status-\u0026gt;he_gi\u0026apos; and is bigger than array size. Looks like\n\u0026quot;copy-paste\u0026quot; mistake.\r\n\r\nFix this mistake by replacing \u0026apos;rate-\u0026gt;he_gi\u0026apos; with \u0026apos;status-\u0026gt;he_gi\u0026apos;.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43842)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Fix bogus checksum computation in udf_rename()\r\n\r\nSyzbot reports uninitialized memory access in udf_rename() when updating\nchecksum of \u0026apos;..\u0026apos; directory entry of a moved directory. This is indeed\ntrue as we pass on-stack diriter.fi to the udf_update_tag() and because\nthat has only struct fileIdentDesc included in it and not the impUse or\nname fields, the checksumming function is going to checksum random stack\ncontents beyond the end of the structure. This is actually harmless\nbecause the following udf_fiiter_write_fi() will recompute the checksum\nfrom on-disk buffers where everything is properly included. So all that\nis needed is just removing the bogus calculation.(CVE-2024-43845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath12k: fix invalid memory access while processing fragmented packets\r\n\r\nThe monitor ring and the reo reinject ring share the same ring mask index.\nWhen the driver receives an interrupt for the reo reinject ring, the\nmonitor ring is also processed, leading to invalid memory access. Since\nmonitor support is not yet enabled in ath12k, the ring mask for the monitor\nring should be removed.\r\n\r\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1(CVE-2024-43847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: pdr: protect locator_addr with the main mutex\r\n\r\nIf the service locator server is restarted fast enough, the PDR can\nrewrite locator_addr fields concurrently. Protect them by placing\nmodification of those fields under the main pdr-\u0026gt;lock.(CVE-2024-43849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove\r\n\r\nThe following warning is seen during bwmon_remove due to refcount\nimbalance, fix this by releasing the OPPs after use.\r\n\r\nLogs:\nWARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158\nHardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT)\n...\nCall trace:\n_opp_table_kref_release+0x150/0x158\ndev_pm_opp_remove_table+0x100/0x1b4\ndevm_pm_opp_of_table_release+0x10/0x1c\ndevm_action_release+0x14/0x20\ndevres_release_all+0xa4/0x104\ndevice_unbind_cleanup+0x18/0x60\ndevice_release_driver_internal+0x1ec/0x228\ndriver_detach+0x50/0x98\nbus_remove_driver+0x6c/0xbc\ndriver_unregister+0x30/0x60\nplatform_driver_unregister+0x14/0x20\nbwmon_driver_exit+0x18/0x524 [icc_bwmon]\n__arm64_sys_delete_module+0x184/0x264\ninvoke_syscall+0x48/0x118\nel0_svc_common.constprop.0+0xc8/0xe8\ndo_el0_svc+0x20/0x2c\nel0_svc+0x34/0xdc\nel0t_64_sync_handler+0x13c/0x158\nel0t_64_sync+0x190/0x194\n--[ end trace 0000000000000000 ]---(CVE-2024-43850)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: xilinx: rename cpu_number1 to dummy_cpu_number\r\n\r\nThe per cpu variable cpu_number1 is passed to xlnx_event_handler as\nargument \u0026quot;dev_id\u0026quot;, but it is not used in this function. So drop the\ninitialization of this variable and rename it to dummy_cpu_number.\nThis patch is to fix the following call trace when the kernel option\nCONFIG_DEBUG_ATOMIC_SLEEP is enabled:\r\n\r\nBUG: sleeping function called from invalid context at include/linux/sched/mm.h:274\n    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n    preempt_count: 1, expected: 0\n    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53\n    Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT)\n    Call trace:\n     dump_backtrace+0xd0/0xe0\n     show_stack+0x18/0x40\n     dump_stack_lvl+0x7c/0xa0\n     dump_stack+0x18/0x34\n     __might_resched+0x10c/0x140\n     __might_sleep+0x4c/0xa0\n     __kmem_cache_alloc_node+0xf4/0x168\n     kmalloc_trace+0x28/0x38\n     __request_percpu_irq+0x74/0x138\n     xlnx_event_manager_probe+0xf8/0x298\n     platform_probe+0x68/0xd8(CVE-2024-43851)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\r\n\r\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev-\u0026gt;flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev-\u0026gt;flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev-\u0026gt;flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: fix call order in dmam_free_coherent\r\n\r\ndmam_free_coherent() frees a DMA allocation, which makes the\nfreed vaddr available for reuse, then calls devres_destroy()\nto remove and free the data structure used to track the DMA\nallocation. Between the two calls, it is possible for a\nconcurrent task to make an allocation with the same vaddr\nand add it to the devres list.\r\n\r\nIf this happens, there will be two entries in the devres list\nwith the same vaddr and devres_destroy() can free the wrong\nentry, triggering the WARN_ON() in dmam_match.\r\n\r\nFix by destroying the devres entry before freeing the DMA\nallocation.\r\n\r\n  kokonut //net/encryption\n    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to truncate preallocated blocks in f2fs_file_open()\r\n\r\nchenyuwen reports a f2fs bug as below:\r\n\r\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000011\n fscrypt_set_bio_crypt_ctx+0x78/0x1e8\n f2fs_grab_read_bio+0x78/0x208\n f2fs_submit_page_read+0x44/0x154\n f2fs_get_read_data_page+0x288/0x5f4\n f2fs_get_lock_data_page+0x60/0x190\n truncate_partial_data_page+0x108/0x4fc\n f2fs_do_truncate_blocks+0x344/0x5f0\n f2fs_truncate_blocks+0x6c/0x134\n f2fs_truncate+0xd8/0x200\n f2fs_iget+0x20c/0x5ac\n do_garbage_collect+0x5d0/0xf6c\n f2fs_gc+0x22c/0x6a4\n f2fs_disable_checkpoint+0xc8/0x310\n f2fs_fill_super+0x14bc/0x1764\n mount_bdev+0x1b4/0x21c\n f2fs_mount+0x20/0x30\n legacy_get_tree+0x50/0xbc\n vfs_get_tree+0x5c/0x1b0\n do_new_mount+0x298/0x4cc\n path_mount+0x33c/0x5fc\n __arm64_sys_mount+0xcc/0x15c\n invoke_syscall+0x60/0x150\n el0_svc_common+0xb8/0xf8\n do_el0_svc+0x28/0xa0\n el0_svc+0x24/0x84\n el0t_64_sync_handler+0x88/0xec\r\n\r\nIt is because inode.i_crypt_info is not initialized during below path:\n- mount\n - f2fs_fill_super\n  - f2fs_disable_checkpoint\n   - f2fs_gc\n    - f2fs_iget\n     - f2fs_truncate\r\n\r\nSo, let\u0026apos;s relocate truncation of preallocated blocks to f2fs_file_open(),\nafter fscrypt_file_open().(CVE-2024-43859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: vhci-hcd: Do not drop references before new references are gained\r\n\r\nAt a few places the driver carries stale pointers\nto references that can still be used. Make sure that does not happen.\nThis strictly speaking closes ZDI-CAN-22273, though there may be\nsimilar races in the driver.(CVE-2024-43883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: MGMT: Add error handling to pair_device()\r\n\r\nhci_conn_params_add() never checks for a NULL value and could lead to a NULL\npointer dereference causing a crash.\r\n\r\nFixed by adding error handling in the function.(CVE-2024-43884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\r\n\r\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\r\n\r\n  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n  [   10.017908] Workqueue: events_unbound padata_mt_helper\n  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n    :\n  [   10.017963] Call Trace:\n  [   10.017968]  \u0026lt;TASK\u0026gt;\n  [   10.018004]  ? padata_mt_helper+0x39/0xb0\n  [   10.018084]  process_one_work+0x174/0x330\n  [   10.018093]  worker_thread+0x266/0x3a0\n  [   10.018111]  kthread+0xcf/0x100\n  [   10.018124]  ret_from_fork+0x31/0x50\n  [   10.018138]  ret_from_fork_asm+0x1a/0x30\n  [   10.018147]  \u0026lt;/TASK\u0026gt;\r\n\r\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps-\u0026gt;chunk_size is 0.  The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\r\n\r\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.(CVE-2024-43889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Fix overflow in get_free_elt()\r\n\r\n\u0026quot;tracing_map-\u0026gt;next_elt\u0026quot; in get_free_elt() is at risk of overflowing.\r\n\r\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \u0026quot;tracing_map-\u0026gt;max_size\u0026quot; elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\r\n\r\nFix this by preventing any further increments to \u0026quot;tracing_map-\u0026gt;next_elt\u0026quot;\nonce it reaches \u0026quot;tracing_map-\u0026gt;max_elt\u0026quot;.(CVE-2024-43890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Have format file honor EVENT_FILE_FL_FREED\r\n\r\nWhen eventfs was introduced, special care had to be done to coordinate the\nfreeing of the file meta data with the files that are exposed to user\nspace. The file meta data would have a ref count that is set when the file\nis created and would be decremented and freed after the last user that\nopened the file closed it. When the file meta data was to be freed, it\nwould set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,\nand any new references made (like new opens or reads) would fail as it is\nmarked freed. This allowed other meta data to be freed after this flag was\nset (under the event_mutex).\r\n\r\nAll the files that were dynamically created in the events directory had a\npointer to the file meta data and would call event_release() when the last\nreference to the user space file was closed. This would be the time that it\nis safe to free the file meta data.\r\n\r\nA shortcut was made for the \u0026quot;format\u0026quot; file. It\u0026apos;s i_private would point to\nthe \u0026quot;call\u0026quot; entry directly and not point to the file\u0026apos;s meta data. This is\nbecause all format files are the same for the same \u0026quot;call\u0026quot;, so it was\nthought there was no reason to differentiate them.  The other files\nmaintain state (like the \u0026quot;enable\u0026quot;, \u0026quot;trigger\u0026quot;, etc). But this meant if the\nfile were to disappear, the \u0026quot;format\u0026quot; file would be unaware of it.\r\n\r\nThis caused a race that could be trigger via the user_events test (that\nwould create dynamic events and free them), and running a loop that would\nread the user_events format files:\r\n\r\nIn one console run:\r\n\r\n # cd tools/testing/selftests/user_events\n # while true; do ./ftrace_test; done\r\n\r\nAnd in another console run:\r\n\r\n # cd /sys/kernel/tracing/\n # while true; do cat events/user_events/__test_event/format; done 2\u0026gt;/dev/null\r\n\r\nWith KASAN memory checking, it would trigger a use-after-free bug report\n(which was a real bug). This was because the format file was not checking\nthe file\u0026apos;s meta data flag \u0026quot;EVENT_FILE_FL_FREED\u0026quot;, so it would access the\nevent that the file meta data pointed to after the event was freed.\r\n\r\nAfter inspection, there are other locations that were found to not check\nthe EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a\nnew helper function: event_file_file() that will make sure that the\nevent_mutex is held, and will return NULL if the trace_event_file has the\nEVENT_FILE_FL_FREED flag set. Have the first reference of the struct file\npointer use event_file_file() and check for NULL. Later uses can still use\nthe event_file_data() helper function if the event_mutex is still held and\nwas not released since the event_file_file() call.(CVE-2024-43891)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip Recompute DSC Params if no Stream on Link\r\n\r\n[why]\nEncounter NULL pointer dereference uner mst + dsc setup.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2\n    Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022\n    RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]\n    Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 \u0026lt;48\u0026gt; 8\u0026gt;\n    RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293\n    RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224\n    RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280\n    RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850\n    R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000\n    R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224\n    FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0\n    Call Trace:\n\u0026lt;TASK\u0026gt;\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? plist_add+0xbe/0x100\n     ? exc_page_fault+0x7c/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n     ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n     compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     drm_atomic_check_only+0x5c5/0xa40\n     drm_mode_atomic_ioctl+0x76e/0xbc0\r\n\r\n[how]\ndsc recompute should be skipped if no mode change detected on the new\nrequest. If detected, keep checking whether the stream is already on\ncurrent state or not.\r\n\r\n(cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef)(CVE-2024-43895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: drop bad gso csum_start and offset in virtio_net_hdr\r\n\r\nTighten csum_start and csum_offset checks in virtio_net_hdr_to_skb\nfor GSO packets.\r\n\r\nThe function already checks that a checksum requested with\nVIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets\nthis might not hold for segs after segmentation.\r\n\r\nSyzkaller demonstrated to reach this warning in skb_checksum_help\r\n\r\n\toffset = skb_checksum_start_offset(skb);\n\tret = -EINVAL;\n\tif (WARN_ON_ONCE(offset \u0026gt;= skb_headlen(skb)))\r\n\r\nBy injecting a TSO packet:\r\n\r\nWARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0\n ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774\n ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]\n __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301\n iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82\n ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813\n __gre_xmit net/ipv4/ip_gre.c:469 [inline]\n ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661\n __netdev_start_xmit include/linux/netdevice.h:4850 [inline]\n netdev_start_xmit include/linux/netdevice.h:4864 [inline]\n xmit_one net/core/dev.c:3595 [inline]\n dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611\n __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261\n packet_snd net/packet/af_packet.c:3073 [inline]\r\n\r\nThe geometry of the bad input packet at tcp_gso_segment:\r\n\r\n[   52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0\n[   52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244\n[   52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))\n[   52.003050][ T8403] csum(0x60000c7 start=199 offset=1536\nip_summed=3 complete_sw=0 valid=0 level=0)\r\n\r\nMitigate with stricter input validation.\r\n\r\ncsum_offset: for GSO packets, deduce the correct value from gso_type.\nThis is already done for USO. Extend it to TSO. Let UFO be:\nudp[46]_ufo_fragment ignores these fields and always computes the\nchecksum in software.\r\n\r\ncsum_start: finding the real offset requires parsing to the transport\nheader. Do not add a parser, use existing segmentation parsing. Thanks\nto SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.\nAgain test both TSO and USO. Do not test UFO for the above reason, and\ndo not test UDP tunnel offload.\r\n\r\nGSO packet are almost always CHECKSUM_PARTIAL. USO packets may be\nCHECKSUM_NONE since commit 10154dbded6d6 (\u0026quot;udp: Allow GSO transmit\nfrom devices with no checksum offload\u0026quot;), but then still these fields\nare initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no\nneed to test for ip_summed == CHECKSUM_PARTIAL first.\r\n\r\nThis revises an existing fix mentioned in the Fixes tag, which broke\nsmall packets with GSO offload, as detected by kselftests.(CVE-2024-43897)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-43898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix null pointer deref in dcn20_resource.c\r\n\r\nFixes a hang thats triggered when MPV is run on a DCN401 dGPU:\r\n\r\nmpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all\r\n\r\nand then enabling fullscreen playback (double click on the video)\r\n\r\nThe following calltrace will be seen:\r\n\r\n[  181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[  181.843997] #PF: supervisor instruction fetch in kernel mode\n[  181.844003] #PF: error_code(0x0010) - not-present page\n[  181.844009] PGD 0 P4D 0\n[  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI\n[  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu\n[  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018\n[  181.844044] RIP: 0010:0x0\n[  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246\n[  181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004\n[  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400\n[  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c\n[  181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8\n[  181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005\n[  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000\n[  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0\n[  181.844141] Call Trace:\n[  181.844146]  \u0026lt;TASK\u0026gt;\n[  181.844153]  ? show_regs+0x6d/0x80\n[  181.844167]  ? __die+0x24/0x80\n[  181.844179]  ? page_fault_oops+0x99/0x1b0\n[  181.844192]  ? do_user_addr_fault+0x31d/0x6b0\n[  181.844204]  ? exc_page_fault+0x83/0x1b0\n[  181.844216]  ? asm_exc_page_fault+0x27/0x30\n[  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]\n[  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]\n[  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]\n[  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]\n[  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu]\n[  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]\n[  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]\n[  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu](CVE-2024-43899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checker before passing variables\r\n\r\nChecks null pointer before passing variables to functions.\r\n\r\nThis fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix the null pointer dereference for vega10_hwmgr\r\n\r\nCheck return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/admgpu: fix dereferencing null pointer context\r\n\r\nWhen user space sets an invalid ta type, the pointer context will be empty.\nSo it need to check the pointer context before using it(CVE-2024-43906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules\r\n\r\nCheck the pointer value to fix potential null pointer\ndereference(CVE-2024-43907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the null pointer dereference to ras_manager\r\n\r\nCheck ras_manager before using it(CVE-2024-43908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu/pm: Fix the null pointer dereference for smu7\r\n\r\noptimize the code to avoid pass a null pointer (hwmgr-\u0026gt;backend)\nto function smu7_update_edc_leakage_table.(CVE-2024-43909)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: nl80211: disallow setting special AP channel widths\r\n\r\nSetting the AP channel width is meant for use with the normal\n20/40/... MHz channel width progression, and switching around\nin S1G or narrow channels isn\u0026apos;t supported. Disallow that.(CVE-2024-43912)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme: apple: fix device reference counting\r\n\r\nDrivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.\nSplit the allocation side out to make the error handling boundary easier\nto navigate. The apple driver had been doing this wrong, leaking the\ncontroller device memory on a tagset failure.(CVE-2024-43913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: avoid BUG_ON() while continue reshape after reassembling\r\n\r\nCurrently, mdadm support --revert-reshape to abort the reshape while\nreassembling, as the test 07revert-grow. However, following BUG_ON()\ncan be triggerred by the test:\r\n\r\nkernel BUG at drivers/md/raid5.c:6278!\ninvalid opcode: 0000 [#1] PREEMPT SMP PTI\nirq event stamp: 158985\nCPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94\nRIP: 0010:reshape_request+0x3f1/0xe60\nCall Trace:\n \u0026lt;TASK\u0026gt;\n raid5_sync_request+0x43d/0x550\n md_do_sync+0xb7a/0x2110\n md_thread+0x294/0x2b0\n kthread+0x147/0x1c0\n ret_from_fork+0x59/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nRoot cause is that --revert-reshape update the raid_disks from 5 to 4,\nwhile reshape position is still set, and after reassembling the array,\nreshape position will be read from super block, then during reshape the\nchecking of \u0026apos;writepos\u0026apos; that is caculated by old reshape position will\nfail.\r\n\r\nFix this panic the easy way first, by converting the BUG_ON() to\nWARN_ON(), and stop the reshape if checkings fail.\r\n\r\nNoted that mdadm must fix --revert-shape as well, and probably md/raid\nshould enhance metadata validation as well, however this means\nreassemble will fail and there must be user tools to fix the wrong\nmetadata.(CVE-2024-43914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mcast: wait for previous gc cycles when removing port\r\n\r\nsyzbot hit a use-after-free[1] which is caused because the bridge doesn\u0026apos;t\nmake sure that all previous garbage has been collected when removing a\nport. What happens is:\n      CPU 1                   CPU 2\n start gc cycle           remove port\n                         acquire gc lock first\n wait for lock\n                         call br_multicasg_gc() directly\n acquire lock now but    free port\n the port can be freed\n while grp timers still\n running\r\n\r\nMake sure all previous gc cycles have finished by using flush_work before\nfreeing the port.\r\n\r\n[1]\n  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699\r\n\r\n  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   __dump_stack lib/dump_stack.c:88 [inline]\n   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n   print_address_description mm/kasan/report.c:377 [inline]\n   print_report+0xc3/0x620 mm/kasan/report.c:488\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792\n   expire_timers kernel/time/timer.c:1843 [inline]\n   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417\n   __run_timer_base kernel/time/timer.c:2428 [inline]\n   __run_timer_base kernel/time/timer.c:2421 [inline]\n   run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsctp: Fix null-ptr-deref in reuseport_add_sock().\r\n\r\nsyzbot reported a null-ptr-deref while accessing sk2-\u0026gt;sk_reuseport_cb in\nreuseport_add_sock(). [0]\r\n\r\nThe repro first creates a listener with SO_REUSEPORT.  Then, it creates\nanother listener on the same port and concurrently closes the first\nlistener.\r\n\r\nThe second listen() calls reuseport_add_sock() with the first listener as\nsk2, where sk2-\u0026gt;sk_reuseport_cb is not expected to be cleared concurrently,\nbut the close() does clear it by reuseport_detach_sock().\r\n\r\nThe problem is SCTP does not properly synchronise reuseport_alloc(),\nreuseport_add_sock(), and reuseport_detach_sock().\r\n\r\nThe caller of reuseport_alloc() and reuseport_{add,detach}_sock() must\nprovide synchronisation for sockets that are classified into the same\nreuseport group.\r\n\r\nOtherwise, such sockets form multiple identical reuseport groups, and\nall groups except one would be silently dead.\r\n\r\n  1. Two sockets call listen() concurrently\n  2. No socket in the same group found in sctp_ep_hashtable[]\n  3. Two sockets call reuseport_alloc() and form two reuseport groups\n  4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives\n      incoming packets\r\n\r\nAlso, the reported null-ptr-deref could occur.\r\n\r\nTCP/UDP guarantees that would not happen by holding the hash bucket lock.\r\n\r\nLet\u0026apos;s apply the locking strategy to __sctp_hash_endpoint() and\n__sctp_unhash_endpoint().\r\n\r\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024\nRIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350\nCode: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14\nRSP: 0018:ffffc9000b947c98 EFLAGS: 00010202\nRAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012\nRBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385\nR10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0\nR13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __sctp_hash_endpoint net/sctp/input.c:762 [inline]\n sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790\n sctp_listen_start net/sctp/socket.c:8570 [inline]\n sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625\n __sys_listen_socket net/socket.c:1883 [inline]\n __sys_listen+0x1b7/0x230 net/socket.c:1894\n __do_sys_listen net/socket.c:1902 [inline]\n __se_sys_listen net/socket.c:1900 [inline]\n __x64_sys_listen+0x5a/0x70 net/socket.c:1900\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f24e46039b9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032\nRAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9\nRDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004\nRBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0\nR10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c\nR13:\n---truncated---(CVE-2024-44935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC\r\n\r\nsyzbot reports a f2fs bug as below:\r\n\r\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inline.c:258!\nCPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0\nRIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258\nCall Trace:\n f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834\n f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315\n do_writepages+0x35b/0x870 mm/page-writeback.c:2612\n __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650\n writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941\n wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117\n wb_do_writeback fs/fs-writeback.c:2264 [inline]\n wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f2/0x390 kernel/kthread.c:388\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\r\n\r\nThe root cause is: inline_data inode can be fuzzed, so that there may\nbe valid blkaddr in its direct node, once f2fs triggers background GC\nto migrate the block, it will hit f2fs_bug_on() during dirty page\nwriteback.\r\n\r\nLet\u0026apos;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,\nso that, it can forbid migrating inline_data inode\u0026apos;s data block for\nfixing.(CVE-2024-44942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkcm: Serialise kcm_sendmsg() for the same socket.\r\n\r\nsyzkaller reported UAF in kcm_release(). [0]\r\n\r\nThe scenario is\r\n\r\n  1. Thread A builds a skb with MSG_MORE and sets kcm-\u0026gt;seq_skb.\r\n\r\n  2. Thread A resumes building skb from kcm-\u0026gt;seq_skb but is blocked\n     by sk_stream_wait_memory()\r\n\r\n  3. Thread B calls sendmsg() concurrently, finishes building kcm-\u0026gt;seq_skb\n     and puts the skb to the write queue\r\n\r\n  4. Thread A faces an error and finally frees skb that is already in the\n     write queue\r\n\r\n  5. kcm_release() does double-free the skb in the write queue\r\n\r\nWhen a thread is building a MSG_MORE skb, another thread must not touch it.\r\n\r\nLet\u0026apos;s add a per-sk mutex and serialise kcm_sendmsg().\r\n\r\n[0]:\nBUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]\nBUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]\nBUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\nRead of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167\r\n\r\nCPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall trace:\n dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x178/0x518 mm/kasan/report.c:488\n kasan_report+0xd8/0x138 mm/kasan/report.c:601\n __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381\n __skb_unlink include/linux/skbuff.h:2366 [inline]\n __skb_dequeue include/linux/skbuff.h:2385 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\n __skb_queue_purge include/linux/skbuff.h:3181 [inline]\n kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\n __sock_release net/socket.c:659 [inline]\n sock_close+0xa4/0x1e8 net/socket.c:1421\n __fput+0x30c/0x738 fs/file_table.c:376\n ____fput+0x20/0x30 fs/file_table.c:404\n task_work_run+0x230/0x2e0 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x618/0x1f64 kernel/exit.c:871\n do_group_exit+0x194/0x22c kernel/exit.c:1020\n get_signal+0x1500/0x15ec kernel/signal.c:2893\n do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249\n do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148\n exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]\n exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]\n el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\r\n\r\nAllocated by task 6166:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903\n __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641\n alloc_skb include/linux/skbuff.h:1296 [inline]\n kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x220/0x2c0 net/socket.c:768\n splice_to_socket+0x7cc/0xd58 fs/splice.c:889\n do_splice_from fs/splice.c:941 [inline]\n direct_splice_actor+0xec/0x1d8 fs/splice.c:1164\n splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108\n do_splice_direct_actor \n---truncated---(CVE-2024-44946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfuse: Initialize beyond-EOF page contents before setting uptodate\r\n\r\nfuse_notify_store(), unlike fuse_do_readpage(), does not enable page\nzeroing (because it can be used to change partial page contents).\r\n\r\nSo fuse_notify_store() must be more careful to fully initialize page\ncontents (including parts of the page that are beyond end-of-file)\nbefore marking the page uptodate.\r\n\r\nThe current code can leave beyond-EOF page contents uninitialized, which\nmakes these uninitialized page contents visible to userspace via mmap().\r\n\r\nThis is an information leak, but only affects systems which do not\nenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the\ncorresponding kernel command line parameter).(CVE-2024-44947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Forward soft recovery errors to userspace\r\n\r\nAs we discussed before[1], soft recovery should be\nforwarded to userspace, or we can get into a really\nbad state where apps will keep submitting hanging\ncommand buffers cascading us to a hard reset.\r\n\r\n1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/\n(cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)(CVE-2024-44961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinfmt_flat: Fix corruption when not offsetting data start\r\n\r\nCommit 04d82a6d0881 (\u0026quot;binfmt_flat: allow not offsetting data start\u0026quot;)\nintroduced a RISC-V specific variant of the FLAT format which does\nnot allocate any space for the (obsolete) array of shared library\npointers. However, it did not disable the code which initializes the\narray, resulting in the corruption of sizeof(long) bytes before the DATA\nsegment, generally the end of the TEXT segment.\r\n\r\nIntroduce MAX_SHARED_LIBS_UPDATE which depends on the state of\nCONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of\nthe shared library pointer region so that it will only be initialized\nif space is reserved for it.(CVE-2024-44966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()\r\n\r\nbcm_sf2_mdio_register() calls of_phy_find_device() and then\nphy_device_remove() in a loop to remove existing PHY devices.\nof_phy_find_device() eventually calls bus_find_device(), which calls\nget_device() on the returned struct device * to increment the refcount.\nThe current implementation does not decrement the refcount, which causes\nmemory leak.\r\n\r\nThis commit adds the missing phy_device_free() call to decrement the\nrefcount via put_device() to balance the refcount.(CVE-2024-44971)",
  "id": "OESA-2024-2124",
  "modified": "2026-08-06T11:07:36Z",
  "published": "2024-09-14T11:07:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2124"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40959"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40976"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41037"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41071"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42139"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42235"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42238"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42240"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42250"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42253"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42258"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42272"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42276"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42277"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42279"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42291"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42294"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42298"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42307"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42314"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42315"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42316"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42317"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43825"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43826"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43832"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43837"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43842"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43845"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43847"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43851"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43856"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43891"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43897"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43907"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43909"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43912"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43914"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44971"
    }
  ],
  "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-36934",
    "CVE-2024-37078",
    "CVE-2024-40959",
    "CVE-2024-40976",
    "CVE-2024-40978",
    "CVE-2024-41012",
    "CVE-2024-41016",
    "CVE-2024-41037",
    "CVE-2024-41052",
    "CVE-2024-41071",
    "CVE-2024-41082",
    "CVE-2024-41098",
    "CVE-2024-42139",
    "CVE-2024-42152",
    "CVE-2024-42153",
    "CVE-2024-42234",
    "CVE-2024-42235",
    "CVE-2024-42237",
    "CVE-2024-42238",
    "CVE-2024-42239",
    "CVE-2024-42240",
    "CVE-2024-42241",
    "CVE-2024-42243",
    "CVE-2024-42248",
    "CVE-2024-42250",
    "CVE-2024-42253",
    "CVE-2024-42258",
    "CVE-2024-42259",
    "CVE-2024-42271",
    "CVE-2024-42272",
    "CVE-2024-42276",
    "CVE-2024-42277",
    "CVE-2024-42279",
    "CVE-2024-42291",
    "CVE-2024-42294",
    "CVE-2024-42296",
    "CVE-2024-42298",
    "CVE-2024-42303",
    "CVE-2024-42307",
    "CVE-2024-42314",
    "CVE-2024-42315",
    "CVE-2024-42316",
    "CVE-2024-42317",
    "CVE-2024-42320",
    "CVE-2024-42321",
    "CVE-2024-43817",
    "CVE-2024-43818",
    "CVE-2024-43821",
    "CVE-2024-43825",
    "CVE-2024-43826",
    "CVE-2024-43829",
    "CVE-2024-43832",
    "CVE-2024-43833",
    "CVE-2024-43837",
    "CVE-2024-43841",
    "CVE-2024-43842",
    "CVE-2024-43845",
    "CVE-2024-43846",
    "CVE-2024-43847",
    "CVE-2024-43849",
    "CVE-2024-43850",
    "CVE-2024-43851",
    "CVE-2024-43855",
    "CVE-2024-43856",
    "CVE-2024-43859",
    "CVE-2024-43883",
    "CVE-2024-43884",
    "CVE-2024-43889",
    "CVE-2024-43890",
    "CVE-2024-43891",
    "CVE-2024-43895",
    "CVE-2024-43897",
    "CVE-2024-43898",
    "CVE-2024-43899",
    "CVE-2024-43900",
    "CVE-2024-43902",
    "CVE-2024-43905",
    "CVE-2024-43906",
    "CVE-2024-43907",
    "CVE-2024-43908",
    "CVE-2024-43909",
    "CVE-2024-43912",
    "CVE-2024-43913",
    "CVE-2024-43914",
    "CVE-2024-44934",
    "CVE-2024-44935",
    "CVE-2024-44940",
    "CVE-2024-44942",
    "CVE-2024-44946",
    "CVE-2024-44947",
    "CVE-2024-44961",
    "CVE-2024-44966",
    "CVE-2024-44971"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-230.0.0.129.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-230.0.0.129.oe2203sp4"
            }
          ],
          "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\nclk: sunxi-ng: Unregister clocks/resets when unbinding\r\n\r\nCurrently, unbinding a CCU driver unmaps the device\u0026apos;s MMIO region, while\nleaving its clocks/resets and their providers registered. This can cause\na page fault later when some clock operation tries to perform MMIO. Fix\nthis by separating the CCU initialization from the memory allocation,\nand then using a devres callback to unregister the clocks and resets.\r\n\r\nThis also fixes a memory leak of the `struct ccu_reset`, and uses the\ncorrect owner (the specific platform driver) for the clocks and resets.\r\n\r\nEarly OF clock providers are never unregistered, and limited error\nhandling is possible, so they are mostly unchanged. The error reporting\nis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mvpp2: clear BM pool before initialization\r\n\r\nRegister value persist after booting the kernel using\nkexec which results in kernel panic. Thus clear the\nBM pool registers before initialisation to fix the issue.(CVE-2024-35837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrop_monitor: replace spin_lock by raw_spin_lock\r\n\r\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026amp;data-\u0026gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last  enabled at (139908): [\u0026lt;ffffffffb1df2b33\u0026gt;] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u0026lt;ffffffffb19bd03d\u0026gt;] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last  enabled at (139892): [\u0026lt;ffffffffb07a1083\u0026gt;] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u0026lt;ffffffffb0909b33\u0026gt;] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u0026lt;ffffffffb1de786b\u0026gt;] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\r\n\r\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\r\n\r\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.(CVE-2024-40980)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: don\u0026apos;t walk off the end of ealist\r\n\r\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix null pointer dereference on error\r\n\r\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\r\n\r\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\r\n\r\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nDo not access ata_port struct members unconditionally.(CVE-2024-41098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip finding free audio for unknown engine_id\r\n\r\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\r\n\r\n[HOW]\nSkip and return NULL.\r\n\r\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkobject_uevent: Fix OOB access within zap_modalias_env()\r\n\r\nzap_modalias_env() wrongly calculates size of memory block to move, so\nwill cause OOB memory access issue if variable MODALIAS is not the last\none within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 \u2502\n                                 \u25bc\n                              ......\nsetup tc                         \u2502\n    \u2502                            \u25bc\n    \u25bc                      DOWN: napi_disable()\nnapi_disable()(skip)             \u2502\n    \u2502                            \u2502\n    \u25bc                            \u25bc\n  ......                      ......\n    \u2502                            \u2502\n    \u25bc                            \u2502\nnapi_enable()                    \u2502\n                                 \u25bc\n                           UINIT: netif_napi_del()\n                                 \u2502\n                                 \u25bc\n                              ......\n                                 \u2502\n                                 \u25bc\n                           INIT: netif_napi_add()\n                                 \u2502\n                                 \u25bc\n                              ......                 global reset start\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                           UP: napi_enable()(skip)    ......\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                              ......                 napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n    PA                              PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg-\u0026gt;nlink = 0\n      iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea-\u0026gt;i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n        PA                PB                        PC\n                echo 2 \u0026gt; /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa-\u0026gt;i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib-\u0026gt;nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n      ubifs_iget(ixa-\u0026gt;i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib-\u0026gt;nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          \u2193             ubifs_jnl_write_inode\n     ABBA deadlock \u2190-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? __warn.cold+0x8e/0xea\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? report_bug+0xff/0x140\n   ? handle_bug+0x3b/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   generic_shutdown_super+0x70/0x160\n   kill_anon_super+0x11/0x40\n   btrfs_kill_super+0x11/0x20 [btrfs]\n   deactivate_locked_super+0x2e/0xa0\n   cleanup_mnt+0xb5/0x150\n   task_work_run+0x57/0x80\n   syscall_exit_to_user_mode+0x121/0x130\n   do_syscall_64+0xab/0x1a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f916847a887\n  ---[ end trace 0000000000000000 ]---\n  BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n   link from disk.  This assigns the corrupted value\n   3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n   this corrupted value to the length variable, which being a\n   signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n   the copied bytes is less than length, which being negative means\n   the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n   the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n   some extra mdelay() calls. See the commit message for a description\n   of the race scenario.\n   On older kernels (before 6.5), I think the same bug can even\n   theoretically lead to accessing transhuge page contents as a page table\n   if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n   detecting PMDs that don\u0026apos;t point to page tables.\n   On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n   wide race to hit this.\n   I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n   VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n   to yank page tables out from under us (though I haven\u0026apos;t tested that),\n   so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n  mfill_atomic                other thread\n  ============                ============\n                              \u0026lt;zap PMD\u0026gt;\n  pmdp_get_lockless() [reads none pmd]\n  \u0026lt;bail if trans_huge\u0026gt;\n  \u0026lt;if none:\u0026gt;\n                              \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n    __pte_alloc [no-op]\n                              \u0026lt;zap PMD\u0026gt;\n  \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n  BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)",
  "id": "OESA-2024-2182",
  "modified": "2026-08-06T11:07:39Z",
  "published": "2024-09-27T11:07:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2182"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47205"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35837"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42292"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46714"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46751"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46752"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46787"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47205",
    "CVE-2022-48828",
    "CVE-2024-35837",
    "CVE-2024-39501",
    "CVE-2024-40978",
    "CVE-2024-40980",
    "CVE-2024-41017",
    "CVE-2024-41098",
    "CVE-2024-42104",
    "CVE-2024-42119",
    "CVE-2024-42292",
    "CVE-2024-43846",
    "CVE-2024-43863",
    "CVE-2024-44939",
    "CVE-2024-44965",
    "CVE-2024-44995",
    "CVE-2024-44999",
    "CVE-2024-45003",
    "CVE-2024-45025",
    "CVE-2024-45028",
    "CVE-2024-46714",
    "CVE-2024-46723",
    "CVE-2024-46731",
    "CVE-2024-46733",
    "CVE-2024-46742",
    "CVE-2024-46744",
    "CVE-2024-46745",
    "CVE-2024-46747",
    "CVE-2024-46751",
    "CVE-2024-46752",
    "CVE-2024-46787",
    "CVE-2024-46800"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-230.0.0.132.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-230.0.0.132.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-230.0.0.132.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-230.0.0.132.oe2203sp3"
            }
          ],
          "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\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: tproxy: bail out if IP has been disabled on the device\r\n\r\nsyzbot reports:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n[..]\nRIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62\nCall Trace:\n nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]\n nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168\r\n\r\n__in_dev_get_rcu() can return NULL, so check for this.(CVE-2024-36270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: llcp: fix nfc_llcp_setsockopt() unsafe copies\r\n\r\nsyzbot reported unsafe calls to copy_from_sockptr() [1]\r\n\r\nUse copy_safe_from_sockptr() instead.\r\n\r\n[1]\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\nRead of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078\r\n\r\nCPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\n  do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfd/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7f7fac07fd89\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89\nRDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: don\u0026apos;t walk off the end of ealist\r\n\r\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix null pointer dereference on error\r\n\r\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\r\n\r\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\r\n\r\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nDo not access ata_port struct members unconditionally.(CVE-2024-41098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip finding free audio for unknown engine_id\r\n\r\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\r\n\r\n[HOW]\nSkip and return NULL.\r\n\r\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkobject_uevent: Fix OOB access within zap_modalias_env()\r\n\r\nzap_modalias_env() wrongly calculates size of memory block to move, so\nwill cause OOB memory access issue if variable MODALIAS is not the last\none within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 \u2502\n                                 \u25bc\n                              ......\nsetup tc                         \u2502\n    \u2502                            \u25bc\n    \u25bc                      DOWN: napi_disable()\nnapi_disable()(skip)             \u2502\n    \u2502                            \u2502\n    \u25bc                            \u25bc\n  ......                      ......\n    \u2502                            \u2502\n    \u25bc                            \u2502\nnapi_enable()                    \u2502\n                                 \u25bc\n                           UINIT: netif_napi_del()\n                                 \u2502\n                                 \u25bc\n                              ......\n                                 \u2502\n                                 \u25bc\n                           INIT: netif_napi_add()\n                                 \u2502\n                                 \u25bc\n                              ......                 global reset start\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                           UP: napi_enable()(skip)    ......\n                                 \u2502                      \u2502\n                                 \u25bc                      \u25bc\n                              ......                 napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n    PA                              PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg-\u0026gt;nlink = 0\n      iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea-\u0026gt;i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n        PA                PB                        PC\n                echo 2 \u0026gt; /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa-\u0026gt;i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib-\u0026gt;nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n      ubifs_iget(ixa-\u0026gt;i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib-\u0026gt;nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          \u2193             ubifs_jnl_write_inode\n     ABBA deadlock \u2190-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? __warn.cold+0x8e/0xea\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? report_bug+0xff/0x140\n   ? handle_bug+0x3b/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   generic_shutdown_super+0x70/0x160\n   kill_anon_super+0x11/0x40\n   btrfs_kill_super+0x11/0x20 [btrfs]\n   deactivate_locked_super+0x2e/0xa0\n   cleanup_mnt+0xb5/0x150\n   task_work_run+0x57/0x80\n   syscall_exit_to_user_mode+0x121/0x130\n   do_syscall_64+0xab/0x1a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f916847a887\n  ---[ end trace 0000000000000000 ]---\n  BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n   link from disk.  This assigns the corrupted value\n   3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n   this corrupted value to the length variable, which being a\n   signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n   the copied bytes is less than length, which being negative means\n   the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n   the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n   some extra mdelay() calls. See the commit message for a description\n   of the race scenario.\n   On older kernels (before 6.5), I think the same bug can even\n   theoretically lead to accessing transhuge page contents as a page table\n   if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n   detecting PMDs that don\u0026apos;t point to page tables.\n   On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n   wide race to hit this.\n   I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n   VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n   to yank page tables out from under us (though I haven\u0026apos;t tested that),\n   so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n  mfill_atomic                other thread\n  ============                ============\n                              \u0026lt;zap PMD\u0026gt;\n  pmdp_get_lockless() [reads none pmd]\n  \u0026lt;bail if trans_huge\u0026gt;\n  \u0026lt;if none:\u0026gt;\n                              \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n    __pte_alloc [no-op]\n                              \u0026lt;zap PMD\u0026gt;\n  \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n  BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)",
  "id": "OESA-2024-2183",
  "modified": "2026-08-06T11:07:39Z",
  "published": "2024-09-27T11:07:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36270"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42292"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46714"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46751"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46752"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46787"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48828",
    "CVE-2023-52691",
    "CVE-2024-36270",
    "CVE-2024-36915",
    "CVE-2024-39501",
    "CVE-2024-40978",
    "CVE-2024-41017",
    "CVE-2024-41098",
    "CVE-2024-42104",
    "CVE-2024-42119",
    "CVE-2024-42292",
    "CVE-2024-43846",
    "CVE-2024-43863",
    "CVE-2024-44939",
    "CVE-2024-44965",
    "CVE-2024-44995",
    "CVE-2024-44999",
    "CVE-2024-45003",
    "CVE-2024-45025",
    "CVE-2024-45028",
    "CVE-2024-46714",
    "CVE-2024-46723",
    "CVE-2024-46731",
    "CVE-2024-46733",
    "CVE-2024-46742",
    "CVE-2024-46744",
    "CVE-2024-46745",
    "CVE-2024-46747",
    "CVE-2024-46751",
    "CVE-2024-46752",
    "CVE-2024-46787",
    "CVE-2024-46800"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.96.0.177.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.96.0.177.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\nALSA: usb-audio: Stop parsing channels bits when all channels are found.\r\n\r\nIf a usb audio device sets more bits than the amount of channels\nit could write outside of the map array.(CVE-2024-27436)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\r\n\r\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC.  There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect.  For a DWC3 based implementation, the callstack looks\nlike the following:\r\n\r\n    DWC3 Gadget                               FFS Application\ndwc3_gadget_soft_disconnect()              ...\n  --\u0026gt; dwc3_stop_active_transfers()\n    --\u0026gt; dwc3_gadget_giveback(-ESHUTDOWN)\n      --\u0026gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()\n        --\u0026gt; usb_ep_free_request()            --\u0026gt; usb_ep_dequeue()\r\n\r\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data-\u0026gt;req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call.  This can\nlead to accessing a stale/hanging pointer.\r\n\r\ncommit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status consistently\u0026quot;)\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can\u0026apos;t be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver\u0026apos;s completion handler in the same context.  Hence, leading\ninto a deadlock.\r\n\r\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data-\u0026gt;req\nto NULL after freeing it within the ffs-\u0026gt;eps_lock.  This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\r\n\r\nThis fix depends on\n  commit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status\n  consistently\u0026quot;)(CVE-2024-36894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bfa: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul instead\nof memdup_user.(CVE-2024-38560)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nenic: Validate length of nl attributes in enic_set_vf_port\r\n\r\nenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE\nis of length PORT_PROFILE_MAX and that the nl attributes\nIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.\nThese attributes are validated (in the function do_setlink in rtnetlink.c)\nusing the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE\nas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and\nIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation\nusing the policy is for the max size of the attributes and not on exact\nsize so the length of these attributes might be less than the sizes that\nenic_set_vf_port expects. This might cause an out of bands\nread access in the memcpys of the data of these\nattributes in enic_set_vf_port.(CVE-2024-38659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbcache: fix variable length array abuse in btree_iter\r\n\r\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\r\n\r\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\r\n\r\nIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\r\n\r\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\r\n\r\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\r\n\r\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Ensure index calculation will not overflow\r\n\r\n[WHY \u0026amp; HOW]\nMake sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will\nnever overflow and exceess array size.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -\u0026gt; addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix negative array index read\r\n\r\nAvoid using the negative values\nfor clk_idex as an index into an array pptable-\u0026gt;DpmDescriptor.\r\n\r\nV2: fix clk_index return check (Tim Huang)(CVE-2024-46821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)",
  "id": "OESA-2024-2218",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2218"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27436"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38560"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46857"
    }
  ],
  "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-27436",
    "CVE-2024-36894",
    "CVE-2024-38560",
    "CVE-2024-38659",
    "CVE-2024-39482",
    "CVE-2024-39501",
    "CVE-2024-40978",
    "CVE-2024-41030",
    "CVE-2024-41095",
    "CVE-2024-43846",
    "CVE-2024-43863",
    "CVE-2024-43900",
    "CVE-2024-44939",
    "CVE-2024-44954",
    "CVE-2024-44958",
    "CVE-2024-44982",
    "CVE-2024-45008",
    "CVE-2024-45016",
    "CVE-2024-45025",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46679",
    "CVE-2024-46681",
    "CVE-2024-46695",
    "CVE-2024-46707",
    "CVE-2024-46721",
    "CVE-2024-46725",
    "CVE-2024-46726",
    "CVE-2024-46732",
    "CVE-2024-46737",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46742",
    "CVE-2024-46743",
    "CVE-2024-46750",
    "CVE-2024-46753",
    "CVE-2024-46755",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46759",
    "CVE-2024-46761",
    "CVE-2024-46771",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781",
    "CVE-2024-46791",
    "CVE-2024-46798",
    "CVE-2024-46800",
    "CVE-2024-46804",
    "CVE-2024-46814",
    "CVE-2024-46816",
    "CVE-2024-46818",
    "CVE-2024-46821",
    "CVE-2024-46829",
    "CVE-2024-46841",
    "CVE-2024-46844",
    "CVE-2024-46849",
    "CVE-2024-46857"
  ]
}