Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-41008 (GCVE-0-2024-41008)
Vulnerability from cvelistv5 – Published: 2024-07-16 08:03 – Updated: 2026-08-05 11:34{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T04:39:56.069Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-41008",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T17:00:49.381223Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T17:34:18.174Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b8f67b9ddf4f8fe6dd536590712b5912ad78f99c",
"status": "affected",
"version": "d38ceaf99ed015f2a0b9af3499791bd3a3daae21",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.2"
},
{
"lessThan": "4.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: change vm-\u003etask_info handling\n\nThis patch changes the handling and lifecycle of vm-\u003etask_info object.\nThe major changes are:\n- vm-\u003etask_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\n\nThis patch also does logistical changes required for existing usage\nof vm-\u003etask_info.\n\nV2: Do not block all the prints when task_info not found (Felix)\n\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\n\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerability is reached through DRM ioctls on the amdgpu device node (/dev/dri/renderD128 or card0), specifically DRM_IOCTL_AMDGPU_CS job submission followed by fd close. No network or adjacent-network exposure exists.\nAC:L - The attacker controls both sides of the lifetime race: it submits a job that deterministically hangs the ring, closes the fd (which does not wait for in-flight hung jobs), and the ~10-second scheduler timeout gives a large, attacker-scheduled window to groom the freed amdgpu_fpriv slab before the coredump path dereferences the stale vm pointer.\nPR:L - An unprivileged local user with render-node access can do this \u2014 on desktop distros logind grants uaccess ACLs on /dev/dri/renderD*, and Android/ChromeOS app sandboxes and GPU-enabled containers likewise expose it. No capability check exists on the amdgpu CS ioctl path.\nUI:N - The attacking process performs every step itself \u2014 job submission, fd close, and heap grooming \u2014 with no action required from any other user.\nS:U - The stale-pointer read and its consequences stay within the kernel\u0027s own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The use-after-free reads a freed kernel heap object and emits its contents into the devcoredump blob and kernel log, and the unterminated %s print can read past the field, disclosing arbitrary reallocated kernel heap data that the attacker can groom.\nI:H - Use-after-free of a slab object whose contents an attacker can control by reallocation constitutes memory corruption exploitable beyond a simple read; the unsynchronized task_info lifetime is a general object-lifetime confusion, so integrity impact is scored High per UAF guidance.\nA:H - Dereferencing the dangling vm pointer during GPU reset can oops or panic the kernel if the slab page has been returned to the page allocator, and it occurs in the non-recoverable GPU recovery path, which the attacker can trigger repeatedly."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:34:34.592Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"title": "drm/amdgpu: change vm-\u003etask_info handling",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-41008",
"datePublished": "2024-07-16T08:03:47.091Z",
"dateReserved": "2024-07-12T12:17:45.610Z",
"dateUpdated": "2026-08-05T11:34:34.592Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-41008",
"date": "2026-10-05",
"epss": "0.00189",
"percentile": "0.07708"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b8f67b9ddf4f8fe6dd536590712b5912ad78f99c",
"status": "affected",
"version": "d38ceaf99ed015f2a0b9af3499791bd3a3daae21",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.2"
},
{
"lessThan": "4.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E6BD4683-0AAB-43D1-B079-A0C20DE05CF6",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: change vm-\u003etask_info handling\n\nThis patch changes the handling and lifecycle of vm-\u003etask_info object.\nThe major changes are:\n- vm-\u003etask_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\n\nThis patch also does logistical changes required for existing usage\nof vm-\u003etask_info.\n\nV2: Do not block all the prints when task_info not found (Felix)\n\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\n\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: cambiar el manejo de vm-\u0026gt;task_info Este parche cambia el manejo y el ciclo de vida del objeto vm-\u0026gt;task_info. Los cambios principales son: - vm-\u0026gt;task_info ahora es un ptr asignado din\u00e1micamente y su uso se cuenta por referencia. - presentamos dos nuevas funciones auxiliares para la gesti\u00f3n del ciclo de vida de task_info - amdgpu_vm_get_task_info: la referencia cuenta task_info antes de devolver esta informaci\u00f3n - amdgpu_vm_put_task_info: la referencia cuenta atr\u00e1s task_info - la \u00faltima entrada en task_info() libera task_info de la m\u00e1quina virtual. Este parche tambi\u00e9n realiza cambios log\u00edsticos necesarios para el uso existente de vm-\u0026gt;task_info. V2: No bloquear todas las impresiones cuando no se encuentra task_info (Felix) V3: Se corrigieron los comentarios de revisi\u00f3n de Felix - Se corrigi\u00f3 la sangr\u00eda incorrecta - No hay mensaje de depuraci\u00f3n para -ENOMEM - Agregar verificaci\u00f3n NULL para task_info - No se duplican los mensajes de depuraci\u00f3n (ti vs no ti) - Obtenga la primera referencia de task_info en vm_init(), col\u00f3quela \u00faltima en vm_fini() V4: Se corrigieron los comentarios de revisi\u00f3n de Felix - se corrigi\u00f3 el incremento de doble referencia en create_task_info - se cambi\u00f3 amdgpu_vm_get_task_info_pasid - cambios adicionales en amdgpu_gem.c durante la portabilidad"
}
],
"id": "CVE-2024-41008",
"lastModified": "2026-08-04T11:19:15.360",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-41008",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T17:00:49.381223Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-16T08:15:02.240",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-08-04T22:44:12+00:00",
"cve": "CVE-2024-41008",
"id": "CVE-2024-41008",
"initial_release_date": "2024-07-16T00:00:00+00:00",
"product_status:fixed": "709",
"product_status:known_affected": "50",
"product_status:known_not_affected": "22",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: drm/amdgpu: change vm-\u0026gt;task_info handling",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-41008.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T04:39:56.069Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-41008",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T17:00:49.381223Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T12:42:21.879Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b8f67b9ddf4f8fe6dd536590712b5912ad78f99c",
"status": "affected",
"version": "d38ceaf99ed015f2a0b9af3499791bd3a3daae21",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.2"
},
{
"lessThan": "4.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: change vm-\u003etask_info handling\n\nThis patch changes the handling and lifecycle of vm-\u003etask_info object.\nThe major changes are:\n- vm-\u003etask_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\n\nThis patch also does logistical changes required for existing usage\nof vm-\u003etask_info.\n\nV2: Do not block all the prints when task_info not found (Felix)\n\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\n\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting"
}
],
"providerMetadata": {
"dateUpdated": "2025-09-16T08:02:39.206Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"title": "drm/amdgpu: change vm-\u003etask_info handling",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-41008",
"datePublished": "2024-07-16T08:03:47.091Z",
"dateReserved": "2024-07-12T12:17:45.610Z",
"dateUpdated": "2025-09-16T08:02:39.206Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
EUVD-2026-345902
European Vulnerability Database identifier assigned by ENISA{
"assigner": "ENISA",
"date_reserved": "2026-10-02T08:05:48.092697+00:00",
"id": "EUVD-2026-345902"
}
FKIE_CVE-2024-41008
Vulnerability from fkie_nvd - Published: 2024-07-16 08:15 - Updated: 2026-08-04 11:195.5 (Medium) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b8f67b9ddf4f8fe6dd536590712b5912ad78f99c",
"status": "affected",
"version": "d38ceaf99ed015f2a0b9af3499791bd3a3daae21",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_job.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h",
"drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c",
"drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c",
"drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c",
"drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.2"
},
{
"lessThan": "4.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E6BD4683-0AAB-43D1-B079-A0C20DE05CF6",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: change vm-\u003etask_info handling\n\nThis patch changes the handling and lifecycle of vm-\u003etask_info object.\nThe major changes are:\n- vm-\u003etask_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\n\nThis patch also does logistical changes required for existing usage\nof vm-\u003etask_info.\n\nV2: Do not block all the prints when task_info not found (Felix)\n\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\n\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: cambiar el manejo de vm-\u0026gt;task_info Este parche cambia el manejo y el ciclo de vida del objeto vm-\u0026gt;task_info. Los cambios principales son: - vm-\u0026gt;task_info ahora es un ptr asignado din\u00e1micamente y su uso se cuenta por referencia. - presentamos dos nuevas funciones auxiliares para la gesti\u00f3n del ciclo de vida de task_info - amdgpu_vm_get_task_info: la referencia cuenta task_info antes de devolver esta informaci\u00f3n - amdgpu_vm_put_task_info: la referencia cuenta atr\u00e1s task_info - la \u00faltima entrada en task_info() libera task_info de la m\u00e1quina virtual. Este parche tambi\u00e9n realiza cambios log\u00edsticos necesarios para el uso existente de vm-\u0026gt;task_info. V2: No bloquear todas las impresiones cuando no se encuentra task_info (Felix) V3: Se corrigieron los comentarios de revisi\u00f3n de Felix - Se corrigi\u00f3 la sangr\u00eda incorrecta - No hay mensaje de depuraci\u00f3n para -ENOMEM - Agregar verificaci\u00f3n NULL para task_info - No se duplican los mensajes de depuraci\u00f3n (ti vs no ti) - Obtenga la primera referencia de task_info en vm_init(), col\u00f3quela \u00faltima en vm_fini() V4: Se corrigieron los comentarios de revisi\u00f3n de Felix - se corrigi\u00f3 el incremento de doble referencia en create_task_info - se cambi\u00f3 amdgpu_vm_get_task_info_pasid - cambios adicionales en amdgpu_gem.c durante la portabilidad"
}
],
"id": "CVE-2024-41008",
"lastModified": "2026-08-04T11:19:15.360",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-41008",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T17:00:49.381223Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-16T08:15:02.240",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-X67R-7MR9-VWM2
Vulnerability from github – Published: 2024-07-16 09:30 – Updated: 2025-10-07 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm->task_info handling
This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage of vm->task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()
V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting
{
"affected": [],
"aliases": [
"CVE-2024-41008"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T08:15:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: change vm-\u003etask_info handling\n\nThis patch changes the handling and lifecycle of vm-\u003etask_info object.\nThe major changes are:\n- vm-\u003etask_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\n\nThis patch also does logistical changes required for existing usage\nof vm-\u003etask_info.\n\nV2: Do not block all the prints when task_info not found (Felix)\n\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\n\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting",
"id": "GHSA-x67r-7mr9-vwm2",
"modified": "2025-10-07T21:31:02Z",
"published": "2024-07-16T09:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2024-41008
Vulnerability from csaf_microsoft - Published: 2025-09-03 22:10 - Updated: 2026-09-24 02:24OESA-2024-2106 (CVE-2022-48811)
Vulnerability from osv_openeuler – Published: 2024-09-06 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface:
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32.
The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN:
Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64
If the RX FIFO depth changes after probe, be sure to resize the buffer.(CVE-2022-48871)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: sdata can be NULL during AMPDU start
ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing.
Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap:
(gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400
wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK>(CVE-2022-48875)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: let's avoid panic if extent_tree is not created
This patch avoids the below panic.
pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c process_one_work+0x24c/0x5bc worker_thread+0x3e8/0xa50 kthread+0x150/0x1b4(CVE-2022-48877)
In the Linux kernel, the following vulnerability has been resolved:
regulator: da9211: Use irq handler when ready
If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us.
If we enable the IRQ handler before its structures are ready, we crash.
This patch fixes:
[ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154(CVE-2022-48891)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
If we have one task trying to start the quota rescan worker while another one is trying to disable quotas, we can end up hitting a race that results in the quota rescan worker doing a NULL pointer dereference. The steps for this are the following:
1) Quotas are enabled;
2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan(). It calls qgroup_rescan_init() which returns 0 (success) and then joins a transaction and commits it;
3) Task B calls the quota disable ioctl and enters btrfs_quota_disable(). It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls btrfs_qgroup_wait_for_completion(), which returns immediately since the rescan worker is not yet running. Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
4) Task A queues the rescan worker, by calling btrfs_queue_work();
5) The rescan worker starts, and calls rescan_should_stop() at the start of its while loop, which results in 0 iterations of the loop, since the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by task B at step 3);
6) Task B sets fs_info->quota_root to NULL;
7) The rescan worker tries to start a transaction and uses fs_info->quota_root as the root argument for btrfs_start_transaction(). This results in a NULL pointer dereference down the call chain of btrfs_start_transaction(). The stack trace is something like the one reported in Link tag below:
general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: btrfs-qgroup-rescan btrfs_work_helper RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564 Code: 48 89 fb 48 (...) RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206 RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402 btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> Modules linked in:
So fix this by having the rescan worker function not attempt to start a transaction if it didn't do any rescan work.(CVE-2023-52896)
In the Linux kernel, the following vulnerability has been resolved:
Add exception protection processing for vd in axi_chan_handle_err function
Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases.
You can refer to the processing of axi_chan_block_xfer_complete function
The triggered kernel panic is as follows:
[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230 [ 67.848491] lr : axi_chan_handle_err+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axi_chan_handle_err+0xc4/0x230 [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590 [ 67.848569] __handle_irq_event_percpu+0x60/0x220 [ 67.848573] handle_irq_event+0x64/0x120 [ 67.848576] handle_fasteoi_irq+0xc4/0x220 [ 67.848580] __handle_domain_irq+0x80/0xe0 [ 67.848583] gic_handle_irq+0xc0/0x138 [ 67.848585] el1_irq+0xc8/0x180 [ 67.848588] arch_cpu_idle+0x14/0x2c [ 67.848591] default_idle_call+0x40/0x16c [ 67.848594] do_idle+0x1f0/0x250 [ 67.848597] cpu_startup_entry+0x2c/0x60 [ 67.848600] rest_init+0xc0/0xcc [ 67.848603] arch_call_rest_init+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid combination according to the comment above 'struct nla_policy':
" Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union "
This can trigger the warning [1] in nla_get_range_unsigned() when validation of the attribute fails. Despite being of 'NLA_U32' type, the associated 'min'/'max' fields in the policy are negative as they are aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent with the above comment and all other users of NLA_POLICY_VALIDATE_FN(). As a result, move the length validation to the validation function.
No regressions in MPLS tests:
# ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0
[1] WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118 nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 Modules linked in: CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 [...] Call Trace: <TASK> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] _syssendmsg+0x38f/0x500 net/socket.c:2482 _sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52906)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump:
BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
For full log, please look at [1].
Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory.
[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm->task_info handling
This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage of vm->task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()
V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.(CVE-2024-41016)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va->bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.(CVE-2024-41060)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: use reserved tag for reg read/write command
In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf:
- For the disable ctrl path, we will not issue connect command
- For the enable ctrl / fw activate path, since connect and reg_xx() are called serially.
So the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix scv instruction crash with kexec
kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel.
Change the kexec sequence to disable AIL after other CPUs have been brought down.
As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.(CVE-2024-42230)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.(CVE-2024-42286)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix for possible memory corruption
Init Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: handle inconsistent state in nilfs_btnode_create_block()
Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug.
It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.
So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page().(CVE-2024-42299)
In the Linux kernel, the following vulnerability has been resolved:
sysctl: always initialize i_uid/i_gid
Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them.
Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference.
Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning:
drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)
Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables.
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
[ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W
ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfxlockacquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfxmutexlock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfxnlavalidate_parse+0x10/0x10 ? pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfxnetdevupdate_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20
To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.(CVE-2024-43883)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash.
Fixed by adding error handling in the function.(CVE-2024-43884)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK>
Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.(CVE-2024-43889)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (max_elts) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map->max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
__tracing_map_insert(), it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".(CVE-2024-43890)
In the Linux kernel, the following vulnerability has been resolved:
ext4: sanity check for NULL pointer after ext4_force_shutdown
Test case: 2 threads write short inline data to a file. In ext4_page_mkwrite the resulting inline data is converted. Handling ext4_grp_locked_error with description "block bitmap and bg descriptor inconsistent: X vs Y free clusters" calls ext4_force_shutdown. The conversion clears EXT4_STATE_MAY_INLINE_DATA but fails for ext4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due to ext4_forced_shutdown. The restoration of inline data fails for the same reason not setting EXT4_STATE_MAY_INLINE_DATA. Without the flag set a regular process path in ext4_da_write_end follows trying to dereference page folio private pointer that has not been set. The fix calls early return with -EIO error shall the pointer to private be NULL.
Sample crash report:
Unable to handle kernel paging request at virtual address dfff800000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfff800000000004] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 lr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160 sp : ffff8000a1957600 x29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020 x20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020 x2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0 Call trace: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer.c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [inline] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: 97f85911 f94002da 91008356 d343fec8 (38796908) ---[ end trace 0000000000000000 ]---
Code disassembly (best guess): 0: 97f85911 bl 0xffffffffffe16444 4: f94002da ldr x26, [x22] 8: 91008356 add x22, x26, #0x20 c: d343fec8 lsr x8, x22, #3 * 10: 38796908 ldrb w8, [x8, x25] <-- trapping instruction(CVE-2024-43898)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the null pointer dereference to ras_manager
Check ras_manager before using it(CVE-2024-43908)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running
Make sure all previous gc cycles have finished by using flush_work before freeing the port.
[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix shift-out-of-bounds in dbDiscardAG
When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative.
This patch fixes the issue by exiting the loop directly when negative shift is found.(CVE-2024-44938)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)
In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
-
Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
-
Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory()
-
Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue
-
Thread A faces an error and finally frees skb that is already in the write queue
-
kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---(CVE-2024-44946)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.92.0.173.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.92.0.173.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.92.0.173.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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR: 8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 28248484 XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer\r\n\r\nDriver\u0026apos;s probe allocates memory for RX FIFO (port-\u0026gt;rx_fifo) based on\ndefault RX FIFO depth, e.g. 16. Later during serial startup the\nqcom_geni_serial_port_setup() updates the RX FIFO depth\n(port-\u0026gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.\r\n\r\nThe RX UART handle code will read \u0026quot;port-\u0026gt;rx_fifo_depth\u0026quot; number of words\ninto \u0026quot;port-\u0026gt;rx_fifo\u0026quot; buffer, thus exceeding the bounds. This can be\nobserved in certain configurations with Qualcomm Bluetooth HCI UART\ndevice and KASAN:\r\n\r\n Bluetooth: hci0: QCA Product ID :0x00000010\n Bluetooth: hci0: QCA SOC Version :0x400a0200\n Bluetooth: hci0: QCA ROM Version :0x00000200\n Bluetooth: hci0: QCA Patch Version:0x00000d2b\n Bluetooth: hci0: QCA controller version 0x02000200\n Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv\n bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2\n Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)\n Bluetooth: hci0: QCA Failed to download patch (-2)\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c\n Write of size 4 at addr ffff279347d578c0 by task swapper/0/0\r\n\r\n CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26\n Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n Call trace:\n dump_backtrace.part.0+0xe0/0xf0\n show_stack+0x18/0x40\n dump_stack_lvl+0x8c/0xb8\n print_report+0x188/0x488\n kasan_report+0xb4/0x100\n __asan_store4+0x80/0xa4\n handle_rx_uart+0xa8/0x18c\n qcom_geni_serial_handle_rx+0x84/0x9c\n qcom_geni_serial_isr+0x24c/0x760\n __handle_irq_event_percpu+0x108/0x500\n handle_irq_event+0x6c/0x110\n handle_fasteoi_irq+0x138/0x2cc\n generic_handle_domain_irq+0x48/0x64\r\n\r\nIf the RX FIFO depth changes after probe, be sure to resize the buffer.(CVE-2022-48871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: sdata can be NULL during AMPDU start\r\n\r\nieee80211_tx_ba_session_handle_start() may get NULL for sdata when a\ndeauthentication is ongoing.\r\n\r\nHere a trace triggering the race with the hostapd test\nmulti_ap_fronthaul_on_ap:\r\n\r\n(gdb) list *drv_ampdu_action+0x46\n0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).\n391 int ret = -EOPNOTSUPP;\n392\n393 might_sleep();\n394\n395 sdata = get_bss_sdata(sdata);\n396 if (!check_sdata_in_driver(sdata))\n397 return -EIO;\n398\n399 trace_drv_ampdu_action(local, sdata, params);\n400\r\n\r\nwlan0: moving STA 02:00:00:00:03:00 to state 3\nwlan0: associated\nwlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)\nwlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0\nwlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)\nwlan0: moving STA 02:00:00:00:03:00 to state 2\nwlan0: moving STA 02:00:00:00:03:00 to state 1\nwlan0: Removed STA 02:00:00:00:03:00\nwlan0: Destroyed STA 02:00:00:00:03:00\nBUG: unable to handle page fault for address: fffffffffffffb48\nPGD 11814067 P4D 11814067 PUD 11816067 PMD 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\nWorkqueue: phy3 ieee80211_ba_session_work [mac80211]\nRIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]\nCode: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 \u0026lt;8b\u0026gt; 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85\nRSP: 0018:ffffc900025ebd20 EFLAGS: 00010287\nRAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240\nRDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40\nRBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001\nR10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0\nR13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8\nFS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]\n ieee80211_ba_session_work+0xff/0x2e0 [mac80211]\n process_one_work+0x29f/0x620\n worker_thread+0x4d/0x3d0\n ? process_one_work+0x620/0x620\n kthread+0xfb/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2022-48875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: let\u0026apos;s avoid panic if extent_tree is not created\r\n\r\nThis patch avoids the below panic.\r\n\r\npc : __lookup_extent_tree+0xd8/0x760\nlr : f2fs_do_write_data_page+0x104/0x87c\nsp : ffffffc010cbb3c0\nx29: ffffffc010cbb3e0 x28: 0000000000000000\nx27: ffffff8803e7f020 x26: ffffff8803e7ed40\nx25: ffffff8803e7f020 x24: ffffffc010cbb460\nx23: ffffffc010cbb480 x22: 0000000000000000\nx21: 0000000000000000 x20: ffffffff22e90900\nx19: 0000000000000000 x18: ffffffc010c5d080\nx17: 0000000000000000 x16: 0000000000000020\nx15: ffffffdb1acdbb88 x14: ffffff888759e2b0\nx13: 0000000000000000 x12: ffffff802da49000\nx11: 000000000a001200 x10: ffffff8803e7ed40\nx9 : ffffff8023195800 x8 : ffffff802da49078\nx7 : 0000000000000001 x6 : 0000000000000000\nx5 : 0000000000000006 x4 : ffffffc010cbba28\nx3 : 0000000000000000 x2 : ffffffc010cbb480\nx1 : 0000000000000000 x0 : ffffff8803e7ed40\nCall trace:\n __lookup_extent_tree+0xd8/0x760\n f2fs_do_write_data_page+0x104/0x87c\n f2fs_write_single_data_page+0x420/0xb60\n f2fs_write_cache_pages+0x418/0xb1c\n __f2fs_write_data_pages+0x428/0x58c\n f2fs_write_data_pages+0x30/0x40\n do_writepages+0x88/0x190\n __writeback_single_inode+0x48/0x448\n writeback_sb_inodes+0x468/0x9e8\n __writeback_inodes_wb+0xb8/0x2a4\n wb_writeback+0x33c/0x740\n wb_do_writeback+0x2b4/0x400\n wb_workfn+0xe4/0x34c\n process_one_work+0x24c/0x5bc\n worker_thread+0x3e8/0xa50\n kthread+0x150/0x1b4(CVE-2022-48877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregulator: da9211: Use irq handler when ready\r\n\r\nIf the system does not come from reset (like when it is kexec()), the\nregulator might have an IRQ waiting for us.\r\n\r\nIf we enable the IRQ handler before its structures are ready, we crash.\r\n\r\nThis patch fixes:\r\n\r\n[ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078\n[ 1.316096] Call trace:\n[ 1.316101] blocking_notifier_call_chain+0x20/0xa8\n[ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests\n[ 1.327823] regulator_notifier_call_chain+0x1c/0x2c\n[ 1.327825] da9211_irq_handler+0x68/0xf8\n[ 1.327829] irq_thread+0x11c/0x234\n[ 1.327833] kthread+0x13c/0x154(CVE-2022-48891)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000004c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n RIP: 0010:aa_label_next_confined+0xb/0x40\n Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? aa_label_next_confined+0xb/0x40\n apparmor_secmark_check+0xec/0x330\n security_sock_rcv_skb+0x35/0x50\n sk_filter_trim_cap+0x47/0x250\n sock_queue_rcv_skb_reason+0x20/0x60\n raw_rcv+0x13c/0x210\n raw_local_deliver+0x1f3/0x250\n ip_protocol_deliver_rcu+0x4f/0x2f0\n ip_local_deliver_finish+0x76/0xa0\n __netif_receive_skb_one_core+0x89/0xa0\n netif_receive_skb+0x119/0x170\n ? __netdev_alloc_skb+0x3d/0x140\n vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n __napi_poll+0x28/0x1b0\n net_rx_action+0x2a4/0x380\n __do_softirq+0xd1/0x2c8\n __irq_exit_rcu+0xbb/0xf0\n common_interrupt+0x86/0xa0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x26/0x40\n RIP: 0010:apparmor_socket_post_create+0xb/0x200\n Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n ? __pfx_apparmor_socket_post_create+0x10/0x10\n security_socket_post_create+0x4b/0x80\n __sock_create+0x176/0x1f0\n __sys_socket+0x89/0x100\n __x64_sys_socket+0x17/0x20\n do_syscall_64+0x5d/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix race between quota rescan and disable leading to NULL pointer deref\r\n\r\nIf we have one task trying to start the quota rescan worker while another\none is trying to disable quotas, we can end up hitting a race that results\nin the quota rescan worker doing a NULL pointer dereference. The steps for\nthis are the following:\r\n\r\n1) Quotas are enabled;\r\n\r\n2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().\n It calls qgroup_rescan_init() which returns 0 (success) and then joins a\n transaction and commits it;\r\n\r\n3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().\n It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-\u0026gt;flags and calls\n btrfs_qgroup_wait_for_completion(), which returns immediately since the\n rescan worker is not yet running.\n Then it starts a transaction and locks fs_info-\u0026gt;qgroup_ioctl_lock;\r\n\r\n4) Task A queues the rescan worker, by calling btrfs_queue_work();\r\n\r\n5) The rescan worker starts, and calls rescan_should_stop() at the start\n of its while loop, which results in 0 iterations of the loop, since\n the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-\u0026gt;flags by\n task B at step 3);\r\n\r\n6) Task B sets fs_info-\u0026gt;quota_root to NULL;\r\n\r\n7) The rescan worker tries to start a transaction and uses\n fs_info-\u0026gt;quota_root as the root argument for btrfs_start_transaction().\n This results in a NULL pointer dereference down the call chain of\n btrfs_start_transaction(). The stack trace is something like the one\n reported in Link tag below:\r\n\r\n general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]\n CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\n Workqueue: btrfs-qgroup-rescan btrfs_work_helper\n RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564\n Code: 48 89 fb 48 (...)\n RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206\n RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\n RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d\n R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000\n R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003\n FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402\n btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280\n process_one_work+0x877/0xdb0 kernel/workqueue.c:2289\n worker_thread+0xb14/0x1330 kernel/workqueue.c:2436\n kthread+0x266/0x300 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\r\n\r\nSo fix this by having the rescan worker function not attempt to start a\ntransaction if it didn\u0026apos;t do any rescan work.(CVE-2023-52896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nAdd exception protection processing for vd in axi_chan_handle_err function\r\n\r\nSince there is no protection for vd, a kernel panic will be\ntriggered here in exceptional cases.\r\n\r\nYou can refer to the processing of axi_chan_block_xfer_complete function\r\n\r\nThe triggered kernel panic is as follows:\r\n\r\n[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[ 67.848447] Mem abort info:\n[ 67.848449] ESR = 0x96000004\n[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 67.848454] SET = 0, FnV = 0\n[ 67.848456] EA = 0, S1PTW = 0\n[ 67.848458] Data abort info:\n[ 67.848460] ISV = 0, ISS = 0x00000004\n[ 67.848462] CM = 0, WnR = 0\n[ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000\n[ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000\n[ 67.848472] Internal error: Oops: 96000004 [#1] SMP\n[ 67.848475] Modules linked in: dmatest\n[ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11\n[ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)\n[ 67.848487] pc : axi_chan_handle_err+0xc4/0x230\n[ 67.848491] lr : axi_chan_handle_err+0x30/0x230\n[ 67.848493] sp : ffff0803fe55ae50\n[ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200\n[ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080\n[ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850\n[ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000\n[ 67.848512] x21: 0000000000000080 x20: 0000000000002000\n[ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000\n[ 67.848521] x17: 0000000000000000 x16: 0000000000000000\n[ 67.848525] x15: 0000000000000000 x14: 0000000000000000\n[ 67.848529] x13: 0000000000000000 x12: 0000000000000040\n[ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a\n[ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270\n[ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0\n[ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480\n[ 67.848550] x3 : dead000000000100 x2 : dead000000000122\n[ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168\n[ 67.848559] Call trace:\n[ 67.848562] axi_chan_handle_err+0xc4/0x230\n[ 67.848566] dw_axi_dma_interrupt+0xf4/0x590\n[ 67.848569] __handle_irq_event_percpu+0x60/0x220\n[ 67.848573] handle_irq_event+0x64/0x120\n[ 67.848576] handle_fasteoi_irq+0xc4/0x220\n[ 67.848580] __handle_domain_irq+0x80/0xe0\n[ 67.848583] gic_handle_irq+0xc0/0x138\n[ 67.848585] el1_irq+0xc8/0x180\n[ 67.848588] arch_cpu_idle+0x14/0x2c\n[ 67.848591] default_idle_call+0x40/0x16c\n[ 67.848594] do_idle+0x1f0/0x250\n[ 67.848597] cpu_startup_entry+0x2c/0x60\n[ 67.848600] rest_init+0xc0/0xcc\n[ 67.848603] arch_call_rest_init+0x14/0x1c\n[ 67.848606] start_kernel+0x4cc/0x500\n[ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)\n[ 67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mpls: Fix warning during failed attribute validation\r\n\r\nThe \u0026apos;TCA_MPLS_LABEL\u0026apos; attribute is of \u0026apos;NLA_U32\u0026apos; type, but has a\nvalidation type of \u0026apos;NLA_VALIDATE_FUNCTION\u0026apos;. This is an invalid\ncombination according to the comment above \u0026apos;struct nla_policy\u0026apos;:\r\n\r\n\u0026quot;\nMeaning of `validate\u0026apos; field, use via NLA_POLICY_VALIDATE_FN:\n NLA_BINARY Validation function called for the attribute.\n All other Unused - but note that it\u0026apos;s a union\n\u0026quot;\r\n\r\nThis can trigger the warning [1] in nla_get_range_unsigned() when\nvalidation of the attribute fails. Despite being of \u0026apos;NLA_U32\u0026apos; type, the\nassociated \u0026apos;min\u0026apos;/\u0026apos;max\u0026apos; fields in the policy are negative as they are\naliased by the \u0026apos;validate\u0026apos; field.\r\n\r\nFix by changing the attribute type to \u0026apos;NLA_BINARY\u0026apos; which is consistent\nwith the above comment and all other users of NLA_POLICY_VALIDATE_FN().\nAs a result, move the length validation to the validation function.\r\n\r\nNo regressions in MPLS tests:\r\n\r\n # ./tdc.py -f tc-tests/actions/mpls.json\n [...]\n # echo $?\n 0\r\n\r\n[1]\nWARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118\nnla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117\nModules linked in:\nCPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014\nRIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310\n netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411\n netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]\n netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506\n netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546\n rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n ____sys_sendmsg+0x38f/0x500 net/socket.c:2482\n ___sys_sendmsg net/socket.c:2536 [inline]\n __sys_sendmsg+0x197/0x230 net/socket.c:2565\n __do_sys_sendmsg net/socket.c:2574 [inline]\n __se_sys_sendmsg net/socket.c:2572 [inline]\n __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\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\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\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\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\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Fix for possible memory corruption\r\n\r\nInit Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media. For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\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\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\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\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n 0:\t97f85911 \tbl\t0xffffffffffe16444\n 4:\tf94002da \tldr\tx26, [x22]\n 8:\t91008356 \tadd\tx22, x26, #0x20\n c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\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/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\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\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\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)",
"id": "OESA-2024-2106",
"modified": "2026-08-06T11:07:34Z",
"published": "2024-09-06T11:07:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48891"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
},
{
"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-43898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
}
],
"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-48811",
"CVE-2022-48871",
"CVE-2022-48875",
"CVE-2022-48877",
"CVE-2022-48891",
"CVE-2023-52889",
"CVE-2023-52896",
"CVE-2023-52899",
"CVE-2023-52906",
"CVE-2024-40901",
"CVE-2024-41008",
"CVE-2024-41016",
"CVE-2024-41060",
"CVE-2024-41082",
"CVE-2024-42153",
"CVE-2024-42230",
"CVE-2024-42286",
"CVE-2024-42288",
"CVE-2024-42295",
"CVE-2024-42299",
"CVE-2024-42312",
"CVE-2024-43824",
"CVE-2024-43834",
"CVE-2024-43854",
"CVE-2024-43883",
"CVE-2024-43884",
"CVE-2024-43889",
"CVE-2024-43890",
"CVE-2024-43898",
"CVE-2024-43905",
"CVE-2024-43908",
"CVE-2024-44934",
"CVE-2024-44938",
"CVE-2024-44944",
"CVE-2024-44946"
]
}
OESA-2024-2107 (CVE-2022-48811)
Vulnerability from osv_openeuler – Published: 2024-09-06 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface:
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: restore set elements when delete set fails
From abort path, nft_mapelem_activate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).
This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.
Toggle next generation bit for elements when delete set command is invoked and call nft_clear() from .activate (abort) path to restore the next generation bit.
The splat below shows an object in mappings memleak:
[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [...] [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? __warn+0x9f/0x1a0 [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458188] ? report_bug+0x1b1/0x1e0 [43929.458196] ? handle_bug+0x3c/0x70 [43929.458200] ? exc_invalid_op+0x17/0x40 [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables] [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables] [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables] [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables] [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables] [43929.458512] ? rb_insert_color+0x2e/0x280 [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables] [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables] [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables] [43929.458701] ? __rcu_read_unlock+0x46/0x70 [43929.458709] nft_delset+0xff/0x110 [nf_tables] [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables] [43929.458830] nf_tables_deltable+0x501/0x580 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: do not compare internal table flags on updates
Restore skipping transaction if table update does not modify flags.(CVE-2024-27065)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below):
kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state.
Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.(CVE-2024-37078)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump:
BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
For full log, please look at [1].
Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory.
[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm->task_info handling
This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage of vm->task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()
V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.(CVE-2024-41016)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va->bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.(CVE-2024-41060)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: use reserved tag for reg read/write command
In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf:
- For the disable ctrl path, we will not issue connect command
- For the enable ctrl / fw activate path, since connect and reg_xx() are called serially.
So the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix scv instruction crash with kexec
kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel.
Change the kexec sequence to disable AIL after other CPUs have been brought down.
As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.(CVE-2024-42230)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses.
Additionally, the calculations have been rewritten in a clearer and more understandable form.
[Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)
In the Linux kernel, the following vulnerability has been resolved:
riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.(CVE-2024-42267)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.(CVE-2024-42286)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Complete command early within lock
A crash was observed while performing NPIV and FW reset,
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]
The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARN_ON condition of performing dma_free_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash.
Hence complete the command early in unload path but within the lock to avoid race condition.(CVE-2024-42287)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: handle inconsistent state in nilfs_btnode_create_block()
Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug.
It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.
So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page().(CVE-2024-42299)
In the Linux kernel, the following vulnerability has been resolved:
sysctl: always initialize i_uid/i_gid
Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them.
Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference.
Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning:
drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)
Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables.
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
[ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W
ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfxlockacquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfxmutexlock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfxnlavalidate_parse+0x10/0x10 ? pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfxnetdevupdate_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20
To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.(CVE-2024-43883)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash.
Fixed by adding error handling in the function.(CVE-2024-43884)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK>
Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.(CVE-2024-43889)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (max_elts) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map->max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
__tracing_map_insert(), it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".(CVE-2024-43890)
In the Linux kernel, the following vulnerability has been resolved:
ext4: sanity check for NULL pointer after ext4_force_shutdown
Test case: 2 threads write short inline data to a file. In ext4_page_mkwrite the resulting inline data is converted. Handling ext4_grp_locked_error with description "block bitmap and bg descriptor inconsistent: X vs Y free clusters" calls ext4_force_shutdown. The conversion clears EXT4_STATE_MAY_INLINE_DATA but fails for ext4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due to ext4_forced_shutdown. The restoration of inline data fails for the same reason not setting EXT4_STATE_MAY_INLINE_DATA. Without the flag set a regular process path in ext4_da_write_end follows trying to dereference page folio private pointer that has not been set. The fix calls early return with -EIO error shall the pointer to private be NULL.
Sample crash report:
Unable to handle kernel paging request at virtual address dfff800000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfff800000000004] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 lr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160 sp : ffff8000a1957600 x29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020 x20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020 x2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0 Call trace: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer.c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [inline] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: 97f85911 f94002da 91008356 d343fec8 (38796908) ---[ end trace 0000000000000000 ]---
Code disassembly (best guess): 0: 97f85911 bl 0xffffffffffe16444 4: f94002da ldr x26, [x22] 8: 91008356 add x22, x26, #0x20 c: d343fec8 lsr x8, x22, #3 * 10: 38796908 ldrb w8, [x8, x25] <-- trapping instruction(CVE-2024-43898)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the null pointer dereference to ras_manager
Check ras_manager before using it(CVE-2024-43908)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running
Make sure all previous gc cycles have finished by using flush_work before freeing the port.
[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix shift-out-of-bounds in dbDiscardAG
When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative.
This patch fixes the issue by exiting the loop directly when negative shift is found.(CVE-2024-44938)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
syzbot reports a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback.
Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.(CVE-2024-44942)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)
In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
-
Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
-
Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory()
-
Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue
-
Thread A faces an error and finally frees skb that is already in the write queue
-
kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---(CVE-2024-44946)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-226.0.0.125.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-226.0.0.125.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-226.0.0.125.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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR: 8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 28248484 XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000004c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n RIP: 0010:aa_label_next_confined+0xb/0x40\n Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? aa_label_next_confined+0xb/0x40\n apparmor_secmark_check+0xec/0x330\n security_sock_rcv_skb+0x35/0x50\n sk_filter_trim_cap+0x47/0x250\n sock_queue_rcv_skb_reason+0x20/0x60\n raw_rcv+0x13c/0x210\n raw_local_deliver+0x1f3/0x250\n ip_protocol_deliver_rcu+0x4f/0x2f0\n ip_local_deliver_finish+0x76/0xa0\n __netif_receive_skb_one_core+0x89/0xa0\n netif_receive_skb+0x119/0x170\n ? __netdev_alloc_skb+0x3d/0x140\n vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n __napi_poll+0x28/0x1b0\n net_rx_action+0x2a4/0x380\n __do_softirq+0xd1/0x2c8\n __irq_exit_rcu+0xbb/0xf0\n common_interrupt+0x86/0xa0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x26/0x40\n RIP: 0010:apparmor_socket_post_create+0xb/0x200\n Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n ? __pfx_apparmor_socket_post_create+0x10/0x10\n security_socket_post_create+0x4b/0x80\n __sock_create+0x176/0x1f0\n __sys_socket+0x89/0x100\n __x64_sys_socket+0x17/0x20\n do_syscall_64+0x5d/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: restore set elements when delete set fails\r\n\r\nFrom abort path, nft_mapelem_activate() needs to restore refcounters to\nthe original state. Currently, it uses the set-\u0026gt;ops-\u0026gt;walk() to iterate\nover these set elements. The existing set iterator skips inactive\nelements in the next generation, this does not work from the abort path\nto restore the original state since it has to skip active elements\ninstead (not inactive ones).\r\n\r\nThis patch moves the check for inactive elements to the set iterator\ncallback, then it reverses the logic for the .activate case which\nneeds to skip active elements.\r\n\r\nToggle next generation bit for elements when delete set command is\ninvoked and call nft_clear() from .activate (abort) path to restore the\nnext generation bit.\r\n\r\nThe splat below shows an object in mappings memleak:\r\n\r\n[43929.457523] ------------[ cut here ]------------\n[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[...]\n[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 \u0026lt;0f\u0026gt; 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90\n[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246\n[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000\n[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550\n[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f\n[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0\n[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002\n[43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0\n[43929.458114] Call Trace:\n[43929.458118] \u0026lt;TASK\u0026gt;\n[43929.458121] ? __warn+0x9f/0x1a0\n[43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458188] ? report_bug+0x1b1/0x1e0\n[43929.458196] ? handle_bug+0x3c/0x70\n[43929.458200] ? exc_invalid_op+0x17/0x40\n[43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]\n[43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables]\n[43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables]\n[43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]\n[43929.458512] ? rb_insert_color+0x2e/0x280\n[43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables]\n[43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]\n[43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]\n[43929.458701] ? __rcu_read_unlock+0x46/0x70\n[43929.458709] nft_delset+0xff/0x110 [nf_tables]\n[43929.458769] nft_flush_table+0x16f/0x460 [nf_tables]\n[43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables](CVE-2024-27012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: do not compare internal table flags on updates\r\n\r\nRestore skipping transaction if table update does not modify flags.(CVE-2024-27065)\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\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\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\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\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\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\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\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\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Complete command early within lock\r\n\r\nA crash was observed while performing NPIV and FW reset,\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\r\n\r\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\r\n\r\nHence complete the command early in unload path but within the lock to\navoid race condition.(CVE-2024-42287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media. For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\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\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\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\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n 0:\t97f85911 \tbl\t0xffffffffffe16444\n 4:\tf94002da \tldr\tx26, [x22]\n 8:\t91008356 \tadd\tx22, x26, #0x20\n c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\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/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\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\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\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\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\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)",
"id": "OESA-2024-2107",
"modified": "2026-08-06T11:07:34Z",
"published": "2024-09-06T11:07:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2107"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
},
{
"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-43898"
},
{
"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-43908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
}
],
"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-48811",
"CVE-2023-52889",
"CVE-2024-27012",
"CVE-2024-27065",
"CVE-2024-37078",
"CVE-2024-40901",
"CVE-2024-41008",
"CVE-2024-41016",
"CVE-2024-41060",
"CVE-2024-41082",
"CVE-2024-42153",
"CVE-2024-42230",
"CVE-2024-42259",
"CVE-2024-42267",
"CVE-2024-42286",
"CVE-2024-42287",
"CVE-2024-42295",
"CVE-2024-42299",
"CVE-2024-42312",
"CVE-2024-43824",
"CVE-2024-43834",
"CVE-2024-43854",
"CVE-2024-43883",
"CVE-2024-43884",
"CVE-2024-43889",
"CVE-2024-43890",
"CVE-2024-43898",
"CVE-2024-43902",
"CVE-2024-43905",
"CVE-2024-43908",
"CVE-2024-44934",
"CVE-2024-44938",
"CVE-2024-44942",
"CVE-2024-44944",
"CVE-2024-44946"
]
}
OESA-2024-2108 (CVE-2022-48811)
Vulnerability from osv_openeuler – Published: 2024-09-06 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface:
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set.
BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
<IRQ>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? aa_label_next_confined+0xb/0x40
apparmor_secmark_check+0xec/0x330
security_sock_rcv_skb+0x35/0x50
sk_filter_trim_cap+0x47/0x250
sock_queue_rcv_skb_reason+0x20/0x60
raw_rcv+0x13c/0x210
raw_local_deliver+0x1f3/0x250
ip_protocol_deliver_rcu+0x4f/0x2f0
ip_local_deliver_finish+0x76/0xa0
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x119/0x170
? __netdev_alloc_skb+0x3d/0x140
vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
__napi_poll+0x28/0x1b0
net_rx_action+0x2a4/0x380
__do_softirq+0xd1/0x2c8
__irq_exit_rcu+0xbb/0xf0
common_interrupt+0x86/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
? __pfx_apparmor_socket_post_create+0x10/0x10
security_socket_post_create+0x4b/0x80
__sock_create+0x176/0x1f0
__sys_socket+0x89/0x100
__x64_sys_socket+0x17/0x20
do_syscall_64+0x5d/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
? do_syscall_64+0x6c/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump:
BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
For full log, please look at [1].
Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory.
[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm->task_info handling
This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage of vm->task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()
V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.(CVE-2024-41016)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va->bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.(CVE-2024-41060)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: use reserved tag for reg read/write command
In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf:
- For the disable ctrl path, we will not issue connect command
- For the enable ctrl / fw activate path, since connect and reg_xx() are called serially.
So the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix scv instruction crash with kexec
kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel.
Change the kexec sequence to disable AIL after other CPUs have been brought down.
As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.(CVE-2024-42230)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses.
Additionally, the calculations have been rewritten in a clearer and more understandable form.
[Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)
In the Linux kernel, the following vulnerability has been resolved:
riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.(CVE-2024-42267)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.(CVE-2024-42286)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Complete command early within lock
A crash was observed while performing NPIV and FW reset,
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]
The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARN_ON condition of performing dma_free_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash.
Hence complete the command early in unload path but within the lock to avoid race condition.(CVE-2024-42287)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: handle inconsistent state in nilfs_btnode_create_block()
Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug.
It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.
So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page().(CVE-2024-42299)
In the Linux kernel, the following vulnerability has been resolved:
sysctl: always initialize i_uid/i_gid
Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them.
Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference.
Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning:
drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)
Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables.
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
[ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W
ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfxlockacquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfxmutexlock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfxnlavalidate_parse+0x10/0x10 ? pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfxnetdevupdate_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20
To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.(CVE-2024-43883)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash.
Fixed by adding error handling in the function.(CVE-2024-43884)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK>
Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.(CVE-2024-43889)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (max_elts) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map->max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
__tracing_map_insert(), it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".(CVE-2024-43890)
In the Linux kernel, the following vulnerability has been resolved:
ext4: sanity check for NULL pointer after ext4_force_shutdown
Test case: 2 threads write short inline data to a file. In ext4_page_mkwrite the resulting inline data is converted. Handling ext4_grp_locked_error with description "block bitmap and bg descriptor inconsistent: X vs Y free clusters" calls ext4_force_shutdown. The conversion clears EXT4_STATE_MAY_INLINE_DATA but fails for ext4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due to ext4_forced_shutdown. The restoration of inline data fails for the same reason not setting EXT4_STATE_MAY_INLINE_DATA. Without the flag set a regular process path in ext4_da_write_end follows trying to dereference page folio private pointer that has not been set. The fix calls early return with -EIO error shall the pointer to private be NULL.
Sample crash report:
Unable to handle kernel paging request at virtual address dfff800000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfff800000000004] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 lr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160 sp : ffff8000a1957600 x29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020 x20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020 x2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0 Call trace: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer.c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [inline] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: 97f85911 f94002da 91008356 d343fec8 (38796908) ---[ end trace 0000000000000000 ]---
Code disassembly (best guess): 0: 97f85911 bl 0xffffffffffe16444 4: f94002da ldr x26, [x22] 8: 91008356 add x22, x26, #0x20 c: d343fec8 lsr x8, x22, #3 * 10: 38796908 ldrb w8, [x8, x25] <-- trapping instruction(CVE-2024-43898)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the null pointer dereference to ras_manager
Check ras_manager before using it(CVE-2024-43908)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running
Make sure all previous gc cycles have finished by using flush_work before freeing the port.
[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix shift-out-of-bounds in dbDiscardAG
When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative.
This patch fixes the issue by exiting the loop directly when negative shift is found.(CVE-2024-44938)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
syzbot reports a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback.
Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.(CVE-2024-44942)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)
In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
-
Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
-
Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory()
-
Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue
-
Thread A faces an error and finally frees skb that is already in the write queue
-
kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---(CVE-2024-44946)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"perf-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-226.0.0.129.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"perf-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-226.0.0.129.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-226.0.0.129.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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR: 8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 28248484 XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000004c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n RIP: 0010:aa_label_next_confined+0xb/0x40\n Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? aa_label_next_confined+0xb/0x40\n apparmor_secmark_check+0xec/0x330\n security_sock_rcv_skb+0x35/0x50\n sk_filter_trim_cap+0x47/0x250\n sock_queue_rcv_skb_reason+0x20/0x60\n raw_rcv+0x13c/0x210\n raw_local_deliver+0x1f3/0x250\n ip_protocol_deliver_rcu+0x4f/0x2f0\n ip_local_deliver_finish+0x76/0xa0\n __netif_receive_skb_one_core+0x89/0xa0\n netif_receive_skb+0x119/0x170\n ? __netdev_alloc_skb+0x3d/0x140\n vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n __napi_poll+0x28/0x1b0\n net_rx_action+0x2a4/0x380\n __do_softirq+0xd1/0x2c8\n __irq_exit_rcu+0xbb/0xf0\n common_interrupt+0x86/0xa0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x26/0x40\n RIP: 0010:apparmor_socket_post_create+0xb/0x200\n Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n ? __pfx_apparmor_socket_post_create+0x10/0x10\n security_socket_post_create+0x4b/0x80\n __sock_create+0x176/0x1f0\n __sys_socket+0x89/0x100\n __x64_sys_socket+0x17/0x20\n do_syscall_64+0x5d/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\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\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\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\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\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\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\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Complete command early within lock\r\n\r\nA crash was observed while performing NPIV and FW reset,\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\r\n\r\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\r\n\r\nHence complete the command early in unload path but within the lock to\navoid race condition.(CVE-2024-42287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media. For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\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\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\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\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n 0:\t97f85911 \tbl\t0xffffffffffe16444\n 4:\tf94002da \tldr\tx26, [x22]\n 8:\t91008356 \tadd\tx22, x26, #0x20\n c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\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/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\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\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\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\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\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)",
"id": "OESA-2024-2108",
"modified": "2026-08-06T11:07:35Z",
"published": "2024-09-06T11:07:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
},
{
"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-43898"
},
{
"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-43908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
}
],
"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-48811",
"CVE-2023-52889",
"CVE-2024-40901",
"CVE-2024-41008",
"CVE-2024-41016",
"CVE-2024-41060",
"CVE-2024-41082",
"CVE-2024-42153",
"CVE-2024-42230",
"CVE-2024-42259",
"CVE-2024-42267",
"CVE-2024-42286",
"CVE-2024-42287",
"CVE-2024-42295",
"CVE-2024-42299",
"CVE-2024-42312",
"CVE-2024-43824",
"CVE-2024-43834",
"CVE-2024-43854",
"CVE-2024-43883",
"CVE-2024-43884",
"CVE-2024-43889",
"CVE-2024-43890",
"CVE-2024-43898",
"CVE-2024-43902",
"CVE-2024-43905",
"CVE-2024-43908",
"CVE-2024-44934",
"CVE-2024-44938",
"CVE-2024-44942",
"CVE-2024-44944",
"CVE-2024-44946"
]
}
OESA-2024-2181 (CVE-2024-36904)
Vulnerability from osv_openeuler – Published: 2024-09-27 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfxinetcheck_established+0x10/0x10 tcp_v4_connect+0x278/0x530 inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm->task_info handling
This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage of vm->task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini()
V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing
This commit adds null checks for the 'stream' and 'plane' variables in the dcn30_apply_idle_power_optimizations function. These variables were previously assumed to be null at line 922, but they were used later in the code without checking if they were null. This could potentially lead to a null pointer dereference, which would cause a crash.
The null checks ensure that 'stream' and 'plane' are not null before they are used, preventing potential crashes.
Fixes the below static smatch checker: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922)(CVE-2024-43904)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: line6: Fix racy access to midibuf
There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).
This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)
In the Linux kernel, the following vulnerability has been resolved:
tracefs: Use generic inode RCU for synchronizing freeing
With structure layout randomization enabled for 'struct inode' we need to avoid overlapping any of the RCU-used / initialized-only-once members, e.g. i_lru or i_sb_list to not corrupt related list traversals when making use of the rcu_head.
For an unlucky structure layout of 'struct inode' we may end up with the following splat when running the ftrace selftests:
[<...>] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object]) [<...>] ------------[ cut here ]------------ [<...>] kernel BUG at lib/list_debug.c:54! [<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65 [<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [<...>] RIP: 0010:[<ffffffff84656018>] list_del_entry_valid_or_report+0x138/0x3e0 [<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f [<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283 [<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000 [<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001 [<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25 [<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d [<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000 [<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object] [<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0 [<...>] RSI: __func.47+0x4340/0x4400 [<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object] [<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550] [<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550] [<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550] [<...>] R14: tracefs_inode_cache+0x78/0x4e0 [slab object] [<...>] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000 [<...>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0 [<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [<...>] ASID: 0003 [<...>] Stack: [<...>] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0 [<...>] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f [<...>] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392 [<...>] Call Trace: [<...>] <TASK> [<...>] [<ffffffff818a2315>] ? lock_release+0x175/0x380 fffffe80416afaf0 [<...>] [<ffffffff8248b392>] list_lru_del+0x152/0x740 fffffe80416afb48 [<...>] [<ffffffff8248ba93>] list_lru_del_obj+0x113/0x280 fffffe80416afb88 [<...>] [<ffffffff8940fd19>] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90 [<...>] [<ffffffff8295b244>] iput_final+0x1c4/0x9a0 fffffe80416afbb8 [<...>] [<ffffffff8293a52b>] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8 [<...>] [<ffffffff8293fefc>] __dentry_kill+0x23c/0xf00 fffffe80416afc40 [<...>] [<ffffffff8953a85f>] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48 [<...>] [<ffffffff82949ce5>] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70 [<...>] [<ffffffff82949b71>] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78 [<...>] [<ffffffff82949da8>] shrink_dentry_list+0x288/0x760 fffffe80416afc80 [<...>] [<ffffffff8294ae75>] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8 [<...>] [<ffffffff8953a7c3>] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0 [<...>] [<ffffffff8294ad20>] ? do_one_tre ---truncated---(CVE-2024-44959)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading
When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.
panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c _dosoftirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---(CVE-2024-44962)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix pti_clone_pgtable() alignment assumption
Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then
DF from the stack guard.
It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.
These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?
Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)
In the Linux kernel, the following vulnerability has been resolved:
drm/mgag200: Bind I2C lifetime to DRM device
Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc.
Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.(CVE-2024-44967)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.
Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: avoid possible UaF when selecting endp
select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.
A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix double DMA unmapping for XDP_REDIRECT
Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:
WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0(CVE-2024-44984)
In the Linux kernel, the following vulnerability has been resolved:
tcp: prevent concurrent execution of tcp_sk_exit_batch
Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns.
tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list.
This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns.
This allows the netns exit worker to proceed to call
WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));
without the expected 1 -> 0 transition, which then splats.
At same time, error unwind path that is also running inet_twsk_purge() will splat as well:
WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110
... because refcount_dec() of tw_refcount unexpectedly dropped to 0.
This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check.
Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns.(CVE-2024-44991)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Restore lost return in iommu_report_device_fault()
When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return.
Instead the return was accidently deleted which results in trying to process the fault and an eventual crash.
Deleting the return was a typo, put it back.(CVE-2024-44994)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)
In the Linux kernel, the following vulnerability has been resolved:
vsock: fix recursive ->recvmsg calls
After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen:
vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again
We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg().(CVE-2024-44996)
In the Linux kernel, the following vulnerability has been resolved:
gtp: pull network headers in gtp_dev_xmit()
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.
Use pskb_inet_may_pull() to fix this issue.
[1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)
In the Linux kernel, the following vulnerability has been resolved:
fs/netfs/fscache_cookie: add missing "n_accesses" check
This fixes a NULL pointer dereference bug due to a data race which looks like this:
BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 worker_thread+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Modules linked in: CR2: 0000000000000008 ---[ end trace 0000000000000000 ]---
This happened because fscache_cookie_state_machine() was slow and was still running while another process invoked fscache_unuse_cookie(); this led to a fscache_cookie_lru_do_one() call, setting the FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by fscache_cookie_state_machine(), withdrawing the cookie via cachefiles_withdraw_cookie(), clearing cookie->cache_priv.
At the same time, yet another process invoked cachefiles_prepare_write(), which found a NULL pointer in this code line:
struct cachefiles_object *object = cachefiles_cres_object(cres);
The next line crashes, obviously:
struct cachefiles_cache *cache = object->volume->cache;
During cachefiles_prepare_write(), the "n_accesses" counter is non-zero (via fscache_begin_operation()). The cookie must not be withdrawn until it drops to zero.
The counter is checked by fscache_cookie_state_machine() before switching to FSCACHE_COOKIE_STATE_RELINQUISHING and FSCACHE_COOKIE_STATE_WITHDRAWING (in "case FSCACHE_COOKIE_STATE_FAILED"), but not for FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case FSCACHE_COOKIE_STATE_ACTIVE").
This patch adds the missing check. With a non-zero access counter, the function returns and the next fscache_end_cookie_access() call will queue another fscache_cookie_state_machine() call to handle the still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.(CVE-2024-45000)
In the Linux kernel, the following vulnerability has been resolved:
rtla/osnoise: Prevent NULL dereference in error handling
If the "tool->data" allocation fails then there is no need to call osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.(CVE-2024-45002)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:
- File A has inode i_reg and an ea inode i_ea
- getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
-
Then, following three processes running like this:
PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:
- File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
- getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
- Then, following three processes running like this:
PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---(CVE-2024-45003)
In the Linux kernel, the following vulnerability has been resolved:
Input: MT - limit max slots
syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Take state lock during tx timeout reporter
mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag.(CVE-2024-45019)
In the Linux kernel, the following vulnerability has been resolved:
fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, if all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied.
For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to.
The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe.
Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open.
The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first.
- new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
- make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset().
Reproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()
[BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace:
BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20
Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause.
The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio.
This means a double freeing thus causing use-after-free, e.g.:
-
Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes.
-
The first run of btrfs_submit_chunk()
2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted.
- The second run of btrfs_submit_chunk()
3.1 Call btrfs_map_block(), which by somehow failed Now we call btrfs_bio_end_io() to handle the error
3.2 btrfs_bio_end_io() calls the original endio function Which is end_bbio_data_read(), and it calls bio_put() for the original bio.
Now the original bio is freed.
- The submitted first 64K bio finished Now we call into btrfs_check_read_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free.
And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing.
[FIX] Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(), which has the extra check on split bios and do the pr ---truncated---(CVE-2024-46687)
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: mark last busy before uart_add_one_port
With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT.
The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add |-> bus_probe_device |->device_initial_probe |->__device_attach |-> pm_runtime_get_sync(dev->parent); |-> pm_request_idle(dev); |-> pm_runtime_put(dev->parent);
So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang.
To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console.(CVE-2024-46706)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case.
This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix dereference after null check
check the pointer hive before use.(CVE-2024-46720)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index for mc_data[] when i = 0.(CVE-2024-46731)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve leaks in cow_file_range
In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked
Cases 2 and 3 in the out_reserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfs_free_qgroup_data.(CVE-2024-46733)
In the Linux kernel, the following vulnerability has been resolved:
smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()
null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) and parse_lease_state() return NULL.
Fix this by check if 'lease_ctx_info' is NULL.
Additionally, remove the redundant parentheses in parse_durable_handle_context().(CVE-2024-46742)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: sanity check symbolic link size
Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.
This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.
The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:
-
squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.
-
Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.
-
The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.
This patch adds a sanity check which checks that the symbolic link size is not larger than expected.
--
V2: fix spelling mistake.(CVE-2024-46744)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - reject requests with unreasonable number of slots
When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.
Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)
In the Linux kernel, the following vulnerability has been resolved:
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()
Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.(CVE-2024-46751)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).(CVE-2024-46752)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (adc128d818) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)
In the Linux kernel, the following vulnerability has been resolved:
eventfs: Use list_del_rcu() for SRCU protected list variable
Chi Zhiling reported:
We found a null pointer accessing in tracefs[1], the reason is that the variable 'ei_child' is set to LIST_POISON1, that means the list was removed in eventfs_remove_rec. so when access the ei_child->is_freed, the panic triggered.
by the way, the following script can reproduce this panic
loop1 (){ while true do echo "p:kp submit_bio" > /sys/kernel/debug/tracing/kprobe_events echo "" > /sys/kernel/debug/tracing/kprobe_events done } loop2 (){ while true do tree /sys/kernel/debug/tracing/events/kprobes/ done } loop1 & loop2
[1]: [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150 [ 1147.968239][T17331] Mem abort info: [ 1147.971739][T17331] ESR = 0x0000000096000004 [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1147.982171][T17331] SET = 0, FnV = 0 [ 1147.985906][T17331] EA = 0, S1PTW = 0 [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault [ 1147.995292][T17331] Data abort info: [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls] [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2 [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650 [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020 [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398 [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398 [ 1148.115969][T17331] sp : ffff80008d56bbd0 [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000 [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100 [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10 [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000 [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0 [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0 [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862 [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068 [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001 [ 1148.198131][T17331] Call trace: [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398 [ 1148.205864][T17331] iterate_dir+0x98/0x188 [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160 [ 1148.215161][T17331] invoke_syscall+0x78/0x108 [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0 [ 1148.224977][T17331] do_el0_svc+0x24/0x38 [ 1148.228974][T17331] el0_svc+0x40/0x168 [ 1148.232798][T17 ---truncated---(CVE-2024-46785)
In the Linux kernel, the following vulnerability has been resolved:
fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF
The fscache_cookie_lru_timer is initialized when the fscache module is inserted, but is not deleted when the fscache module is removed. If timer_reduce() is called before removing the fscache module, the fscache_cookie_lru_timer will be added to the timer list of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the fscache module, as follows:
================================================================== BUG: unable to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: <IRQ> tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 </TASK> Modules linked in: [last unloaded: netfs] ==================================================================
Therefore delete fscache_cookie_lru_timer when removing the fscahe module.(CVE-2024-46786)
In the Linux kernel, the following vulnerability has been resolved:
sch/netem: fix use after free in netem_dequeue
If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails")
Commands to trigger KASAN UaF:
ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF(CVE-2024-46800)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-source-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"perf-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"python3-perf-6.6.0-44.0.0.50.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-44.0.0.50.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-44.0.0.50.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-source-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"perf-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"python3-perf-6.6.0-44.0.0.50.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-44.0.0.50.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-44.0.0.50.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n - amdgpu_vm_get_task_info: reference counts up task_info before\n returning this info\n - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n - Fix wrong indentation\n - No debug message for -ENOMEM\n - Add NULL check for task_info\n - Do not duplicate the debug messages (ti vs no ti)\n - Get first reference of task_info in vm_init(), put last\n in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n - fix double reference increment in create_task_info\n - change amdgpu_vm_get_task_info_pasid\n - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checks for \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; before dereferencing\r\n\r\nThis commit adds null checks for the \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; variables in\nthe dcn30_apply_idle_power_optimizations function. These variables were\npreviously assumed to be null at line 922, but they were used later in\nthe code without checking if they were null. This could potentially lead\nto a null pointer dereference, which would cause a crash.\r\n\r\nThe null checks ensure that \u0026apos;stream\u0026apos; and \u0026apos;plane\u0026apos; are not null before\nthey are used, preventing potential crashes.\r\n\r\nFixes the below static smatch checker:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed \u0026apos;stream\u0026apos; could be null (see line 922)\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed \u0026apos;plane\u0026apos; could be null (see line 922)(CVE-2024-43904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access. This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracefs: Use generic inode RCU for synchronizing freeing\r\n\r\nWith structure layout randomization enabled for \u0026apos;struct inode\u0026apos; we need to\navoid overlapping any of the RCU-used / initialized-only-once members,\ne.g. i_lru or i_sb_list to not corrupt related list traversals when making\nuse of the rcu_head.\r\n\r\nFor an unlucky structure layout of \u0026apos;struct inode\u0026apos; we may end up with the\nfollowing splat when running the ftrace selftests:\r\n\r\n[\u0026lt;...\u0026gt;] list_del corruption, ffff888103ee2cb0-\u0026gt;next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])\n[\u0026lt;...\u0026gt;] ------------[ cut here ]------------\n[\u0026lt;...\u0026gt;] kernel BUG at lib/list_debug.c:54!\n[\u0026lt;...\u0026gt;] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[\u0026lt;...\u0026gt;] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65\n[\u0026lt;...\u0026gt;] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n[\u0026lt;...\u0026gt;] RIP: 0010:[\u0026lt;ffffffff84656018\u0026gt;] __list_del_entry_valid_or_report+0x138/0x3e0\n[\u0026lt;...\u0026gt;] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff \u0026lt;0f\u0026gt; 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f\n[\u0026lt;...\u0026gt;] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283\n[\u0026lt;...\u0026gt;] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000\n[\u0026lt;...\u0026gt;] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001\n[\u0026lt;...\u0026gt;] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25\n[\u0026lt;...\u0026gt;] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d\n[\u0026lt;...\u0026gt;] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000\n[\u0026lt;...\u0026gt;] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] RDX: __list_del_entry_valid_or_report+0x108/0x3e0\n[\u0026lt;...\u0026gt;] RSI: __func__.47+0x4340/0x4400\n[\u0026lt;...\u0026gt;] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]\n[\u0026lt;...\u0026gt;] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]\n[\u0026lt;...\u0026gt;] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000\n[\u0026lt;...\u0026gt;] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[\u0026lt;...\u0026gt;] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0\n[\u0026lt;...\u0026gt;] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[\u0026lt;...\u0026gt;] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[\u0026lt;...\u0026gt;] ASID: 0003\n[\u0026lt;...\u0026gt;] Stack:\n[\u0026lt;...\u0026gt;] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0\n[\u0026lt;...\u0026gt;] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f\n[\u0026lt;...\u0026gt;] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392\n[\u0026lt;...\u0026gt;] Call Trace:\n[\u0026lt;...\u0026gt;] \u0026lt;TASK\u0026gt;\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff818a2315\u0026gt;] ? lock_release+0x175/0x380 fffffe80416afaf0\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8248b392\u0026gt;] list_lru_del+0x152/0x740 fffffe80416afb48\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8248ba93\u0026gt;] list_lru_del_obj+0x113/0x280 fffffe80416afb88\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8940fd19\u0026gt;] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8295b244\u0026gt;] iput_final+0x1c4/0x9a0 fffffe80416afbb8\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8293a52b\u0026gt;] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8293fefc\u0026gt;] __dentry_kill+0x23c/0xf00 fffffe80416afc40\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8953a85f\u0026gt;] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff82949ce5\u0026gt;] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff82949b71\u0026gt;] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff82949da8\u0026gt;] shrink_dentry_list+0x288/0x760 fffffe80416afc80\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8294ae75\u0026gt;] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8953a7c3\u0026gt;] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0\n[\u0026lt;...\u0026gt;] [\u0026lt;ffffffff8294ad20\u0026gt;] ? do_one_tre\n---truncated---(CVE-2024-44959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading\r\n\r\nWhen unload the btnxpuart driver, its associated timer will be deleted.\nIf the timer happens to be modified at this moment, it leads to the\nkernel call this timer even after the driver unloaded, resulting in\nkernel panic.\nUse timer_shutdown_sync() instead of del_timer_sync() to prevent rearming.\r\n\r\npanic log:\n Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart]\n CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1\n Hardware name: NXP i.MX95 19X19 board (DT)\n pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0xffff80007a2cf464\n lr : call_timer_fn.isra.0+0x24/0x80\n...\n Call trace:\n 0xffff80007a2cf464\n __run_timers+0x234/0x280\n run_timer_softirq+0x20/0x40\n __do_softirq+0x100/0x26c\n ____do_softirq+0x10/0x1c\n call_on_irq_stack+0x24/0x4c\n do_softirq_own_stack+0x1c/0x2c\n irq_exit_rcu+0xc0/0xdc\n el0_interrupt+0x54/0xd8\n __el0_irq_handler_common+0x18/0x24\n el0t_64_irq_handler+0x10/0x1c\n el0t_64_irq+0x190/0x194\n Code: ???????? ???????? ???????? ???????? (????????)\n ---[ end trace 0000000000000000 ]---\n Kernel panic - not syncing: Oops: Fatal exception in interrupt\n SMP: stopping secondary CPUs\n Kernel Offset: disabled\n CPU features: 0x0,c0000000,40028143,1000721b\n Memory Limit: none\n ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---(CVE-2024-44962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mgag200: Bind I2C lifetime to DRM device\r\n\r\nManaged cleanup with devm_add_action_or_reset() will release the I2C\nadapter when the underlying Linux device goes away. But the connector\nstill refers to it, so this cleanup leaves behind a stale pointer\nin struct drm_connector.ddc.\r\n\r\nBind the lifetime of the I2C adapter to the connector\u0026apos;s lifetime by\nusing DRM\u0026apos;s managed release. When the DRM device goes away (after\nthe Linux device) DRM will first clean up the connector and then\nclean up the I2C adapter.(CVE-2024-44967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Prevent release of buffer in I/O\r\n\r\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\r\n\r\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: avoid possible UaF when selecting endp\r\n\r\nselect_local_address() and select_signal_address() both select an\nendpoint entry from the list inside an RCU protected section, but return\na reference to it, to be read later on. If the entry is dereferenced\nafter the RCU unlock, reading info could cause a Use-after-Free.\r\n\r\nA simple solution is to copy the required info while inside the RCU\nprotected section to avoid any risk of UaF later. The address ID might\nneed to be modified later to handle the ID0 case later, so a copy seems\nOK to deal with.(CVE-2024-44974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_en: Fix double DMA unmapping for XDP_REDIRECT\r\n\r\nRemove the dma_unmap_page_attrs() call in the driver\u0026apos;s XDP_REDIRECT\ncode path. This should have been removed when we let the page pool\nhandle the DMA mapping. This bug causes the warning:\r\n\r\nWARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100\nCPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu\nHardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024\nRIP: 0010:iommu_dma_unmap_page+0xd5/0x100\nCode: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9\nRSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c\nR10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000\nR13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002\nFS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0\n? show_regs+0x6d/0x80\n? __warn+0x89/0x150\n? iommu_dma_unmap_page+0xd5/0x100\n? report_bug+0x16a/0x190\n? handle_bug+0x51/0xa0\n? exc_invalid_op+0x18/0x80\n? iommu_dma_unmap_page+0xd5/0x100\n? iommu_dma_unmap_page+0x35/0x100\ndma_unmap_page_attrs+0x55/0x220\n? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f\nbnxt_rx_xdp+0x237/0x520 [bnxt_en]\nbnxt_rx_pkt+0x640/0xdd0 [bnxt_en]\n__bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]\nbnxt_poll+0xaa/0x1e0 [bnxt_en]\n__napi_poll+0x33/0x1e0\nnet_rx_action+0x18a/0x2f0(CVE-2024-44984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: prevent concurrent execution of tcp_sk_exit_batch\r\n\r\nIts possible that two threads call tcp_sk_exit_batch() concurrently,\nonce from the cleanup_net workqueue, once from a task that failed to clone\na new netns. In the latter case, error unwinding calls the exit handlers\nin reverse order for the \u0026apos;failed\u0026apos; netns.\r\n\r\ntcp_sk_exit_batch() calls tcp_twsk_purge().\nProblem is that since commit b099ce2602d8 (\u0026quot;net: Batch inet_twsk_purge\u0026quot;),\nthis function picks up twsk in any dying netns, not just the one passed\nin via exit_batch list.\r\n\r\nThis means that the error unwind of setup_net() can \u0026quot;steal\u0026quot; and destroy\ntimewait sockets belonging to the exiting netns.\r\n\r\nThis allows the netns exit worker to proceed to call\r\n\r\nWARN_ON_ONCE(!refcount_dec_and_test(\u0026amp;net-\u0026gt;ipv4.tcp_death_row.tw_refcount));\r\n\r\nwithout the expected 1 -\u0026gt; 0 transition, which then splats.\r\n\r\nAt same time, error unwind path that is also running inet_twsk_purge()\nwill splat as well:\r\n\r\nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210\n...\n refcount_dec include/linux/refcount.h:351 [inline]\n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70\n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221\n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304\n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n setup_net+0x714/0xb40 net/core/net_namespace.c:375\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\r\n\r\n... because refcount_dec() of tw_refcount unexpectedly dropped to 0.\r\n\r\nThis doesn\u0026apos;t seem like an actual bug (no tw sockets got lost and I don\u0026apos;t\nsee a use-after-free) but as erroneous trigger of debug check.\r\n\r\nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge()\nblocks other task from doing final _dec_and_test before mutex-owner has\nremoved all tw sockets of dying netns.(CVE-2024-44991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Restore lost return in iommu_report_device_fault()\r\n\r\nWhen iommu_report_device_fault gets called with a partial fault it is\nsupposed to collect the fault into the group and then return.\r\n\r\nInstead the return was accidently deleted which results in trying to\nprocess the fault and an eventual crash.\r\n\r\nDeleting the return was a typo, put it back.(CVE-2024-44994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n \u2502\n \u25bc\n ......\nsetup tc \u2502\n \u2502 \u25bc\n \u25bc DOWN: napi_disable()\nnapi_disable()(skip) \u2502\n \u2502 \u2502\n \u25bc \u25bc\n ...... ......\n \u2502 \u2502\n \u25bc \u2502\nnapi_enable() \u2502\n \u25bc\n UINIT: netif_napi_del()\n \u2502\n \u25bc\n ......\n \u2502\n \u25bc\n INIT: netif_napi_add()\n \u2502\n \u25bc\n ...... global reset start\n \u2502 \u2502\n \u25bc \u25bc\n UP: napi_enable()(skip) ......\n \u2502 \u2502\n \u25bc \u25bc\n ...... napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvsock: fix recursive -\u0026gt;recvmsg calls\r\n\r\nAfter a vsock socket has been added to a BPF sockmap, its prot-\u0026gt;recvmsg\nhas been replaced with vsock_bpf_recvmsg(). Thus the following\nrecursiion could happen:\r\n\r\nvsock_bpf_recvmsg()\n -\u0026gt; __vsock_recvmsg()\n -\u0026gt; vsock_connectible_recvmsg()\n -\u0026gt; prot-\u0026gt;recvmsg()\n -\u0026gt; vsock_bpf_recvmsg() again\r\n\r\nWe need to fix it by calling the original -\u0026gt;recvmsg() without any BPF\nsockmap logic in __vsock_recvmsg().(CVE-2024-44996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n xmit_one net/core/dev.c:3580 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3145 [inline]\n packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3994 [inline]\n slab_alloc_node mm/slub.c:4037 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n alloc_skb include/linux/skbuff.h:1320 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n packet_snd net/packet/af_packet.c:3088 [inline]\n packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/netfs/fscache_cookie: add missing \u0026quot;n_accesses\u0026quot; check\r\n\r\nThis fixes a NULL pointer dereference bug due to a data race which\nlooks like this:\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP PTI\n CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43\n Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n Workqueue: events_unbound netfs_rreq_write_to_cache_work\n RIP: 0010:cachefiles_prepare_write+0x30/0xa0\n Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 \u0026lt;48\u0026gt; 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10\n RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286\n RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000\n RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438\n RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001\n R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68\n R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00\n FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x1f/0x70\n ? page_fault_oops+0x15d/0x440\n ? search_module_extables+0xe/0x40\n ? fixup_exception+0x22/0x2f0\n ? exc_page_fault+0x5f/0x100\n ? asm_exc_page_fault+0x22/0x30\n ? cachefiles_prepare_write+0x30/0xa0\n netfs_rreq_write_to_cache_work+0x135/0x2e0\n process_one_work+0x137/0x2c0\n worker_thread+0x2e9/0x400\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\n CR2: 0000000000000008\n ---[ end trace 0000000000000000 ]---\r\n\r\nThis happened because fscache_cookie_state_machine() was slow and was\nstill running while another process invoked fscache_unuse_cookie();\nthis led to a fscache_cookie_lru_do_one() call, setting the\nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by\nfscache_cookie_state_machine(), withdrawing the cookie via\ncachefiles_withdraw_cookie(), clearing cookie-\u0026gt;cache_priv.\r\n\r\nAt the same time, yet another process invoked\ncachefiles_prepare_write(), which found a NULL pointer in this code\nline:\r\n\r\n struct cachefiles_object *object = cachefiles_cres_object(cres);\r\n\r\nThe next line crashes, obviously:\r\n\r\n struct cachefiles_cache *cache = object-\u0026gt;volume-\u0026gt;cache;\r\n\r\nDuring cachefiles_prepare_write(), the \u0026quot;n_accesses\u0026quot; counter is\nnon-zero (via fscache_begin_operation()). The cookie must not be\nwithdrawn until it drops to zero.\r\n\r\nThe counter is checked by fscache_cookie_state_machine() before\nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and\nFSCACHE_COOKIE_STATE_WITHDRAWING (in \u0026quot;case\nFSCACHE_COOKIE_STATE_FAILED\u0026quot;), but not for\nFSCACHE_COOKIE_STATE_LRU_DISCARDING (\u0026quot;case\nFSCACHE_COOKIE_STATE_ACTIVE\u0026quot;).\r\n\r\nThis patch adds the missing check. With a non-zero access counter,\nthe function returns and the next fscache_end_cookie_access() call\nwill queue another fscache_cookie_state_machine() call to handle the\nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD.(CVE-2024-45000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtla/osnoise: Prevent NULL dereference in error handling\r\n\r\nIf the \u0026quot;tool-\u0026gt;data\u0026quot; allocation fails then there is no need to call\nosnoise_free_top() and, in fact, doing so will lead to a NULL dereference.(CVE-2024-45002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n PA PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(i_reg)\n spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n spin_unlock(lru_lock)\n rm file A\n i_reg-\u0026gt;nlink = 0\n iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n ext4_evict_inode\n ext4_xattr_delete_inode\n ext4_xattr_inode_dec_ref_all\n ext4_xattr_inode_iget\n ext4_iget(i_ea-\u0026gt;i_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n PA PB PC\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n ixa-\u0026gt;i_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(ib)\n spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n spin_unlock(lru_lock)\n rm file B\n ib-\u0026gt;nlink = 0\n rm file A\n iput(ia)\n ubifs_evict_inode(ia)\n ubifs_jnl_delete_inode(ia)\n ubifs_jnl_write_inode(ia)\n make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n ubifs_iget(ixa-\u0026gt;i_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(ixa)\n | iput(ib) // ib-\u0026gt;nlink is 0, do evict\n | ubifs_evict_inode\n | ubifs_jnl_delete_inode(ib)\n \u2193 ubifs_jnl_write_inode\n ABBA deadlock \u2190-----make_reservation(BASEHD)\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Take state lock during tx timeout reporter\r\n\r\nmlx5e_safe_reopen_channels() requires the state lock taken. The\nreferenced changed in the Fixes tag removed the lock to fix another\nissue. This patch adds it back but at a later point (when calling\nmlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the\nFixes tag.(CVE-2024-45019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes. What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear. Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds. In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()\r\n\r\n[BUG]\nThere is an internal report that KASAN is reporting use-after-free, with\nthe following backtrace:\r\n\r\n BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45\n CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]\n Call Trace:\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x5e/0x2f0\n print_report+0x118/0x216\n kasan_report+0x11d/0x1f0\n btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n process_one_work+0xce0/0x12a0\n worker_thread+0x717/0x1250\n kthread+0x2e3/0x3c0\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x11/0x20\r\n\r\n Allocated by task 20917:\n kasan_save_stack+0x37/0x60\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x7d/0x80\n kmem_cache_alloc_noprof+0x16e/0x3e0\n mempool_alloc_noprof+0x12e/0x310\n bio_alloc_bioset+0x3f0/0x7a0\n btrfs_bio_alloc+0x2e/0x50 [btrfs]\n submit_extent_page+0x4d1/0xdb0 [btrfs]\n btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n btrfs_readahead+0x29a/0x430 [btrfs]\n read_pages+0x1a7/0xc60\n page_cache_ra_unbounded+0x2ad/0x560\n filemap_get_pages+0x629/0xa20\n filemap_read+0x335/0xbf0\n vfs_read+0x790/0xcb0\n ksys_read+0xfd/0x1d0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\n Freed by task 20917:\n kasan_save_stack+0x37/0x60\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x50\n __kasan_slab_free+0x4b/0x60\n kmem_cache_free+0x214/0x5d0\n bio_free+0xed/0x180\n end_bbio_data_read+0x1cc/0x580 [btrfs]\n btrfs_submit_chunk+0x98d/0x1880 [btrfs]\n btrfs_submit_bio+0x33/0x70 [btrfs]\n submit_one_bio+0xd4/0x130 [btrfs]\n submit_extent_page+0x3ea/0xdb0 [btrfs]\n btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n btrfs_readahead+0x29a/0x430 [btrfs]\n read_pages+0x1a7/0xc60\n page_cache_ra_unbounded+0x2ad/0x560\n filemap_get_pages+0x629/0xa20\n filemap_read+0x335/0xbf0\n vfs_read+0x790/0xcb0\n ksys_read+0xfd/0x1d0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\n[CAUSE]\nAlthough I cannot reproduce the error, the report itself is good enough\nto pin down the cause.\r\n\r\nThe call trace is the regular endio workqueue context, but the\nfree-by-task trace is showing that during btrfs_submit_chunk() we\nalready hit a critical error, and is calling btrfs_bio_end_io() to error\nout. And the original endio function called bio_put() to free the whole\nbio.\r\n\r\nThis means a double freeing thus causing use-after-free, e.g.:\r\n\r\n1. Enter btrfs_submit_bio() with a read bio\n The read bio length is 128K, crossing two 64K stripes.\r\n\r\n2. The first run of btrfs_submit_chunk()\r\n\r\n2.1 Call btrfs_map_block(), which returns 64K\n2.2 Call btrfs_split_bio()\n Now there are two bios, one referring to the first 64K, the other\n referring to the second 64K.\n2.3 The first half is submitted.\r\n\r\n3. The second run of btrfs_submit_chunk()\r\n\r\n3.1 Call btrfs_map_block(), which by somehow failed\n Now we call btrfs_bio_end_io() to handle the error\r\n\r\n3.2 btrfs_bio_end_io() calls the original endio function\n Which is end_bbio_data_read(), and it calls bio_put() for the\n original bio.\r\n\r\n Now the original bio is freed.\r\n\r\n4. The submitted first 64K bio finished\n Now we call into btrfs_check_read_bio() and tries to advance the bio\n iter.\n But since the original bio (thus its iter) is already freed, we\n trigger the above use-after free.\r\n\r\n And even if the memory is not poisoned/corrupted, we will later call\n the original endio function, causing a double freeing.\r\n\r\n[FIX]\nInstead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),\nwhich has the extra check on split bios and do the pr\n---truncated---(CVE-2024-46687)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: fsl_lpuart: mark last busy before uart_add_one_port\r\n\r\nWith \u0026quot;earlycon initcall_debug=1 loglevel=8\u0026quot; in bootargs, kernel\nsometimes boot hang. It is because normal console still is not ready,\nbut runtime suspend is called, so early console putchar will hang\nin waiting TRDE set in UARTSTAT.\r\n\r\nThe lpuart driver has auto suspend delay set to 3000ms, but during\nuart_add_one_port, a child device serial ctrl will added and probed with\nits pm runtime enabled(see serial_ctrl.c).\nThe runtime suspend call path is:\ndevice_add\n |-\u0026gt; bus_probe_device\n |-\u0026gt;device_initial_probe\n\t |-\u0026gt;__device_attach\n |-\u0026gt; pm_runtime_get_sync(dev-\u0026gt;parent);\n\t\t\t |-\u0026gt; pm_request_idle(dev);\n\t\t\t |-\u0026gt; pm_runtime_put(dev-\u0026gt;parent);\r\n\r\nSo in the end, before normal console ready, the lpuart get runtime\nsuspended. And earlycon putchar will hang.\r\n\r\nTo address the issue, mark last busy just after pm_runtime_enable,\nthree seconds is long enough to switch from bootconsole to normal\nconsole.(CVE-2024-46706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix dereference after null check\r\n\r\ncheck the pointer hive before use.(CVE-2024-46720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n ------------[ cut here ]------------\n WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? __warn.cold+0x8e/0xea\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? report_bug+0xff/0x140\n ? handle_bug+0x3b/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? close_ctree+0x222/0x4d0 [btrfs]\n generic_shutdown_super+0x70/0x160\n kill_anon_super+0x11/0x40\n btrfs_kill_super+0x11/0x20 [btrfs]\n deactivate_locked_super+0x2e/0xa0\n cleanup_mnt+0xb5/0x150\n task_work_run+0x57/0x80\n syscall_exit_to_user_mode+0x121/0x130\n do_syscall_64+0xab/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f916847a887\n ---[ end trace 0000000000000000 ]---\n BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n link from disk. This assigns the corrupted value\n 3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n this corrupted value to the length variable, which being a\n signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n the copied bytes is less than length, which being negative means\n the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neventfs: Use list_del_rcu() for SRCU protected list variable\r\n\r\nChi Zhiling reported:\r\n\r\n We found a null pointer accessing in tracefs[1], the reason is that the\n variable \u0026apos;ei_child\u0026apos; is set to LIST_POISON1, that means the list was\n removed in eventfs_remove_rec. so when access the ei_child-\u0026gt;is_freed, the\n panic triggered.\r\n\r\n by the way, the following script can reproduce this panic\r\n\r\n loop1 (){\n while true\n do\n echo \u0026quot;p:kp submit_bio\u0026quot; \u0026gt; /sys/kernel/debug/tracing/kprobe_events\n echo \u0026quot;\u0026quot; \u0026gt; /sys/kernel/debug/tracing/kprobe_events\n done\n }\n loop2 (){\n while true\n do\n tree /sys/kernel/debug/tracing/events/kprobes/\n done\n }\n loop1 \u0026amp;\n loop2\r\n\r\n [1]:\n [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150\n [ 1147.968239][T17331] Mem abort info:\n [ 1147.971739][T17331] ESR = 0x0000000096000004\n [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits\n [ 1147.982171][T17331] SET = 0, FnV = 0\n [ 1147.985906][T17331] EA = 0, S1PTW = 0\n [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault\n [ 1147.995292][T17331] Data abort info:\n [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges\n [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP\n [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls]\n [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2\n [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650\n [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020\n [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398\n [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398\n [ 1148.115969][T17331] sp : ffff80008d56bbd0\n [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000\n [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100\n [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10\n [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000\n [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0\n [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0\n [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862\n [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068\n [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001\n [ 1148.198131][T17331] Call trace:\n [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398\n [ 1148.205864][T17331] iterate_dir+0x98/0x188\n [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160\n [ 1148.215161][T17331] invoke_syscall+0x78/0x108\n [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0\n [ 1148.224977][T17331] do_el0_svc+0x24/0x38\n [ 1148.228974][T17331] el0_svc+0x40/0x168\n [ 1148.232798][T17\n---truncated---(CVE-2024-46785)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF\r\n\r\nThe fscache_cookie_lru_timer is initialized when the fscache module\nis inserted, but is not deleted when the fscache module is removed.\nIf timer_reduce() is called before removing the fscache module,\nthe fscache_cookie_lru_timer will be added to the timer list of\nthe current cpu. Afterwards, a use-after-free will be triggered\nin the softIRQ after removing the fscache module, as follows:\r\n\r\n==================================================================\nBUG: unable to handle page fault for address: fffffbfff803c9e9\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855\nTainted: [W]=WARN\nRIP: 0010:__run_timer_base.part.0+0x254/0x8a0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n tmigr_handle_remote_up+0x627/0x810\n __walk_groups.isra.0+0x47/0x140\n tmigr_handle_remote+0x1fa/0x2f0\n handle_softirqs+0x180/0x590\n irq_exit_rcu+0x84/0xb0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:default_idle+0xf/0x20\n default_idle_call+0x38/0x60\n do_idle+0x2b5/0x300\n cpu_startup_entry+0x54/0x60\n start_secondary+0x20d/0x280\n common_startup_64+0x13e/0x148\n \u0026lt;/TASK\u0026gt;\nModules linked in: [last unloaded: netfs]\n==================================================================\r\n\r\nTherefore delete fscache_cookie_lru_timer when removing the fscahe module.(CVE-2024-46786)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)",
"id": "OESA-2024-2181",
"modified": "2026-08-06T11:07:39Z",
"published": "2024-09-27T11:07:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2181"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45002"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46786"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-36904",
"CVE-2024-41008",
"CVE-2024-43904",
"CVE-2024-44954",
"CVE-2024-44959",
"CVE-2024-44962",
"CVE-2024-44965",
"CVE-2024-44967",
"CVE-2024-44969",
"CVE-2024-44974",
"CVE-2024-44984",
"CVE-2024-44991",
"CVE-2024-44994",
"CVE-2024-44995",
"CVE-2024-44996",
"CVE-2024-44999",
"CVE-2024-45000",
"CVE-2024-45002",
"CVE-2024-45003",
"CVE-2024-45008",
"CVE-2024-45019",
"CVE-2024-45025",
"CVE-2024-46687",
"CVE-2024-46706",
"CVE-2024-46714",
"CVE-2024-46720",
"CVE-2024-46723",
"CVE-2024-46731",
"CVE-2024-46733",
"CVE-2024-46742",
"CVE-2024-46744",
"CVE-2024-46745",
"CVE-2024-46747",
"CVE-2024-46751",
"CVE-2024-46752",
"CVE-2024-46759",
"CVE-2024-46785",
"CVE-2024-46786",
"CVE-2024-46800"
]
}
RHSA-2024:10771
Vulnerability from csaf_redhat - Published: 2024-12-04 00:56 - Updated: 2026-09-28 03:30In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting
RHSA-2024:7000
Vulnerability from csaf_opensuse - Published: 2024-09-24 02:39 - Updated: 2026-10-02 17:10In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.