Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-35915 (GCVE-0-2024-35915)
Vulnerability from cvelistv5 – Published: 2024-05-19 08:35 – Updated: 2026-08-05 11:30| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
6a2968aaf50c7a22fced77a5e24aa636281efca8 , < 11387b2effbb55f58dc2111ef4b4b896f2756240
(git)
Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < 03fe259649a551d336a7f20919b641ea100e3fff (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < 755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < ac68d9fa09e410fa3ed20fb721d56aa558695e16 (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < a946ebee45b09294c8b0b0e77410b763c4d2817a (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < 8948e30de81faee87eeee01ef42a1f6008f5a83a (git) Affected: 6a2968aaf50c7a22fced77a5e24aa636281efca8 , < d24b03535e5eb82e025219c2f632b485409c898f (git) |
guessed | |
| Linux | Linux |
Affected:
3.2
Unaffected: 0 , < 3.2 (semver) Unaffected: 4.19.312 , ≤ 4.19.* (semver) Unaffected: 5.4.274 , ≤ 5.4.* (semver) Unaffected: 5.10.215 , ≤ 5.10.* (semver) Unaffected: 5.15.154 , ≤ 5.15.* (semver) Unaffected: 6.1.85 , ≤ 6.1.* (semver) Unaffected: 6.6.26 , ≤ 6.6.* (semver) Unaffected: 6.8.5 , ≤ 6.8.* (semver) Unaffected: 6.9 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem |
Affected:
0 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-35915",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-20T17:12:44.324505Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-04T17:34:39.499Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:49.232Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T11:52:46.691Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "11387b2effbb55f58dc2111ef4b4b896f2756240",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "03fe259649a551d336a7f20919b641ea100e3fff",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "ac68d9fa09e410fa3ed20fb721d56aa558695e16",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "a946ebee45b09294c8b0b0e77410b763c4d2817a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "8948e30de81faee87eeee01ef42a1f6008f5a83a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "d24b03535e5eb82e025219c2f632b485409c898f",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.2"
},
{
"lessThan": "3.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.26",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.5",
"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": "4.19.312",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.85",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.26",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.5",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "3.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\n\nsyzbot reported the following uninit-value access issue [1][2]:\n\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\n\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:A - NCI control/notification frames are delivered to `nci_rx_work()` by the NFC controller whose notification stream is driven by an NFC peer/tag in adjacent RF range, and the same parser is fed by the N_NCI tty line discipline and /dev/virtual_nci on the local host. This matches the kernel CNA\u0027s scoring of the directly related NCI packet-validation fixes (CVE-2025-40043, CVE-2026-43291, CVE-2026-63915) as Adjacent.\nAC:L - Triggering only requires that a single NCI frame with a zero payload length field reach the RX queue; the missing check is unconditional, with no race, timing window, or memory-layout precondition. Every dispatch through `nci_rsp_packet()`/`nci_ntf_packet()` then reads past the received data deterministically.\nPR:N - The RF-side path requires no authentication or privileges of any kind \u2014 an NFC peer in range needs no credentials, and the NCI parser runs before any application-level policy. The local fallbacks (N_NCI ldisc via TIOCSETD on a pty) are reachable by an ordinary unprivileged user.\nUI:N - Frames are consumed by the `nci_rx_work` workqueue as soon as they are queued by `nci_recv_frame()`; NFC polling/discovery runs autonomously on the device. No victim action is needed.\nS:U - The uninitialized reads, out-of-bounds accesses, and state corruption are all confined to kernel memory and the NFC device state within the same security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - Uninitialized/out-of-bounds heap bytes are memcpy\u0027d into `nfc_target.nfcid1`, `sensb_res`, and `sensf_res` by `nci_extract_rf_params_*()` and then exported to userspace by `nfc_genl_send_target()` as netlink attributes, a direct kernel heap information leak; `nci_core_init_rsp_packet_v1()` additionally reads up to ~270 bytes past the payload via an uninitialized `num_supported_rf_interfaces` offset.\nI:H - `nci_core_conn_credits_ntf_packet()` writes `conn_entries[i].conn_id` back into the skb beyond the received payload and adds uninitialized credit values to connection flow control, while uninit values are stored into `ndev-\u003enci_ver`, `max_ctrl_pkt_payload_len`, `supported_rf_interfaces`, and `manufact_specific_info`, corrupting kernel state used by subsequent parsing and transmission decisions.\nA:H - Out-of-bounds reads past the skb buffer and the corrupted length/interface counts driving further parsing can fault or oops the kernel, and the poisoned NCI device state (credit counters, `nci_ver`, packet length limits) leaves the NFC stack in an inconsistent state. Any such memory-safety error in softirq/workqueue context is a full kernel crash."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:30:57.434Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
}
],
"title": "nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35915",
"datePublished": "2024-05-19T08:35:08.239Z",
"dateReserved": "2024-05-17T13:50:33.122Z",
"dateUpdated": "2026-08-05T11:30:57.434Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-35915",
"date": "2026-09-19",
"epss": "0.00323",
"percentile": "0.25519"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "11387b2effbb55f58dc2111ef4b4b896f2756240",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "03fe259649a551d336a7f20919b641ea100e3fff",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "ac68d9fa09e410fa3ed20fb721d56aa558695e16",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "a946ebee45b09294c8b0b0e77410b763c4d2817a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "8948e30de81faee87eeee01ef42a1f6008f5a83a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "d24b03535e5eb82e025219c2f632b485409c898f",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.2"
},
{
"lessThan": "3.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.26",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BDA8503D-7AD7-4EC3-B31E-F6FD0C2E8403",
"versionEndExcluding": "4.19.312",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F45A0F3C-C16D-49C4-86D6-D021C3D4B834",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9CD5894E-58E9-4B4A-B0F4-3E6BC134B8F5",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "325665BF-2409-49D9-B391-39AD4566FDBD",
"versionEndExcluding": "6.1.85",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C520696A-A594-4FFC-A32D-12DA535CE911",
"versionEndExcluding": "6.6.26",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DBD6C99E-4250-4DFE-8447-FF2075939D10",
"versionEndExcluding": "6.8.5",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*",
"matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\n\nsyzbot reported the following uninit-value access issue [1][2]:\n\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\n\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: nfc: nci: corrigi\u00f3 el valor uninit en nci_dev_up y nci_ntf_packet syzbot inform\u00f3 el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. La recepci\u00f3n de un paquete con un payload de tama\u00f1o cero se considera inesperada y, por lo tanto, dichos paquetes deben descartarse silenciosamente. Este parche resolvi\u00f3 este problema verificando el tama\u00f1o del payload antes de llamar a los c\u00f3digos de controlador de cada tipo de mensaje."
}
],
"id": "CVE-2024-35915",
"lastModified": "2026-08-04T11:18:11.050",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.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-35915",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-20T17:12:44.324505Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-19T09:15:11.987",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-908"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-08-18T17:07:42+00:00",
"cve": "CVE-2024-35915",
"id": "CVE-2024-35915",
"initial_release_date": "2024-05-19T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-35915.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:49.232Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T11:52:46.691Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-35915",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-20T17:12:44.324505Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-05-23T19:01:25.041Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "11387b2effbb55f58dc2111ef4b4b896f2756240",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "03fe259649a551d336a7f20919b641ea100e3fff",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "ac68d9fa09e410fa3ed20fb721d56aa558695e16",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "a946ebee45b09294c8b0b0e77410b763c4d2817a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "8948e30de81faee87eeee01ef42a1f6008f5a83a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "d24b03535e5eb82e025219c2f632b485409c898f",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.2"
},
{
"lessThan": "3.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.26",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.5",
"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": "4.19.312",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.85",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.26",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.5",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "3.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\n\nsyzbot reported the following uninit-value access issue [1][2]:\n\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\n\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:A - NCI control/notification frames are delivered to `nci_rx_work()` by the NFC controller whose notification stream is driven by an NFC peer/tag in adjacent RF range, and the same parser is fed by the N_NCI tty line discipline and /dev/virtual_nci on the local host. This matches the kernel CNA\u0027s scoring of the directly related NCI packet-validation fixes (CVE-2025-40043, CVE-2026-43291, CVE-2026-63915) as Adjacent.\nAC:L - Triggering only requires that a single NCI frame with a zero payload length field reach the RX queue; the missing check is unconditional, with no race, timing window, or memory-layout precondition. Every dispatch through `nci_rsp_packet()`/`nci_ntf_packet()` then reads past the received data deterministically.\nPR:N - The RF-side path requires no authentication or privileges of any kind \u2014 an NFC peer in range needs no credentials, and the NCI parser runs before any application-level policy. The local fallbacks (N_NCI ldisc via TIOCSETD on a pty) are reachable by an ordinary unprivileged user.\nUI:N - Frames are consumed by the `nci_rx_work` workqueue as soon as they are queued by `nci_recv_frame()`; NFC polling/discovery runs autonomously on the device. No victim action is needed.\nS:U - The uninitialized reads, out-of-bounds accesses, and state corruption are all confined to kernel memory and the NFC device state within the same security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - Uninitialized/out-of-bounds heap bytes are memcpy\u0027d into `nfc_target.nfcid1`, `sensb_res`, and `sensf_res` by `nci_extract_rf_params_*()` and then exported to userspace by `nfc_genl_send_target()` as netlink attributes, a direct kernel heap information leak; `nci_core_init_rsp_packet_v1()` additionally reads up to ~270 bytes past the payload via an uninitialized `num_supported_rf_interfaces` offset.\nI:H - `nci_core_conn_credits_ntf_packet()` writes `conn_entries[i].conn_id` back into the skb beyond the received payload and adds uninitialized credit values to connection flow control, while uninit values are stored into `ndev-\u003enci_ver`, `max_ctrl_pkt_payload_len`, `supported_rf_interfaces`, and `manufact_specific_info`, corrupting kernel state used by subsequent parsing and transmission decisions.\nA:H - Out-of-bounds reads past the skb buffer and the corrupted length/interface counts driving further parsing can fault or oops the kernel, and the poisoned NCI device state (credit counters, `nci_ver`, packet length limits) leaves the NFC stack in an inconsistent state. Any such memory-safety error in softirq/workqueue context is a full kernel crash."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:30:57.434Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
}
],
"title": "nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35915",
"datePublished": "2024-05-19T08:35:08.239Z",
"dateReserved": "2024-05-17T13:50:33.122Z",
"dateUpdated": "2026-08-05T11:30:57.434Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2024-AVI-0800
Vulnerability from certfr_avis - Published: 2024-09-20 - Updated: 2024-09-20
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | openSUSE Leap Micro 5.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Manager Proxy 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Real Time Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP3 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 12 12-SP5 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Enterprise Storage 7.1 | ||
| SUSE | N/A | SUSE Real Time Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 Business Critical Linux 15-SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Software Development Kit 12 SP5 | ||
| SUSE | N/A | SUSE Manager Server 4.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | openSUSE Leap 15.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.5 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "openSUSE Leap Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Real Time Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 12 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Enterprise Storage 7.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Real Time Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 Business Critical Linux 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Software Development Kit 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
}
],
"affected_systems_content": null,
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-38662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38662"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2022-48651",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48651"
},
{
"name": "CVE-2022-48786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48786"
},
{
"name": "CVE-2024-42162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42162"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-43819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43819"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2022-48837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48837"
},
{
"name": "CVE-2023-52846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52846"
},
{
"name": "CVE-2022-48910",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48910"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2022-48851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48851"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-35965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35965"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2022-2964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2964"
},
{
"name": "CVE-2022-48912",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48912"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2022-48899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48899"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2022-48926",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48926"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2022-48788",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48788"
},
{
"name": "CVE-2022-48930",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48930"
},
{
"name": "CVE-2022-48857",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48857"
},
{
"name": "CVE-2023-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52907"
},
{
"name": "CVE-2022-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48873"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2022-48798",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48798"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2023-52708",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52708"
},
{
"name": "CVE-2023-52901",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52901"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2022-48790",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48790"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2022-48791",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-27398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27398"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2022-48789",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48789"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2022-48934",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48934"
},
{
"name": "CVE-2023-1582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1582"
},
{
"name": "CVE-2022-48919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48919"
},
{
"name": "CVE-2022-48823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48823"
},
{
"name": "CVE-2024-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23307"
},
{
"name": "CVE-2021-47425",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47425"
},
{
"name": "CVE-2022-48931",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48931"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2021-4441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4441"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2021-47373",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47373"
},
{
"name": "CVE-2024-42226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42226"
},
{
"name": "CVE-2021-4440",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4440"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2022-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48875"
},
{
"name": "CVE-2022-0854",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0854"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2022-48769",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48769"
},
{
"name": "CVE-2023-2176",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2176"
},
{
"name": "CVE-2022-48856",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48856"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2022-48778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48778"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2021-47549",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47549"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2022-48775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48775"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2022-48858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48858"
},
{
"name": "CVE-2022-48802",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48802"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2022-48843",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48843"
},
{
"name": "CVE-2024-39489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39489"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2022-48838",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48838"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-26610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26610"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2022-48787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48787"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2022-20368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-20368"
},
{
"name": "CVE-2022-48822",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48822"
},
{
"name": "CVE-2024-40910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40910"
},
{
"name": "CVE-2022-48805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48805"
},
{
"name": "CVE-2021-47289",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47289"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2022-48811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48811"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2022-28748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28748"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2022-48834",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48834"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2022-48839",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48839"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2022-48925",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48925"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2022-48901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48901"
},
{
"name": "CVE-2024-35817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35817"
},
{
"name": "CVE-2024-26828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26828"
},
{
"name": "CVE-2022-48917",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48917"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2022-48686",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48686"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2022-48928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48928"
},
{
"name": "CVE-2023-52893",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52893"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2022-48920",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48920"
},
{
"name": "CVE-2022-48853",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48853"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2022-48865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48865"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2022-48872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48872"
},
{
"name": "CVE-2023-6546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6546"
},
{
"name": "CVE-2022-48933",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48933"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2022-48751",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48751"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2021-47341",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47341"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2022-48905",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48905"
},
{
"name": "CVE-2024-26930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26930"
},
{
"name": "CVE-2022-48896",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48896"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2022-48662",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48662"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2021-47257",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47257"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2022-48835",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48835"
},
{
"name": "CVE-2022-48824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48824"
}
],
"initial_release_date": "2024-09-20T00:00:00",
"last_revision_date": "2024-09-20T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-0800",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-09-20T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3320-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243320-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3347-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243347-1"
},
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3322-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243322-1"
},
{
"published_at": "2024-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3249-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243249-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3334-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243334-1"
},
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3318-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243318-1"
},
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3321-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243321-1"
},
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3319-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243319-1"
},
{
"published_at": "2024-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3251-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243251-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3348-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243348-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3337-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243337-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3338-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243338-1"
},
{
"published_at": "2024-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3252-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243252-1"
},
{
"published_at": "2024-09-20",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3350-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243350-1"
},
{
"published_at": "2024-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3304-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243304-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3336-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243336-1"
},
{
"published_at": "2024-09-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3349-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243349-1"
}
]
}
FKIE_CVE-2024-35915
Vulnerability from fkie_nvd - Published: 2024-05-19 09:15 - Updated: 2026-08-04 11:185.5 (Medium) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html | Mailing List | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html | Mailing List | |
| 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e | https://cert-portal.siemens.com/productcert/html/ssa-265688.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.9 | |
| debian | debian_linux | 10.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "11387b2effbb55f58dc2111ef4b4b896f2756240",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "03fe259649a551d336a7f20919b641ea100e3fff",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "ac68d9fa09e410fa3ed20fb721d56aa558695e16",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "a946ebee45b09294c8b0b0e77410b763c4d2817a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "8948e30de81faee87eeee01ef42a1f6008f5a83a",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
},
{
"lessThan": "d24b03535e5eb82e025219c2f632b485409c898f",
"status": "affected",
"version": "6a2968aaf50c7a22fced77a5e24aa636281efca8",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/nfc/nci/core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.2"
},
{
"lessThan": "3.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.26",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BDA8503D-7AD7-4EC3-B31E-F6FD0C2E8403",
"versionEndExcluding": "4.19.312",
"versionStartIncluding": "3.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F45A0F3C-C16D-49C4-86D6-D021C3D4B834",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9CD5894E-58E9-4B4A-B0F4-3E6BC134B8F5",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "325665BF-2409-49D9-B391-39AD4566FDBD",
"versionEndExcluding": "6.1.85",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C520696A-A594-4FFC-A32D-12DA535CE911",
"versionEndExcluding": "6.6.26",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DBD6C99E-4250-4DFE-8447-FF2075939D10",
"versionEndExcluding": "6.8.5",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*",
"matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\n\nsyzbot reported the following uninit-value access issue [1][2]:\n\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\n\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: nfc: nci: corrigi\u00f3 el valor uninit en nci_dev_up y nci_ntf_packet syzbot inform\u00f3 el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. La recepci\u00f3n de un paquete con un payload de tama\u00f1o cero se considera inesperada y, por lo tanto, dichos paquetes deben descartarse silenciosamente. Este parche resolvi\u00f3 este problema verificando el tama\u00f1o del payload antes de llamar a los c\u00f3digos de controlador de cada tipo de mensaje."
}
],
"id": "CVE-2024-35915",
"lastModified": "2026-08-04T11:18:11.050",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.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-35915",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-20T17:12:44.324505Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-19T09:15:11.987",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-908"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-M6CX-H2F4-5JR4
Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.
This patch resolved this issue by checking payload size before calling each message type handler codes.
{
"affected": [],
"aliases": [
"CVE-2024-35915"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T09:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\n\nsyzbot reported the following uninit-value access issue [1][2]:\n\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\n\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.",
"id": "GHSA-m6cx-h2f4-5jr4",
"modified": "2026-05-12T12:31:49Z",
"published": "2024-05-19T09:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"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"
}
]
}
ICSA-24-102-01
Vulnerability from csaf_cisa - Published: 2024-04-09 00:00 - Updated: 2026-05-14 06:00OESA-2024-1706 (CVE-2021-47247)
Vulnerability from osv_openeuler – Published: 2024-06-14 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:
net/mlx5e: Fix use-after-free of encap entry in neigh update handler
Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock removal from TC filter update path and properly handle concurrent encap entry insertion/deletion which can lead to following use-after-free:
[23827.464923] ================================================================== [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core] [23827.476731] Call Trace: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831] ? process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ? __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Allocated by task 28248: [23827.507694] kasan_save_stack+0x1b/0x40 [23827.508476] __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.517300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg+0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131] _syssendmsg+0x590/0x770 [23827.520851] _sys_sendmsg+0xd8/0x160 [23827.521552] __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae [23827.523797] [23827.524163] Freed by task 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] kasan_set_free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] process_one_work+0x8ac/0x14e0 [23827.530770] worker_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/0x30 [23827.532785] [23827.533147] Last potentially related work creation: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] kvfree_call_rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncated---(CVE-2021-47247)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.
Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible use-after-free in HFC_cleanup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47356)
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Disable Tx queues when reconfiguring the interface
The Tx queues were not disabled in situations where the driver needed to stop the interface to apply a new configuration. This could result in a kernel panic when doing any of the 3 following actions: * reconfiguring the number of queues (ethtool -L) * reconfiguring the size of the ring buffers (ethtool -G) * installing/removing an XDP program (ip l set dev ethX xdp)
Prevent the panic by making sure netif_tx_disable is called when stopping an interface.
Without this patch, the following kernel panic can be observed when doing any of the actions above:
Unable to handle kernel paging request at virtual address ffff80001238d040 [....] Call trace: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [ end trace 0000000000000002 ]---(CVE-2021-47558)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix crash by keep old cfg when update TCs more than queues
There are problems if allocated queues less than Traffic Classes.
Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs.
Another case is if we first set less queues, and later update more TCs config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.
[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice] [ 95.971774] ice_vsi_open+0x25/0x120 [ice] [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice] [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280 [ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975891] sock_sendmsg+0x4c/0x50 [ 95.979032] syssendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [ 95.985242] ? wake_up_common_lock+0x79/0x90 [ 95.988338] ? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copy_to_user+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [ 95.997619] ? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca
Only update num_txq/rxq when passed check, and restore tc_cfg if setup queue map failed.(CVE-2022-48652)
In the Linux kernel, the following vulnerability has been resolved:
aio: fix mremap after fork null-deref
Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL.
jmoyer@redhat.com: fix 80 column issue
In the Linux kernel, the following vulnerability has been resolved:
riscv: Check if the code to patch lies in the exit section
Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.(CVE-2023-52677)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing error checks to *_ctl_get()
The ctl_get() functions which call scarlett2_update() were not checking the return value. Fix to check the return value and pass to the caller.(CVE-2023-52680)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_event_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52686)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached.(CVE-2023-52702)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread:
INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...
This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)
In the Linux kernel, the following vulnerability has been resolved:
IB/IPoIB: Fix legacy IPoIB due to wrong number of queues
The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues.
This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time.
BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 ip6_send_skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180 ? __switch_to_asm+0x3a/0x60 ? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc </TASK>(CVE-2023-52745)
In the Linux kernel, the following vulnerability has been resolved:
xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
int type = nla_type(nla);
if (type > XFRMA_MAX) { return -EOPNOTSUPP; }
@type is then used as an array index and can be used as a Spectre v1 gadget.
if (nla_len(nla) < compat_policy[type].len) {
array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users.(CVE-2023-52746)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid data corruption caused by decline
We found a data corruption issue during testing of SMC-R on Redis applications.
The benchmark has a low probability of reporting a strange error as shown below.
"Error: Protocol error, got "\xe2" as reply type byte"
Finally, we found that the retrieved error data was as follows:
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations:
client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp
wait decline
(after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <--------------
As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection.
This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout).
This issue requires an immediate solution, since the protocol updates involve a more long-term solution.(CVE-2023-52775)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix dfs radar event locking
The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52798)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix htt pktlog locking
The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52800)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs
The hns3 driver define an array of string to show the coalesce info, but if the kernel adds a new mode or a new state, out-of-bounds access may occur when coalesce info is read via debugfs, this patch fix the problem.(CVE-2023-52807)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52865)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Add missing skb_mark_for_recycle
Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")).
This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").(CVE-2024-27393)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:
[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_report+0x139/0x170 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_check_range+0x2c3/0x2e0 [ 472.075308] mutex_lock+0x68/0xc0 [ 472.075308] l2cap_chan_timeout+0x181/0x300 [ 472.075308] process_one_work+0x5d2/0xe00 [ 472.075308] worker_thread+0xe1d/0x1660 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork+0x4d/0x80 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork_asm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: error_code(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2cap_chan_timeout [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? __die_body+0x8d/0xe0 [ 472.096136] ? page_fault_oops+0x6b8/0x9a0 [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0 [ 472.096136] ? do_user_addr_fault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutex_lock+0x68/0xc0 [ 472.096136] ? add_taint+0x42/0xd0 [ 472.096136] ? exc_page_fault+0x6a/0x1b0 [ 472.096136] ? asm_exc_page_fault+0x26/0x30 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] ? mutex_lock+0x88/0xc0 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] l2cap_chan_timeo ---truncated---(CVE-2024-27399)
In the Linux kernel, the following vulnerability has been resolved:
phonet/pep: fix racy skb_queue_empty() use
The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges.
Example: macvlan0 | br0 / \ ethX ethY
ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.
- skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry
- skb is broad/mcast packet. bridge now passes clones out on each bridge interface.
- skb gets passed up the stack.
-
In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.
The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting.
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again.
This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook.
Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.(CVE-2024-27415)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.(CVE-2024-35790)
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.
However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.]
One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1].
Fix by not rolling back a failed rollback and add a warning to avoid future cases.
[1] WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35853)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another according to the number of available credits.
The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration.
The destruction of a region that still has filters referencing it can result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30(CVE-2024-35854)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the 'vregion->lock' mutex.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0]
12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) _sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan_base_hdr is present in skb->head
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is not hardirq-unsafe, that is interrupts are disabled, and bail out with an error.
Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK>
Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---(CVE-2024-35896)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Protect against int overflow for stack access size
This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail.
This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.(CVE-2024-35905)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.
This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Limit read size on v1.2
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.(CVE-2024-35924)
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix not validating setsockopt user input
syzbot reported sco_sock_setsockopt() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)
In the Linux kernel, the following vulnerability has been resolved:
geneve: fix header validation in geneve[6]_xmit_skb
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol.
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all.
If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected.
Add skb_vlan_inet_prepare() to perform a complete mac validation.
Use this in geneve for the moment, I suspect we need to adopt this more broadly.
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types.
v2,v3 - Addressed Sabrina comments on v1 and v2
[1]
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: check for NULL idev in ip_route_use_hint()
syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1].
It appears the bug exists in latest trees.
All calls to __in_dev_get_rcu() must be checked for a NULL result.
[1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during pf initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.(CVE-2024-36029)
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---(CVE-2024-36886)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_nxt is properly initialized on connect
Christoph reported a splat hinting at a corrupted snd_una:
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK>
When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values.
We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice.
Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time.(CVE-2024-36889)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: fix uninitialised kfifo
If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace.
Initialise the kfifo in the case where the software debounce is already active.(CVE-2024-36898)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines.
Here is the typical stack when issue happened:
[free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule()
[use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free
The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway.
To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.(CVE-2024-36899)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations.
[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9381/1: kasan: clear stale stack poison
We found below OOB crash:
[ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ==================================================================
We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle.
This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
From cited commit [1] that explain the problem
Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning.
In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned.
If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel.
Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console.
To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online.
From cited commit [2]
Extend to check for CONFIG_KASAN_STACK
[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")(CVE-2024-36906)
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: do not WARN if iocg was already offlined
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time:
WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0
The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns.
Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.(CVE-2024-36908)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)
In the Linux kernel, the following vulnerability has been resolved:
net: core: reject skb_copy(_expand) for fraglist GSO skbs
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment.(CVE-2024-36929)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: sync all devices to wait all processes being evicted
If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: avoid off-by-one read from userspace
We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.(CVE-2024-36964)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-headers-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.79.0.159.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-headers-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.79.0.159.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.79.0.159.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Medium"
},
"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\nnet/mlx5e: Fix use-after-free of encap entry in neigh update handler\r\n\r\nFunction mlx5e_rep_neigh_update() wasn\u0026apos;t updated to accommodate rtnl lock\nremoval from TC filter update path and properly handle concurrent encap\nentry insertion/deletion which can lead to following use-after-free:\r\n\r\n [23827.464923] ==================================================================\n [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635\n [23827.472251]\n [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5\n [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]\n [23827.476731] Call Trace:\n [23827.477260] dump_stack+0xbb/0x107\n [23827.477906] print_address_description.constprop.0+0x18/0x140\n [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.480905] kasan_report.cold+0x7c/0xd8\n [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.482744] kasan_check_range+0x145/0x1a0\n [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]\n [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]\n [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]\n [23827.497486] ? read_word_at_a_time+0xe/0x20\n [23827.498250] ? strscpy+0xa0/0x2a0\n [23827.498889] process_one_work+0x8ac/0x14e0\n [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400\n [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0\n [23827.501359] ? rwlock_bug.part.0+0x90/0x90\n [23827.502116] worker_thread+0x53b/0x1220\n [23827.502831] ? process_one_work+0x14e0/0x14e0\n [23827.503627] kthread+0x328/0x3f0\n [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40\n [23827.505065] ? __kthread_bind_mask+0x90/0x90\n [23827.505912] ret_from_fork+0x1f/0x30\n [23827.506621]\n [23827.506987] Allocated by task 28248:\n [23827.507694] kasan_save_stack+0x1b/0x40\n [23827.508476] __kasan_kmalloc+0x7c/0x90\n [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]\n [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]\n [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]\n [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]\n [23827.513298] tc_setup_cb_add+0x1d5/0x420\n [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]\n [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]\n [23827.515821] tc_new_tfilter+0x89a/0x2070\n [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0\n [23827.517300] netlink_rcv_skb+0x11d/0x340\n [23827.518021] netlink_unicast+0x42b/0x700\n [23827.518742] netlink_sendmsg+0x743/0xc20\n [23827.519467] sock_sendmsg+0xb2/0xe0\n [23827.520131] ____sys_sendmsg+0x590/0x770\n [23827.520851] ___sys_sendmsg+0xd8/0x160\n [23827.521552] __sys_sendmsg+0xb7/0x140\n [23827.522238] do_syscall_64+0x3a/0x70\n [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae\n [23827.523797]\n [23827.524163] Freed by task 25948:\n [23827.524780] kasan_save_stack+0x1b/0x40\n [23827.525488] kasan_set_track+0x1c/0x30\n [23827.526187] kasan_set_free_info+0x20/0x30\n [23827.526968] __kasan_slab_free+0xed/0x130\n [23827.527709] slab_free_freelist_hook+0xcf/0x1d0\n [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0\n [23827.529317] kfree_rcu_work+0x55f/0xb70\n [23827.530024] process_one_work+0x8ac/0x14e0\n [23827.530770] worker_thread+0x53b/0x1220\n [23827.531480] kthread+0x328/0x3f0\n [23827.532114] ret_from_fork+0x1f/0x30\n [23827.532785]\n [23827.533147] Last potentially related work creation:\n [23827.534007] kasan_save_stack+0x1b/0x40\n [23827.534710] kasan_record_aux_stack+0xab/0xc0\n [23827.535492] kvfree_call_rcu+0x31/0x7b0\n [23827.536206] mlx5e_tc_del\n---truncated---(CVE-2021-47247)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA: Verify port when creating flow rule\r\n\r\nValidate port value provided by the user and with that remove no longer\nneeded validation by the driver. The missing check in the mlx5_ib driver\ncould cause to the below oops.\r\n\r\nCall trace:\n _create_flow_rule+0x2d4/0xf28 [mlx5_ib]\n mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]\n ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]\n ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]\n ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]\n do_vfs_ioctl+0xd0/0xaf0\n ksys_ioctl+0x84/0xb4\n __arm64_sys_ioctl+0x28/0xc4\n el0_svc_common.constprop.3+0xa4/0x254\n el0_svc_handler+0x84/0xa0\n el0_svc+0x10/0x26c\n Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: fix possible use-after-free in HFC_cleanup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: Disable Tx queues when reconfiguring the interface\r\n\r\nThe Tx queues were not disabled in situations where the driver needed to\nstop the interface to apply a new configuration. This could result in a\nkernel panic when doing any of the 3 following actions:\n* reconfiguring the number of queues (ethtool -L)\n* reconfiguring the size of the ring buffers (ethtool -G)\n* installing/removing an XDP program (ip l set dev ethX xdp)\r\n\r\nPrevent the panic by making sure netif_tx_disable is called when stopping\nan interface.\r\n\r\nWithout this patch, the following kernel panic can be observed when doing\nany of the actions above:\r\n\r\nUnable to handle kernel paging request at virtual address ffff80001238d040\n[....]\n Call trace:\n dwmac4_set_addr+0x8/0x10\n dev_hard_start_xmit+0xe4/0x1ac\n sch_direct_xmit+0xe8/0x39c\n __dev_queue_xmit+0x3ec/0xaf0\n dev_queue_xmit+0x14/0x20\n[...]\n[ end trace 0000000000000002 ]---(CVE-2021-47558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Fix crash by keep old cfg when update TCs more than queues\r\n\r\nThere are problems if allocated queues less than Traffic Classes.\r\n\r\nCommit a632b2a4c920 (\u0026quot;ice: ethtool: Prohibit improper channel config\nfor DCB\u0026quot;) already disallow setting less queues than TCs.\r\n\r\nAnother case is if we first set less queues, and later update more TCs\nconfig due to LLDP, ice_vsi_cfg_tc() will failed but left dirty\nnum_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.\r\n\r\n[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.\n[ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!\n[ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0\n[ 95.969621] general protection fault: 0000 [#1] SMP NOPTI\n[ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1\n[ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021\n[ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60\n[ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 \u0026lt;8b\u0026gt; 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c\n[ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206\n[ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0\n[ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200\n[ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000\n[ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100\n[ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460\n[ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000\n[ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0\n[ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 95.971530] PKRU: 55555554\n[ 95.971573] Call Trace:\n[ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]\n[ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]\n[ 95.971774] ice_vsi_open+0x25/0x120 [ice]\n[ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]\n[ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]\n[ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]\n[ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]\n[ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]\n[ 95.972220] dcbnl_ieee_set+0x89/0x230\n[ 95.972279] ? dcbnl_ieee_del+0x150/0x150\n[ 95.972341] dcb_doit+0x124/0x1b0\n[ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0\n[ 95.972457] ? dcb_doit+0x14d/0x1b0\n[ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280\n[ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100\n[ 95.972661] netlink_rcv_skb+0xcf/0xf0\n[ 95.972720] netlink_unicast+0x16d/0x220\n[ 95.972781] netlink_sendmsg+0x2ba/0x3a0\n[ 95.975891] sock_sendmsg+0x4c/0x50\n[ 95.979032] ___sys_sendmsg+0x2e4/0x300\n[ 95.982147] ? kmem_cache_alloc+0x13e/0x190\n[ 95.985242] ? __wake_up_common_lock+0x79/0x90\n[ 95.988338] ? __check_object_size+0xac/0x1b0\n[ 95.991440] ? _copy_to_user+0x22/0x30\n[ 95.994539] ? move_addr_to_user+0xbb/0xd0\n[ 95.997619] ? __sys_sendmsg+0x53/0x80\n[ 96.000664] __sys_sendmsg+0x53/0x80\n[ 96.003747] do_syscall_64+0x5b/0x1d0\n[ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nOnly update num_txq/rxq when passed check, and restore tc_cfg if setup\nqueue map failed.(CVE-2022-48652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naio: fix mremap after fork null-deref\r\n\r\nCommit e4a0d3e720e7 (\u0026quot;aio: Make it possible to remap aio ring\u0026quot;) introduced\na null-deref if mremap is called on an old aio mapping after fork as\nmm-\u0026gt;ioctx_table will be set to NULL.\r\n\r\n[jmoyer@redhat.com: fix 80 column issue](CVE-2023-52646)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Check if the code to patch lies in the exit section\r\n\r\nOtherwise we fall through to vmalloc_to_page() which panics since the\naddress does not lie in the vmalloc region.(CVE-2023-52677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add missing error checks to *_ctl_get()\r\n\r\nThe *_ctl_get() functions which call scarlett2_update_*() were not\nchecking the return value. Fix to check the return value and pass to\nthe caller.(CVE-2023-52680)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_event_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: fix possible memory leak in ovs_meter_cmd_set()\r\n\r\nold_meter needs to be free after it is detached regardless of whether\nthe new meter is successfully attached.(CVE-2023-52702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix underflow in second superblock position calculations\r\n\r\nMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the second\nsuperblock, underflows when the argument device size is less than 4096\nbytes. Therefore, when using this macro, it is necessary to check in\nadvance that the device size is not less than a lower limit, or at least\nthat underflow does not occur.\r\n\r\nThe current nilfs2 implementation lacks this check, causing out-of-bound\nblock access when mounting devices smaller than 4096 bytes:\r\n\r\n I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0\n phys_seg 1 prio class 2\n NILFS (loop0): unable to read secondary superblock (blocksize = 1024)\r\n\r\nIn addition, when trying to resize the filesystem to a size below 4096\nbytes, this underflow occurs in nilfs_resize_fs(), passing a huge number\nof segments to nilfs_sufile_resize(), corrupting parameters such as the\nnumber of segments in superblocks. This causes excessive loop iterations\nin nilfs_sufile_resize() during a subsequent resize ioctl, causing\nsemaphore ns_segctor_sem to block for a long time and hang the writer\nthread:\r\n\r\n INFO: task segctord:5067 blocked for more than 143 seconds.\n Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:segctord state:D stack:23456 pid:5067 ppid:2\n flags:0x00004000\n Call Trace:\n \u0026lt;TASK\u0026gt;\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x1409/0x43f0 kernel/sched/core.c:6606\n schedule+0xc3/0x190 kernel/sched/core.c:6682\n rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190\n nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]\n nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570\n kthread+0x270/0x300 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n folio_mark_accessed+0x51c/0xf00 mm/swap.c:515\n __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]\n nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61\n nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121\n nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176\n nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251\n nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]\n nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]\n nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777\n nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422\n nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]\n nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301\n ...\r\n\r\nThis fixes these issues by inserting appropriate minimum device size\nchecks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/IPoIB: Fix legacy IPoIB due to wrong number of queues\r\n\r\nThe cited commit creates child PKEY interfaces over netlink will\nmultiple tx and rx queues, but some devices doesn\u0026apos;t support more than 1\ntx and 1 rx queues. This causes to a crash when traffic is sent over the\nPKEY interface due to the parent having a single queue but the child\nhaving multiple queues.\r\n\r\nThis patch fixes the number of queues to 1 for legacy IPoIB at the\nearliest possible point in time.\r\n\r\nBUG: kernel NULL pointer dereference, address: 000000000000036b\nPGD 0 P4D 0\nOops: 0000 [#1] SMP\nCPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kmem_cache_alloc+0xcb/0x450\nCode: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a\n01 49 8b 3c 24 \u0026lt;49\u0026gt; 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b\nRSP: 0018:ffff88822acbbab8 EFLAGS: 00010202\nRAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae\nRDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00\nRBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40\nR10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000\nR13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000\nFS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_clone+0x55/0xd0\n ip6_finish_output2+0x3fe/0x690\n ip6_finish_output+0xfa/0x310\n ip6_send_skb+0x1e/0x60\n udp_v6_send_skb+0x1e5/0x420\n udpv6_sendmsg+0xb3c/0xe60\n ? ip_mc_finish_output+0x180/0x180\n ? __switch_to_asm+0x3a/0x60\n ? __switch_to_asm+0x34/0x60\n sock_sendmsg+0x33/0x40\n __sys_sendto+0x103/0x160\n ? _copy_to_user+0x21/0x30\n ? kvm_clock_get_cycles+0xd/0x10\n ? ktime_get_ts64+0x49/0xe0\n __x64_sys_sendto+0x25/0x30\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7f9374f1ed14\nCode: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b\n7c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b\nRSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14\nRDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030\nRBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc\n \u0026lt;/TASK\u0026gt;(CVE-2023-52745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()\r\n\r\n int type = nla_type(nla);\r\n\r\n if (type \u0026gt; XFRMA_MAX) {\n return -EOPNOTSUPP;\n }\r\n\r\n@type is then used as an array index and can be used\nas a Spectre v1 gadget.\r\n\r\n if (nla_len(nla) \u0026lt; compat_policy[type].len) {\r\n\r\narray_index_nospec() can be used to prevent leaking\ncontent of kernel memory to malicious users.(CVE-2023-52746)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid NULL dereference of timing generator\r\n\r\n[Why \u0026amp; How]\nCheck whether assigned timing generator is NULL or not before\naccessing its funcs to prevent NULL dereference.(CVE-2023-52753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: avoid data corruption caused by decline\r\n\r\nWe found a data corruption issue during testing of SMC-R on Redis\napplications.\r\n\r\nThe benchmark has a low probability of reporting a strange error as\nshown below.\r\n\r\n\u0026quot;Error: Protocol error, got \u0026quot;\\xe2\u0026quot; as reply type byte\u0026quot;\r\n\r\nFinally, we found that the retrieved error data was as follows:\r\n\r\n0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C\n0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2\r\n\r\nIt is quite obvious that this is a SMC DECLINE message, which means that\nthe applications received SMC protocol message.\nWe found that this was caused by the following situations:\r\n\r\nclient server\n \u00a6 clc proposal\n -------------\u0026gt;\n \u00a6 clc accept\n \u0026lt;-------------\n \u00a6 clc confirm\n -------------\u0026gt;\nwait llc confirm\n\t\t\tsend llc confirm\n \u00a6failed llc confirm\n \u00a6 x------\n(after 2s)timeout\n wait llc confirm rsp\r\n\r\nwait decline\r\n\r\n(after 1s) timeout\n (after 2s) timeout\n \u00a6 decline\n --------------\u0026gt;\n \u00a6 decline\n \u0026lt;--------------\r\n\r\nAs a result, a decline message was sent in the implementation, and this\nmessage was read from TCP by the already-fallback connection.\r\n\r\nThis patch double the client timeout as 2x of the server value,\nWith this simple change, the Decline messages should never cross or\ncollide (during Confirm link timeout).\r\n\r\nThis issue requires an immediate solution, since the protocol updates\ninvolve a more long-term solution.(CVE-2023-52775)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: add ipvlan_route_v6_outbound() helper\r\n\r\nInspired by syzbot reports using a stack of multiple ipvlan devices.\r\n\r\nReduce stack size needed in ipvlan_process_v6_outbound() by moving\nthe flowi6 struct used for the route lookup in an non inlined\nhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,\nimmediately reclaimed.\r\n\r\nAlso make sure ipvlan_process_v4_outbound() is not inlined.\r\n\r\nWe might also have to lower MAX_NEST_DEV, because only syzbot uses\nsetups with more than four stacked devices.\r\n\r\nBUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)\nstack guard page: 0000 [#1] SMP KASAN\nCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nRIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188\nCode: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 \u0026lt;41\u0026gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89\nRSP: 0018:ffffc9000e804000 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2\nRDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568\nRBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c\nR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000\nFS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;#DF\u0026gt;\n\u0026lt;/#DF\u0026gt;\n\u0026lt;TASK\u0026gt;\n[\u0026lt;ffffffff81f281d1\u0026gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n[\u0026lt;ffffffff817e5bf2\u0026gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpu_online include/linux/cpumask.h:1092 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632\n[\u0026lt;ffffffff8563221e\u0026gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306\n[\u0026lt;ffffffff8561464d\u0026gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]\n[\u0026lt;ffffffff8561464d\u0026gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221\n[\u0026lt;ffffffff85618120\u0026gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606\n[\u0026lt;ffffffff856f65b5\u0026gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]\n[\u0026lt;ffffffff856f65b5\u0026gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116\n[\u0026lt;ffffffff85618009\u0026gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638\n[\u0026lt;ffffffff8561821a\u0026gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ip6_route_output include/net/ip6_route.h:100 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677\n[\u0026lt;ffffffff838c2909\u0026gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229\n[\u0026lt;ffffffff84d03900\u0026gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] xmit_one net/core/dev.c:3644 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660\n[\u0026lt;ffffffff84d080e2\u0026gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[\u0026lt;ffffffff855ce4cd\u0026gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]\n[\u0026lt;ffffffff855ce4cd\u0026gt;] neigh_hh_output include/net/neighbour.h:529 [inline]\n[\u0026lt;f\n---truncated---(CVE-2023-52796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix dfs radar event locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the DFS radar event\nhandling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbFindLeaf\r\n\r\nCurrently while searching for dmtree_t for sufficient free blocks there\nis an array out of bounds while getting element in tp-\u0026gt;dm_stree. To add\nthe required check for out of bound we first need to determine the type\nof dmtree. Thus added an extra parameter to dbFindLeaf so that the type\nof tree can be determined and the required check can be applied.(CVE-2023-52799)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix htt pktlog locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the htt pktlog handling\ncode calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52800)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix RPC client cleaned up the freed pipefs dentries\r\n\r\nRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()\nworkqueue,which takes care about pipefs superblock locking.\nIn some special scenarios, when kernel frees the pipefs sb of the\ncurrent client and immediately alloctes a new pipefs sb,\nrpc_remove_pipedir function would misjudge the existence of pipefs\nsb which is not the one it used to hold. As a result,\nthe rpc_remove_pipedir would clean the released freed pipefs dentries.\r\n\r\nTo fix this issue, rpc_remove_pipedir should check whether the\ncurrent pipefs sb is consistent with the original pipefs sb.\r\n\r\nThis error can be catched by KASAN:\n=========================================================\n[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200\n[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503\n[ 250.500549] Workqueue: events rpc_free_client_work\n[ 250.501001] Call Trace:\n[ 250.502880] kasan_report+0xb6/0xf0\n[ 250.503209] ? dget_parent+0x195/0x200\n[ 250.503561] dget_parent+0x195/0x200\n[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10\n[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90\n[ 250.504781] rpc_remove_client_dir+0xf5/0x150\n[ 250.505195] rpc_free_client_work+0xe4/0x230\n[ 250.505598] process_one_work+0x8ee/0x13b0\n...\n[ 22.039056] Allocated by task 244:\n[ 22.039390] kasan_save_stack+0x22/0x50\n[ 22.039758] kasan_set_track+0x25/0x30\n[ 22.040109] __kasan_slab_alloc+0x59/0x70\n[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240\n[ 22.040889] __d_alloc+0x31/0x8e0\n[ 22.041207] d_alloc+0x44/0x1f0\n[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140\n[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110\n[ 22.042459] rpc_create_client_dir+0x34/0x150\n[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0\n[ 22.043284] rpc_client_register+0x136/0x4e0\n[ 22.043689] rpc_new_client+0x911/0x1020\n[ 22.044057] rpc_create_xprt+0xcb/0x370\n[ 22.044417] rpc_create+0x36b/0x6c0\n...\n[ 22.049524] Freed by task 0:\n[ 22.049803] kasan_save_stack+0x22/0x50\n[ 22.050165] kasan_set_track+0x25/0x30\n[ 22.050520] kasan_save_free_info+0x2b/0x50\n[ 22.050921] __kasan_slab_free+0x10e/0x1a0\n[ 22.051306] kmem_cache_free+0xa5/0x390\n[ 22.051667] rcu_core+0x62c/0x1930\n[ 22.051995] __do_softirq+0x165/0x52a\n[ 22.052347]\n[ 22.052503] Last potentially related work creation:\n[ 22.052952] kasan_save_stack+0x22/0x50\n[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0\n[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0\n[ 22.054209] dentry_free+0xb2/0x140\n[ 22.054540] __dentry_kill+0x3be/0x540\n[ 22.054900] shrink_dentry_list+0x199/0x510\n[ 22.055293] shrink_dcache_parent+0x190/0x240\n[ 22.055703] do_one_tree+0x11/0x40\n[ 22.056028] shrink_dcache_for_umount+0x61/0x140\n[ 22.056461] generic_shutdown_super+0x70/0x590\n[ 22.056879] kill_anon_super+0x3a/0x60\n[ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs\r\n\r\nThe hns3 driver define an array of string to show the coalesce\ninfo, but if the kernel adds a new mode or a new state,\nout-of-bounds access may occur when coalesce info is read via\ndebugfs, this patch fix the problem.(CVE-2023-52807)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxen-netfront: Add missing skb_mark_for_recycle\r\n\r\nNotice that skb_mark_for_recycle() is introduced later than fixes tag in\ncommit 6a5bcd84e886 (\u0026quot;page_pool: Allow drivers to hint on SKB recycling\u0026quot;).\r\n\r\nIt is believed that fixes tag were missing a call to page_pool_release_page()\nbetween v5.9 to v5.14, after which is should have used skb_mark_for_recycle().\nSince v6.6 the call page_pool_release_page() were removed (in\ncommit 535b9c61bdef (\u0026quot;net: page_pool: hide page_pool_release_page()\u0026quot;)\nand remaining callers converted (in commit 6bfef2ec0172 (\u0026quot;Merge branch\n\u0026apos;net-page_pool-remove-page_pool_release_page\u0026apos;\u0026quot;)).\r\n\r\nThis leak became visible in v6.8 via commit dba1b8a7ab68 (\u0026quot;mm/page_pool: catch\npage_pool memory leaks\u0026quot;).(CVE-2024-27393)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout\r\n\r\nThere is a race condition between l2cap_chan_timeout() and\nl2cap_chan_del(). When we use l2cap_chan_del() to delete the\nchannel, the chan-\u0026gt;conn will be set to null. But the conn could\nbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().\nAs a result the null pointer dereference bug will happen. The\nKASAN report triggered by POC is shown below:\r\n\r\n[ 472.074580] ==================================================================\n[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0\n[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7\n[ 472.075308]\n[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.075308] Workqueue: events l2cap_chan_timeout\n[ 472.075308] Call Trace:\n[ 472.075308] \u0026lt;TASK\u0026gt;\n[ 472.075308] dump_stack_lvl+0x137/0x1a0\n[ 472.075308] print_report+0x101/0x250\n[ 472.075308] ? __virt_addr_valid+0x77/0x160\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_report+0x139/0x170\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_check_range+0x2c3/0x2e0\n[ 472.075308] mutex_lock+0x68/0xc0\n[ 472.075308] l2cap_chan_timeout+0x181/0x300\n[ 472.075308] process_one_work+0x5d2/0xe00\n[ 472.075308] worker_thread+0xe1d/0x1660\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] kthread+0x2b7/0x350\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork+0x4d/0x80\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork_asm+0x11/0x20\n[ 472.075308] \u0026lt;/TASK\u0026gt;\n[ 472.075308] ==================================================================\n[ 472.094860] Disabling lock debugging due to kernel taint\n[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158\n[ 472.096136] #PF: supervisor write access in kernel mode\n[ 472.096136] #PF: error_code(0x0002) - not-present page\n[ 472.096136] PGD 0 P4D 0\n[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI\n[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.096136] Workqueue: events l2cap_chan_timeout\n[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0\n[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88\n[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246\n[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865\n[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78\n[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f\n[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000\n[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00\n[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000\n[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0\n[ 472.096136] Call Trace:\n[ 472.096136] \u0026lt;TASK\u0026gt;\n[ 472.096136] ? __die_body+0x8d/0xe0\n[ 472.096136] ? page_fault_oops+0x6b8/0x9a0\n[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0\n[ 472.096136] ? do_user_addr_fault+0x1027/0x1340\n[ 472.096136] ? _printk+0x7a/0xa0\n[ 472.096136] ? mutex_lock+0x68/0xc0\n[ 472.096136] ? add_taint+0x42/0xd0\n[ 472.096136] ? exc_page_fault+0x6a/0x1b0\n[ 472.096136] ? asm_exc_page_fault+0x26/0x30\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] ? mutex_lock+0x88/0xc0\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] l2cap_chan_timeo\n---truncated---(CVE-2024-27399)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: fix racy skb_queue_empty() use\r\n\r\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: confirm multicast packets before passing them up the stack\r\n\r\nconntrack nf_confirm logic cannot handle cloned skbs referencing\nthe same nf_conn entry, which will happen for multicast (broadcast)\nframes on bridges.\r\n\r\n Example:\n macvlan0\n |\n br0\n / \\\n ethX ethY\r\n\r\n ethX (or Y) receives a L2 multicast or broadcast packet containing\n an IP packet, flow is not yet in conntrack table.\r\n\r\n 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.\n -\u0026gt; skb-\u0026gt;_nfct now references a unconfirmed entry\n 2. skb is broad/mcast packet. bridge now passes clones out on each bridge\n interface.\n 3. skb gets passed up the stack.\n 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb\n and schedules a work queue to send them out on the lower devices.\r\n\r\n The clone skb-\u0026gt;_nfct is not a copy, it is the same entry as the\n original skb. The macvlan rx handler then returns RX_HANDLER_PASS.\n 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.\r\n\r\nThe Macvlan broadcast worker and normal confirm path will race.\r\n\r\nThis race will not happen if step 2 already confirmed a clone. In that\ncase later steps perform skb_clone() with skb-\u0026gt;_nfct already confirmed (in\nhash table). This works fine.\r\n\r\nBut such confirmation won\u0026apos;t happen when eb/ip/nftables rules dropped the\npackets before they reached the nf_confirm step in postrouting.\r\n\r\nPablo points out that nf_conntrack_bridge doesn\u0026apos;t allow use of stateful\nnat, so we can safely discard the nf_conn entry and let inet call\nconntrack again.\r\n\r\nThis doesn\u0026apos;t work for bridge netfilter: skb could have a nat\ntransformation. Also bridge nf prevents re-invocation of inet prerouting\nvia \u0026apos;sabotage_in\u0026apos; hook.\r\n\r\nWork around this problem by explicit confirmation of the entry at LOCAL_IN\ntime, before upper layer has a chance to clone the unconfirmed entry.\r\n\r\nThe downside is that this disables NAT and conntrack helpers.\r\n\r\nAlternative fix would be to add locking to all code parts that deal with\nunconfirmed packets, but even if that could be done in a sane way this\nopens up other problems, for example:\r\n\r\n-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4\n-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5\r\n\r\nFor multicast case, only one of such conflicting mappings will be\ncreated, conntrack only handles 1:1 NAT mappings.\r\n\r\nUsers should set create a setup that explicitly marks such traffic\nNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass\nthem, ruleset might have accept rules for untracked traffic already,\nso user-visible behaviour would change.(CVE-2024-27415)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: altmodes/displayport: create sysfs nodes as driver\u0026apos;s default device attribute group\r\n\r\nThe DisplayPort driver\u0026apos;s sysfs nodes may be present to the userspace before\ntypec_altmode_set_drvdata() completes in dp_altmode_probe. This means that\na sysfs read can trigger a NULL pointer error by deferencing dp-\u0026gt;hpd in\nhpd_show or dp-\u0026gt;lock in pin_assignment_show, as dev_get_drvdata() returns\nNULL in those cases.\r\n\r\nRemove manual sysfs node creation in favor of adding attribute group as\ndefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is\nnot used here otherwise the path to the sysfs nodes is no longer compliant\nwith the ABI.(CVE-2024-35790)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/PM: Drain runtime-idle callbacks before driver removal\r\n\r\nA race condition between the .runtime_idle() callback and the .remove()\ncallback in the rtsx_pcr PCI driver leads to a kernel crash due to an\nunhandled page fault [1].\r\n\r\nThe problem is that rtsx_pci_runtime_idle() is not expected to be running\nafter pm_runtime_get_sync() has been called, but the latter doesn\u0026apos;t really\nguarantee that. It only guarantees that the suspend and resume callbacks\nwill not be running when it returns.\r\n\r\nHowever, if a .runtime_idle() callback is already running when\npm_runtime_get_sync() is called, the latter will notice that the runtime PM\nstatus of the device is RPM_ACTIVE and it will return right away without\nwaiting for the former to complete. In fact, it cannot wait for\n.runtime_idle() to complete because it may be called from that callback (it\narguably does not make much sense to do that, but it is not strictly\nprohibited).\r\n\r\nThus in general, whoever is providing a .runtime_idle() callback needs\nto protect it from running in parallel with whatever code runs after\npm_runtime_get_sync(). [Note that .runtime_idle() will not start after\npm_runtime_get_sync() has returned, but it may continue running then if it\nhas started earlier.]\r\n\r\nOne way to address that race condition is to call pm_runtime_barrier()\nafter pm_runtime_get_sync() (not before it, because a nonzero value of the\nruntime PM usage counter is necessary to prevent runtime PM callbacks from\nbeing invoked) to wait for the .runtime_idle() callback to complete should\nit be running at that point. A suitable place for doing that is in\npci_device_remove() which calls pm_runtime_get_sync() before removing the\ndriver, so it may as well call pm_runtime_barrier() subsequently, which\nwill prevent the race in question from occurring, not just in the rtsx_pcr\ndriver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix memory leak during rehash\r\n\r\nThe rehash delayed work migrates filters from one region to another.\nThis is done by iterating over all chunks (all the filters with the same\npriority) in the region and in each chunk iterating over all the\nfilters.\r\n\r\nIf the migration fails, the code tries to migrate the filters back to\nthe old region. However, the rollback itself can also fail in which case\nanother migration will be erroneously performed. Besides the fact that\nthis ping pong is not a very good idea, it also creates a problem.\r\n\r\nEach virtual chunk references two chunks: The currently used one\n(\u0026apos;vchunk-\u0026gt;chunk\u0026apos;) and a backup (\u0026apos;vchunk-\u0026gt;chunk2\u0026apos;). During migration the\nfirst holds the chunk we want to migrate filters to and the second holds\nthe chunk we are migrating filters from.\r\n\r\nThe code currently assumes - but does not verify - that the backup chunk\ndoes not exist (NULL) if the currently used chunk does not reference the\ntarget region. This assumption breaks when we are trying to rollback a\nrollback, resulting in the backup chunk being overwritten and leaked\n[1].\r\n\r\nFix by not rolling back a failed rollback and add a warning to avoid\nfuture cases.\r\n\r\n[1]\nWARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20\nModules linked in:\nCPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:parman_destroy+0x17/0x20\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_region_fini+0x19/0x60\n mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash\r\n\r\nThe rehash delayed work migrates filters from one region to another\naccording to the number of available credits.\r\n\r\nThe migrated from region is destroyed at the end of the work if the\nnumber of credits is non-negative as the assumption is that this is\nindicative of migration being complete. This assumption is incorrect as\na non-negative number of credits can also be the result of a failed\nmigration.\r\n\r\nThe destruction of a region that still has filters referencing it can\nresult in a use-after-free [1].\r\n\r\nFix by not destroying the region if migration failed.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230\nRead of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858\r\n\r\nCPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230\n mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70\n mlxsw_sp_acl_atcam_entry_del+0x81/0x210\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 174:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc+0x19c/0x360\n mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\r\n\r\nFreed by task 7:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xc1/0x290\n mlxsw_sp_acl_tcam_region_destroy+0x272/0x310\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30(CVE-2024-35854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update\r\n\r\nThe rule activity update delayed work periodically traverses the list of\nconfigured rules and queries their activity from the device.\r\n\r\nAs part of this task it accesses the entry pointed by \u0026apos;ventry-\u0026gt;entry\u0026apos;,\nbut this entry can be changed concurrently by the rehash delayed work,\nleading to a use-after-free [1].\r\n\r\nFix by closing the race and perform the activity query under the\n\u0026apos;vregion-\u0026gt;lock\u0026apos; mutex.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\nRead of size 8 at addr ffff8881054ed808 by task kworker/0:18/181\r\n\r\nCPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\n mlxsw_sp_acl_rule_activity_update_work+0x219/0x400\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc+0x19c/0x360\n mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\r\n\r\nFreed by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xc1/0x290\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\r\n\r\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerspan: make sure erspan_base_hdr is present in skb-\u0026gt;head\r\n\r\nsyzbot reported a problem in ip6erspan_rcv() [1]\r\n\r\nIssue is that ip6erspan_rcv() (and erspan_rcv()) no longer make\nsure erspan_base_hdr is present in skb linear part (skb-\u0026gt;head)\nbefore getting @ver field from it.\r\n\r\nAdd the missing pskb_may_pull() calls.\r\n\r\nv2: Reload iph pointer in erspan_rcv() after pskb_may_pull()\n because skb-\u0026gt;head might have changed.\r\n\r\n[1]\r\n\r\n BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]\n BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n pskb_may_pull include/linux/skbuff.h:2756 [inline]\n ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:460 [inline]\n ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5538 [inline]\n __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652\n netif_receive_skb_internal net/core/dev.c:5738 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5798\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549\n tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 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 __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1318 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n tun_alloc_skb drivers/net/tun.c:1525 [inline]\n tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 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 __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, sockmap: Prevent lock inversion deadlock in map delete elem\r\n\r\nsyzkaller started using corpuses where a BPF tracing program deletes\nelements from a sockmap/sockhash map. Because BPF tracing programs can be\ninvoked from any interrupt context, locks taken during a map_delete_elem\noperation must be hardirq-safe. Otherwise a deadlock due to lock inversion\nis possible, as reported by lockdep:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;htab-\u0026gt;buckets[i].lock);\n local_irq_disable();\n lock(\u0026amp;host-\u0026gt;lock);\n lock(\u0026amp;htab-\u0026gt;buckets[i].lock);\n \u0026lt;Interrupt\u0026gt;\n lock(\u0026amp;host-\u0026gt;lock);\r\n\r\nLocks in sockmap are hardirq-unsafe by design. We expects elements to be\ndeleted from sockmap/sockhash only in task (normal) context with interrupts\nenabled, or in softirq context.\r\n\r\nDetect when map_delete_elem operation is invoked from a context which is\n_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an\nerror.\r\n\r\nNote that map updates are not affected by this issue. BPF verifier does not\nallow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: validate user input for expected length\r\n\r\nI got multiple syzbot reports showing old bugs exposed\nby BPF after commit 20f2505fb436 (\u0026quot;bpf: Try to avoid kzalloc\nin cgroup/{s,g}etsockopt\u0026quot;)\r\n\r\nsetsockopt() @optlen argument should be taken into account\nbefore copying data.\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\nRead of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238\r\n\r\nCPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\n nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\nRIP: 0033:0x7fd22067dde9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7238:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:4069 [inline]\n __kmalloc_noprof+0x200/0x410 mm/slub.c:4082\n kmalloc_noprof include/linux/slab.h:664 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\r\n\r\nThe buggy address belongs to the object at ffff88802cd73da0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes inside of\n allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)\r\n\r\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73\nflags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)\npage_type: 0xffffefff(slab)\nraw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122\nraw: ffff88802cd73020 000000008080007f 00000001ffffefff 00\n---truncated---(CVE-2024-35896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Protect against int overflow for stack access size\r\n\r\nThis patch re-introduces protection against the size of access to stack\nmemory being negative; the access size can appear negative as a result\nof overflowing its signed int representation. This should not actually\nhappen, as there are other protections along the way, but we should\nprotect against it anyway. One code path was missing such protections\n(fixed in the previous patch in the series), causing out-of-bounds array\naccesses in check_stack_range_initialized(). This patch causes the\nverification of a program with such a non-sensical access size to fail.\r\n\r\nThis check used to exist in a more indirect way, but was inadvertendly\nremoved in a833a17aeac7.(CVE-2024-35905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\r\n\r\nsyzbot reported the following uninit-value access issue [1][2]:\r\n\r\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\r\n\r\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.(CVE-2024-35915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Limit read size on v1.2\r\n\r\nBetween UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was\nincreased from 16 to 256. In order to avoid overflowing reads for older\nsystems, add a mechanism to use the read UCSI version to truncate read\nsizes on UCSI v1.2.(CVE-2024-35924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: prevent division by zero in blk_rq_stat_sum()\r\n\r\nThe expression dst-\u0026gt;nr_samples + src-\u0026gt;nr_samples may\nhave zero value on overflow. It is necessary to add\na check to avoid division by zero.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: SCO: Fix not validating setsockopt user input\r\n\r\nsyzbot reported sco_sock_setsockopt() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90\nnet/bluetooth/sco.c:893\nRead of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngeneve: fix header validation in geneve[6]_xmit_skb\r\n\r\nsyzbot is able to trigger an uninit-value in geneve_xmit() [1]\r\n\r\nProblem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())\nuses skb_protocol(skb, true), pskb_inet_may_pull() is only using\nskb-\u0026gt;protocol.\r\n\r\nIf anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-\u0026gt;protocol,\npskb_inet_may_pull() does nothing at all.\r\n\r\nIf a vlan tag was provided by the caller (af_packet in the syzbot case),\nthe network header might not point to the correct location, and skb\nlinear part could be smaller than expected.\r\n\r\nAdd skb_vlan_inet_prepare() to perform a complete mac validation.\r\n\r\nUse this in geneve for the moment, I suspect we need to adopt this\nmore broadly.\r\n\r\nv4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest\n - Only call __vlan_get_protocol() for vlan types.\r\n\r\nv2,v3 - Addressed Sabrina comments on v1 and v2\r\n\r\n[1]\r\n\r\nBUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113\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:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1318 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n packet_snd net/packet/af_packet.c:3024 [inline]\n packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113\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:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv4: check for NULL idev in ip_route_use_hint()\r\n\r\nsyzbot was able to trigger a NULL deref in fib_validate_source()\nin an old tree [1].\r\n\r\nIt appears the bug exists in latest trees.\r\n\r\nAll calls to __in_dev_get_rcu() must be checked for a NULL result.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425\nCode: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf\nRSP: 0018:ffffc900015fee40 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0\nRDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0\nRBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000\nR10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000\nFS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231\n ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327\n ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]\n ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638\n ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673\n __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]\n __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620\n __netif_receive_skb_list net/core/dev.c:5672 [inline]\n netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764\n netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816\n xdp_recv_frames net/bpf/test_run.c:257 [inline]\n xdp_test_run_batch net/bpf/test_run.c:335 [inline]\n bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363\n bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376\n bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736\n __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115\n __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\r\n\r\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when devlink reload during pf initialization\r\n\r\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdhci-msm: pervent access to suspended controller\r\n\r\nGeneric sdhci code registers LED device and uses host-\u0026gt;runtime_suspended\nflag to protect access to it. The sdhci-msm driver doesn\u0026apos;t set this flag,\nwhich causes a crash when LED is accessed while controller is runtime\nsuspended. Fix this by setting the flag correctly.(CVE-2024-36029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix out-of-bounds access in ops_init\r\n\r\nnet_alloc_generic is called by net_alloc, which is called without any\nlocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It\nis read twice, first to allocate an array, then to set s.len, which is\nlater used to limit the bounds of the array access.\r\n\r\nIt is possible that the array is allocated and another thread is\nregistering a new pernet ops, increments max_gen_ptrs, which is then used\nto set s.len with a larger than allocated length for the variable array.\r\n\r\nFix it by reading max_gen_ptrs only once in net_alloc_generic. If\nmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix UAF in error path\r\n\r\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\r\n\r\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\r\n\r\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack linux/lib/dump_stack.c:88\n dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\n print_address_description linux/mm/kasan/report.c:377\n print_report+0xc4/0x620 linux/mm/kasan/report.c:488\n kasan_report+0xda/0x110 linux/mm/kasan/report.c:601\n kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\n skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\n skb_release_all linux/net/core/skbuff.c:1094\n __kfree_skb linux/net/core/skbuff.c:1108\n kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\n kfree_skb linux/./include/linux/skbuff.h:1244\n tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\n tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\n tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\n tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\n tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\n udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\n ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\n dst_input linux/./include/net/dst.h:461\n ip_rcv_finish linux/net/ipv4/ip_input.c:449\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\n process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\n napi_poll linux/net/core/dev.c:6645\n net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\n do_softirq linux/kernel/softirq.c:454\n do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\n local_bh_enable linux/./include/linux/bottom_half.h:33\n rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\n dev_queue_xmit linux/./include/linux/netdevice.h:3169\n neigh_hh_output linux/./include/net/neighbour.h:526\n neigh_output linux/./include/net/neighbour.h:540\n ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n __ip_finish_output linux/net/ipv4/ip_output.c:313\n __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\n NF_HOOK_COND linux/./include/linux/netfilter.h:303\n ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\n dst_output linux/./include/net/dst.h:451\n ip_local_out linux/net/ipv4/ip_output.c:129\n ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\n udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\n udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\n inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\n sock_sendmsg_nosec linux/net/socket.c:730\n __sock_sendmsg linux/net/socket.c:745\n __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n __do_sys_sendto linux/net/socket.c:2203\n __se_sys_sendto linux/net/socket.c:2199\n __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\n do_syscall_x64 linux/arch/x86/entry/common.c:52\n do_syscall_\n---truncated---(CVE-2024-36886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_nxt is properly initialized on connect\r\n\r\nChristoph reported a splat hinting at a corrupted snd_una:\r\n\r\n WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n Modules linked in:\n CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n Workqueue: events mptcp_worker\n RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8\n \t8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe\n \t\u0026lt;0f\u0026gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9\n RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293\n RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4\n RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000\n R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000\n FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]\n mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]\n __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615\n mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767\n process_one_work+0x1e0/0x560 kernel/workqueue.c:3254\n process_scheduled_works kernel/workqueue.c:3335 [inline]\n worker_thread+0x3c7/0x640 kernel/workqueue.c:3416\n kthread+0x121/0x170 kernel/kthread.c:388\n ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n \u0026lt;/TASK\u0026gt;\r\n\r\nWhen fallback to TCP happens early on a client socket, snd_nxt\nis not yet initialized and any incoming ack will copy such value\ninto snd_una. If the mptcp worker (dumbly) tries mptcp-level\nre-injection after such ack, that would unconditionally trigger a send\nbuffer cleanup using \u0026apos;bad\u0026apos; snd_una values.\r\n\r\nWe could easily disable re-injection for fallback sockets, but such\ndumb behavior already helped catching a few subtle issues and a very\nlow to zero impact in practice.\r\n\r\nInstead address the issue always initializing snd_nxt (and write_seq,\nfor consistency) at connect time.(CVE-2024-36889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: fix uninitialised kfifo\r\n\r\nIf a line is requested with debounce, and that results in debouncing\nin software, and the line is subsequently reconfigured to enable edge\ndetection then the allocation of the kfifo to contain edge events is\noverlooked. This results in events being written to and read from an\nuninitialised kfifo. Read events are returned to userspace.\r\n\r\nInitialise the kfifo in the case where the software debounce is\nalready active.(CVE-2024-36898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: Fix use after free in lineinfo_changed_notify\r\n\r\nThe use-after-free issue occurs as follows: when the GPIO chip device file\nis being closed by invoking gpio_chrdev_release(), watched_lines is freed\nby bitmap_free(), but the unregistration of lineinfo_changed_nb notifier\nchain failed due to waiting write rwsem. Additionally, one of the GPIO\nchip\u0026apos;s lines is also in the release process and holds the notifier chain\u0026apos;s\nread rwsem. Consequently, a race condition leads to the use-after-free of\nwatched_lines.\r\n\r\nHere is the typical stack when issue happened:\r\n\r\n[free]\ngpio_chrdev_release()\n --\u0026gt; bitmap_free(cdev-\u0026gt;watched_lines) \u0026lt;-- freed\n --\u0026gt; blocking_notifier_chain_unregister()\n --\u0026gt; down_write(\u0026amp;nh-\u0026gt;rwsem) \u0026lt;-- waiting rwsem\n --\u0026gt; __down_write_common()\n --\u0026gt; rwsem_down_write_slowpath()\n --\u0026gt; schedule_preempt_disabled()\n --\u0026gt; schedule()\r\n\r\n[use]\nst54spi_gpio_dev_release()\n --\u0026gt; gpio_free()\n --\u0026gt; gpiod_free()\n --\u0026gt; gpiod_free_commit()\n --\u0026gt; gpiod_line_state_notify()\n --\u0026gt; blocking_notifier_call_chain()\n --\u0026gt; down_read(\u0026amp;nh-\u0026gt;rwsem); \u0026lt;-- held rwsem\n --\u0026gt; notifier_call_chain()\n --\u0026gt; lineinfo_changed_notify()\n --\u0026gt; test_bit(xxxx, cdev-\u0026gt;watched_lines) \u0026lt;-- use after free\r\n\r\nThe side effect of the use-after-free issue is that a GPIO line event is\nbeing generated for userspace where it shouldn\u0026apos;t. However, since the chrdev\nis being closed, userspace won\u0026apos;t have the chance to read that event anyway.\r\n\r\nTo fix the issue, call the bitmap_free() function after the unregistration\nof lineinfo_changed_nb notifier chain.(CVE-2024-36899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()\r\n\r\nsyzbot is able to trigger the following crash [1],\ncaused by unsafe ip6_dst_idev() use.\r\n\r\nIndeed ip6_dst_idev() can return NULL, and must always be checked.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]\n RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267\nCode: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c\nRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700\nRDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760\nRBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd\nR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000\nR13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00\nFS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317\n fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108\n ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]\n ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649\n ip6_route_output include/net/ip6_route.h:93 [inline]\n ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120\n ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250\n sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326\n sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455\n sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662\n sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099\n __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n TCP_CLOSE\nconnect()\n TCP_SYN_SENT\n TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1068\n ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9381/1: kasan: clear stale stack poison\r\n\r\nWe found below OOB crash:\r\n\r\n[ 33.452494] ==================================================================\n[ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec\n[ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0\n[ 33.455515]\n[ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1\n[ 33.456880] Hardware name: Generic DT based system\n[ 33.457555] unwind_backtrace from show_stack+0x18/0x1c\n[ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c\n[ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4\n[ 33.459863] print_report from kasan_report+0x9c/0x148\n[ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0\n[ 33.461424] kasan_check_range from memset+0x20/0x3c\n[ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec\n[ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c\n[ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354\n[ 33.465029] do_idle from cpu_startup_entry+0x20/0x24\n[ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4\n[ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18\n[ 33.467397]\n[ 33.467644] The buggy address belongs to stack of task swapper/0/0\n[ 33.468493] and is located at offset 112 in frame:\n[ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec\n[ 33.469917]\n[ 33.470165] This frame has 2 objects:\n[ 33.470696] [32, 76) \u0026apos;global_zone_diff\u0026apos;\n[ 33.470729] [112, 276) \u0026apos;global_node_diff\u0026apos;\n[ 33.471294]\n[ 33.472095] The buggy address belongs to the physical page:\n[ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03\n[ 33.473944] flags: 0x1000(reserved|zone=0)\n[ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001\n[ 33.475656] raw: 00000000\n[ 33.476050] page dumped because: kasan: bad access detected\n[ 33.476816]\n[ 33.477061] Memory state around the buggy address:\n[ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00\n[ 33.479526] \u0026gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1\n[ 33.480415] ^\n[ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3\n[ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00\n[ 33.482978] ==================================================================\r\n\r\nWe find the root cause of this OOB is that arm does not clear stale stack\npoison in the case of cpuidle.\r\n\r\nThis patch refer to arch/arm64/kernel/sleep.S to resolve this issue.\r\n\r\nFrom cited commit [1] that explain the problem\r\n\r\nFunctions which the compiler has instrumented for KASAN place poison on\nthe stack shadow upon entry and remove this poison prior to returning.\r\n\r\nIn the case of cpuidle, CPUs exit the kernel a number of levels deep in\nC code. Any instrumented functions on this critical path will leave\nportions of the stack shadow poisoned.\r\n\r\nIf CPUs lose context and return to the kernel via a cold path, we\nrestore a prior context saved in __cpu_suspend_enter are forgotten, and\nwe never remove the poison they placed in the stack shadow area by\nfunctions calls between this and the actual exit of the kernel.\r\n\r\nThus, (depending on stackframe layout) subsequent calls to instrumented\nfunctions may hit this stale poison, resulting in (spurious) KASAN\nsplats to the console.\r\n\r\nTo avoid this, clear any stale poison from the idle thread for a CPU\nprior to bringing a CPU online.\r\n\r\nFrom cited commit [2]\r\n\r\nExtend to check for CONFIG_KASAN_STACK\r\n\r\n[1] commit 0d97e6d8024c (\u0026quot;arm64: kasan: clear stale stack poison\u0026quot;)\n[2] commit d56a9ef84bd0 (\u0026quot;kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK\u0026quot;)(CVE-2024-36906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: do not WARN if iocg was already offlined\r\n\r\nIn iocg_pay_debt(), warn is triggered if \u0026apos;active_list\u0026apos; is empty, which\nis intended to confirm iocg is active when it has debt. However, warn\ncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()\nis run at that time:\r\n\r\n WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190\n Call trace:\n iocg_pay_debt+0x14c/0x190\n iocg_kick_waitq+0x438/0x4c0\n iocg_waitq_timer_fn+0xd8/0x130\n __run_hrtimer+0x144/0x45c\n __hrtimer_run_queues+0x16c/0x244\n hrtimer_interrupt+0x2cc/0x7b0\r\n\r\nThe warn in this situation is meaningless. Since this iocg is being\nremoved, the state of the \u0026apos;active_list\u0026apos; is irrelevant, and \u0026apos;waitq_timer\u0026apos;\nis canceled after removing \u0026apos;active_list\u0026apos; in ioc_pd_free(), which ensures\niocg is freed after iocg_waitq_timer_fn() returns.\r\n\r\nTherefore, add the check if iocg was already offlined to avoid warn\nwhen removing a blkcg or disk.(CVE-2024-36908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()\r\n\r\nlpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the\nhbalock. Thus, lpfc_worker_wake_up() should not be called while holding the\nhbalock to avoid potential deadlock.(CVE-2024-36924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: core: reject skb_copy(_expand) for fraglist GSO skbs\r\n\r\nSKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become\ninvalid. Return NULL if such an skb is passed to skb_copy or\nskb_copy_expand, in order to prevent a crash on a potential later\ncall to skb_gso_segment.(CVE-2024-36929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namd/amdkfd: sync all devices to wait all processes being evicted\r\n\r\nIf there are more than one device doing reset in parallel, the first\ndevice will call kfd_suspend_all_processes() to evict all processes\non all devices, this call takes time to finish. other device will\nstart reset and recover without waiting. if the process has not been\nevicted before doing recover, it will be restored, then caused page\nfault.(CVE-2024-36949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocteontx2-af: avoid off-by-one read from userspace\r\n\r\nWe try to access count + 1 byte from userspace with memdup_user(buffer,\ncount + 1). However, the userspace only provides buffer of count bytes and\nonly these count bytes are verified to be okay to access. To ensure the\ncopied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: only translate RWX permissions for plain 9P2000\r\n\r\nGarbage in plain 9P2000\u0026apos;s perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.(CVE-2024-36964)",
"id": "OESA-2024-1706",
"modified": "2026-08-06T11:07:10Z",
"published": "2024-06-14T11:07:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52646"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52686"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52807"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27402"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35790"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47247",
"CVE-2021-47265",
"CVE-2021-47356",
"CVE-2021-47558",
"CVE-2022-48652",
"CVE-2023-52646",
"CVE-2023-52677",
"CVE-2023-52680",
"CVE-2023-52686",
"CVE-2023-52702",
"CVE-2023-52705",
"CVE-2023-52745",
"CVE-2023-52746",
"CVE-2023-52753",
"CVE-2023-52775",
"CVE-2023-52796",
"CVE-2023-52798",
"CVE-2023-52799",
"CVE-2023-52800",
"CVE-2023-52803",
"CVE-2023-52807",
"CVE-2023-52865",
"CVE-2023-52875",
"CVE-2024-27393",
"CVE-2024-27399",
"CVE-2024-27402",
"CVE-2024-27415",
"CVE-2024-35790",
"CVE-2024-35809",
"CVE-2024-35853",
"CVE-2024-35854",
"CVE-2024-35855",
"CVE-2024-35886",
"CVE-2024-35888",
"CVE-2024-35895",
"CVE-2024-35896",
"CVE-2024-35905",
"CVE-2024-35915",
"CVE-2024-35924",
"CVE-2024-35925",
"CVE-2024-35967",
"CVE-2024-35973",
"CVE-2024-36008",
"CVE-2024-36017",
"CVE-2024-36021",
"CVE-2024-36029",
"CVE-2024-36883",
"CVE-2024-36886",
"CVE-2024-36889",
"CVE-2024-36898",
"CVE-2024-36899",
"CVE-2024-36901",
"CVE-2024-36902",
"CVE-2024-36905",
"CVE-2024-36906",
"CVE-2024-36908",
"CVE-2024-36924",
"CVE-2024-36929",
"CVE-2024-36949",
"CVE-2024-36957",
"CVE-2024-36964"
]
}
OESA-2024-1738 (CVE-2021-47366)
Vulnerability from osv_openeuler – Published: 2024-06-21 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:
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.
This is a problem, however, since the file position and length fields of FS.FetchData are signed 32-bit values.
Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values.
This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.
Note that the issue does not exist with FS.StoreData - that uses unsigned 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.
This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client1. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like:
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
This can be observed in the server's FileLog with something like the following appearing:
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
Note the file position of 18446744071815340032. This is the requested file position sign-extended.(CVE-2021-47366)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Set scmnd->result only when scmnd is not NULL
This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally.
BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: <IRQ> __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] irq_poll_softirq+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/0xc0 </IRQ>(CVE-2022-48692)
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: virtio: Free driver_override when rpmsg_remove()
Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur:
unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: avoid format-overflow warning
With gcc and W=1 option, there's a warning like this:
fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’: fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between 1 and 7 bytes into a region of size between 5 and 8 [-Werror=format-overflow=] 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~
String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35". slab_name's size should be 35 rather than 32.(CVE-2023-52748)
In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Run atomic i2c xfer when !preemptible
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA).
panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c
Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: mux: Add check and kfree for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.(CVE-2023-52841)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52873)
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one element that share the same key.
This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.
The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).
Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.
v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):
usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.(CVE-2024-26935)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel1, the system crashed during some uio test with the following memory layout:
node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is:0xc0900000, 0x100000
the crash backtrace like:
Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception
So check if PG_reserved was set to solve this issue.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req().(CVE-2024-26954)
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: walk over current view on netlink dump
The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.
Based on patch from Florian Westphal.(CVE-2024-27017)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)
In the Linux kernel, the following vulnerability has been resolved:
net: ll_temac: platform_get_resource replaced by wrong function
The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name.
This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp.
if (type == resource_type(r) && !strcmp(r->name, name))
It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.(CVE-2024-35821)
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING.
To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc:
kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35870)
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below:
(Thread 1) | (Thread 2)
| ax25_ds_timeout()
ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE
In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.(CVE-2024-35887)
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.
For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.
It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue 1[2]:
nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.
This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: don't check if plane->state->fb == state->fb
Currently, when using non-blocking commits, we can see the following kernel warning:
[ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although prepare_fb and cleanup_fb are
perfectly balanced, we cannot guarantee consistency in the check
plane->state->fb == state->fb. This means that sometimes we can increase
the refcount in prepare_fb and don't decrease it in cleanup_fb. The
opposite can also be true.
In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the drm_atomic_get_new_plane_state() helper function should
be used. So, we could stick to this check, but using
drm_atomic_get_new_plane_state(). But actually, this check is not re
---truncated---(CVE-2024-35932)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)
In the Linux kernel, the following vulnerability has been resolved:
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix not validating setsockopt user input
Check user input length before copying data.(CVE-2024-35965)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix not validating setsockopt user input
syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.
In the following crash 1, syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations.
1 divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ...
Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.
I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.(CVE-2024-36916)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure that's actually used.
The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)
In the Linux kernel, the following vulnerability has been resolved:
net: fix __dst_negative_advice() race
__dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-209.0.0.117.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-209.0.0.117.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-209.0.0.117.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\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\r\n\r\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0026apos;s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\r\n\r\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\r\n\r\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0026apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\r\n\r\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\r\n\r\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values. It\u0026apos;s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\r\n\r\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \u0026quot;git status\u0026quot; on it from a Linux afs\nclient[1]. Provided the clone has a pack file that\u0026apos;s in the 2G-4G range,\nthe git status will show errors like:\r\n\r\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\r\n\r\nThis can be observed in the server\u0026apos;s FileLog with something like the\nfollowing appearing:\r\n\r\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\r\n\r\nNote the file position of 18446744071815340032. This is the requested file\nposition sign-extended.(CVE-2021-47366)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix possible access to freed memory in link clear\r\n\r\nAfter modifying the QP to the Error state, all RX WR would be completed\nwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not\nwait for it is done, but destroy the QP and free the link group directly.\nSo there is a risk that accessing the freed memory in tasklet context.\r\n\r\nHere is a crash example:\r\n\r\n BUG: unable to handle page fault for address: ffffffff8f220860\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060\n Oops: 0002 [#1] SMP PTI\n CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23\n Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018\n RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0\n Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e \u0026lt;48\u0026gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32\n RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086\n RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000\n RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00\n RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b\n R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010\n R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040\n FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n _raw_spin_lock_irqsave+0x30/0x40\n mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]\n smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]\n tasklet_action_common.isra.21+0x66/0x100\n __do_softirq+0xd5/0x29c\n asm_call_irq_on_stack+0x12/0x20\n \u0026lt;/IRQ\u0026gt;\n do_softirq_own_stack+0x37/0x40\n irq_exit_rcu+0x9d/0xa0\n sysvec_call_function_single+0x34/0x80\n asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srp: Set scmnd-\u0026gt;result only when scmnd is not NULL\r\n\r\nThis change fixes the following kernel NULL pointer dereference\nwhich is reproduced by blktests srp/007 occasionally.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000170\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014\nWorkqueue: 0x0 (kblockd)\nRIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]\nCode: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 \u0026lt;41\u0026gt; 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9\nRSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282\nRAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000\nRDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff\nRBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001\nR10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000\nR13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __ib_process_cq+0xb7/0x280 [ib_core]\n ib_poll_handler+0x2b/0x130 [ib_core]\n irq_poll_softirq+0x93/0x150\n __do_softirq+0xee/0x4b8\n irq_exit_rcu+0xf7/0x130\n sysvec_apic_timer_interrupt+0x8e/0xc0\n \u0026lt;/IRQ\u0026gt;(CVE-2022-48692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n hex dump (first 32 bytes):\n 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: avoid format-overflow warning\r\n\r\nWith gcc and W=1 option, there\u0026apos;s a warning like this:\r\n\r\nfs/f2fs/compress.c: In function \u2018f2fs_init_page_array_cache\u2019:\nfs/f2fs/compress.c:1984:47: error: \u2018%u\u2019 directive writing between\n1 and 7 bytes into a region of size between 5 and 8\n[-Werror=format-overflow=]\n 1984 | sprintf(slab_name, \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot;, MAJOR(dev),\n\t\tMINOR(dev));\n | ^~\r\n\r\nString \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot; can up to 35. The first \u0026quot;%u\u0026quot; can up\nto 4 and the second \u0026quot;%u\u0026quot; can up to 7, so total size is \u0026quot;24 + 4 + 7 = 35\u0026quot;.\nslab_name\u0026apos;s size should be 35 rather than 32.(CVE-2023-52748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: core: Run atomic i2c xfer when !preemptible\r\n\r\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\r\n\r\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\r\n\r\n[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[ 12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58\n[ 13.001050] machine_restart from panic+0x2a8/0x32c\r\n\r\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.(CVE-2023-52791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: fix a possible null pointer dereference\r\n\r\nIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: mux: Add check and kfree for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.\nMoreover, use kfree() in the later error handling in order to avoid\nmemory leak.(CVE-2023-52841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: do not free live element\r\n\r\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\r\n\r\n add_elem(\u0026quot;00000000\u0026quot;) timeout 100 ms\n ...\n add_elem(\u0026quot;0000000X\u0026quot;) timeout 100 ms\n del_elem(\u0026quot;0000000X\u0026quot;) \u0026lt;---------------- delete one that was just added\n ...\n add_elem(\u0026quot;00005000\u0026quot;) timeout 100 ms\r\n\r\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\r\n\r\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\r\n\r\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\r\n\r\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\r\n\r\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\r\n\r\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\r\n\r\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\r\n\r\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\r\n\r\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\r\n\r\nv2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix unremoved procfs host directory regression\r\n\r\nCommit fc663711b944 (\u0026quot;scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\u0026quot;) fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it\u0026apos;s also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\u0026quot;scsi: core: Fix a procfs host\ndirectory removal regression\u0026quot;). The fix just dropped the hostdir_rm() call\nfrom dev_release().\r\n\r\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \u0026quot;pairs\u0026quot; with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn\u0026apos;t happen. And that pattern happens to exist in some\nerror paths, for example.\r\n\r\nSyzkaller causes that by using USB raw gadget device, error\u0026apos;ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there\u0026apos;s no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\r\n\r\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry \u0026apos;scsi/usb-storage\u0026apos; already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\r\n\r\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\r\n\r\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.(CVE-2024-26935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate request buffer size in smb2_allocate_rsp_buf()\r\n\r\nThe response buffer should be allocated in smb2_allocate_rsp_buf\nbefore validating request. But the fields in payload as well as smb2 header\nis used in smb2_allocate_rsp_buf(). This patch add simple buffer size\nvalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\r\n\r\nSince commit a4d5613c4dc6 (\u0026quot;arm: extend pfn_valid to take into account\nfreed memory map alignment\u0026quot;) changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\r\n\r\n node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node 0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is\uff1a0xc0900000, 0x100000\r\n\r\nthe crash backtrace like:\r\n\r\n Unable to handle kernel paging request at virtual address bff00000\n [...]\n CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1\n Hardware name: Generic DT based system\n PC is at b15_flush_kern_dcache_area+0x24/0x3c\n LR is at __sync_icache_dcache+0x6c/0x98\n [...]\n (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n (__do_mmap_mm) from (do_mmap+0x50/0x58)\n (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n ---[ end trace 09cf0734c3805d52 ]---\n Kernel panic - not syncing: Fatal exception\r\n\r\nSo check if PG_reserved was set to solve this issue.\r\n\r\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\r\n\r\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: walk over current view on netlink dump\r\n\r\nThe generation mask can be updated while netlink dump is in progress.\nThe pipapo set backend walk iterator cannot rely on it to infer what\nview of the datastructure is to be used. Add notation to specify if user\nwants to read/update the set.\r\n\r\nBased on patch from Florian Westphal.(CVE-2024-27017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential NULL pointer dereferences in \u0026apos;dcn10_set_output_transfer_func()\u0026apos;\r\n\r\nThe \u0026apos;stream\u0026apos; pointer is used in dcn10_set_output_transfer_func() before\nthe check if \u0026apos;stream\u0026apos; is NULL.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check \u0026apos;stream\u0026apos; (see line 1875)(CVE-2024-27044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ll_temac: platform_get_resource replaced by wrong function\r\n\r\nThe function platform_get_resource was replaced with\ndevm_platform_ioremap_resource_byname and is called using 0 as name.\r\n\r\nThis eventually ends up in platform_get_resource_byname in the call\nstack, where it causes a null pointer in strcmp.\r\n\r\n\tif (type == resource_type(r) \u0026amp;\u0026amp; !strcmp(r-\u0026gt;name, name))\r\n\r\nIt should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data. Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix UAF in smb2_reconnect_server()\r\n\r\nThe UAF bug is due to smb2_reconnect_server() accessing a session that\nis already being teared down by another thread that is executing\n__cifs_put_smb_ses(). This can happen when (a) the client has\nconnection to the server but no session or (b) another thread ends up\nsetting @ses-\u0026gt;ses_status again to something different than\nSES_EXITING.\r\n\r\nTo fix this, we need to make sure to unconditionally set\n@ses-\u0026gt;ses_status to SES_EXITING and prevent any other threads from\nsetting a new status while we\u0026apos;re still tearing it down.\r\n\r\nThe following can be reproduced by adding some delay to right after\nthe ipc is freed in __cifs_put_smb_ses() - which will give\nsmb2_reconnect_server() worker a chance to run and then accessing\n@ses-\u0026gt;ipc:\r\n\r\nkinit ...\nmount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10\n[disconnect srv]\nls /mnt/1 \u0026amp;\u0026gt;/dev/null\nsleep 30\nkdestroy\n[reconnect srv]\nsleep 10\numount /mnt/1\n...\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\ngeneral protection fault, probably for non-canonical address\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0\nCode: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad\nde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 \u0026lt;48\u0026gt; 8b 01 48 39 f8 75\n7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8\nRSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83\nRAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b\nRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800\nRBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000\nR13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000\nFS: 0000000000000000(0000) GS:ffff888157c00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x36/0x90\n ? exc_general_protection+0x1c1/0x3f0\n ? asm_exc_general_protection+0x26/0x30\n ? __list_del_entry_valid_or_report+0x33/0xf0\n __cifs_put_smb_ses+0x1ae/0x500 [cifs]\n smb2_reconnect_server+0x4ed/0x710 [cifs]\n process_one_work+0x205/0x6b0\n worker_thread+0x191/0x360\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe2/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: fix use-after-free bugs caused by ax25_ds_del_timer\r\n\r\nWhen the ax25 device is detaching, the ax25_dev_device_down()\ncalls ax25_ds_del_timer() to cleanup the slave_timer. When\nthe timer handler is running, the ax25_ds_del_timer() that\ncalls del_timer() in it will return directly. As a result,\nthe use-after-free bugs could happen, one of the scenarios\nis shown below:\r\n\r\n (Thread 1) | (Thread 2)\n | ax25_ds_timeout()\nax25_dev_device_down() |\n ax25_ds_del_timer() |\n del_timer() |\n ax25_dev_put() //FREE |\n | ax25_dev-\u0026gt; //USE\r\n\r\nIn order to mitigate bugs, when the device is detaching, use\ntimer_shutdown_sync() to stop the timer.(CVE-2024-35887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\r\n\r\nsyzbot reported the following uninit-value access issue [1][2]:\r\n\r\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\r\n\r\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.(CVE-2024-35915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vc4: don\u0026apos;t check if plane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb\r\n\r\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\r\n\r\n[ 110.908514] ------------[ cut here ]------------\n[ 110.908529] refcount_t: underflow; use-after-free.\n[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32\n[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[ 110.909170] sp : ffffffc00913b9c0\n[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[ 110.909434] Call trace:\n[ 110.909441] refcount_dec_not_one+0xb8/0xc0\n[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]\n[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]\n[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]\n[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]\n[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]\n[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4\n[ 110.914873] invoke_syscall+0x4c/0x114\n[ 110.914897] el0_svc_common+0xd0/0x118\n[ 110.914917] do_el0_svc+0x38/0xd0\n[ 110.914936] el0_svc+0x30/0x8c\n[ 110.914958] el0t_64_sync_handler+0x84/0xf0\n[ 110.914979] el0t_64_sync+0x18c/0x190\n[ 110.914996] ---[ end trace 0000000000000000 ]---\r\n\r\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don\u0026apos;t decrease it in `cleanup_fb`. The\nopposite can also be true.\r\n\r\nIn fact, the struct drm_plane .state shouldn\u0026apos;t be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---(CVE-2024-35932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\r\n\r\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\r\n\r\nIf some the pages or sgt allocation failed, we shouldn\u0026apos;t release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it\u0026apos;s called.(CVE-2024-35951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n TCP_CLOSE\nconnect()\n TCP_SYN_SENT\n TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1068\n ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: avoid out of bounds shift\r\n\r\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\r\n\r\n[ 186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\r\n\r\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\r\n\r\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[ 449.843143] ------------[ cut here ]------------\n[ 449.848302] kernel BUG at mm/vmalloc.c:2727!\n[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[ 449.882910] RIP: 0010:vunmap+0x2e/0x30\n[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 449.993028] Call Trace:\n[ 449.995756] __iommu_dma_free+0x96/0x100\n[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]\n[ 450.023103] process_one_work+0x1e8/0x3c0\n[ 450.027581] worker_thread+0x50/0x3b0\n[ 450.031669] ? rescuer_thread+0x370/0x370\n[ 450.036143] kthread+0x149/0x170\n[ 450.039744] ? set_kthread_struct+0x40/0x40\n[ 450.044411] ret_from_fork+0x22/0x30\n[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric. This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject. This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)",
"id": "OESA-2024-1738",
"modified": "2026-08-06T11:07:12Z",
"published": "2024-06-21T11:07:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52873"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47366",
"CVE-2022-48673",
"CVE-2022-48692",
"CVE-2023-52670",
"CVE-2023-52748",
"CVE-2023-52791",
"CVE-2023-52821",
"CVE-2023-52841",
"CVE-2023-52873",
"CVE-2023-52882",
"CVE-2024-26924",
"CVE-2024-26935",
"CVE-2024-26936",
"CVE-2024-26947",
"CVE-2024-26954",
"CVE-2024-26960",
"CVE-2024-27014",
"CVE-2024-27017",
"CVE-2024-27019",
"CVE-2024-27044",
"CVE-2024-35796",
"CVE-2024-35819",
"CVE-2024-35821",
"CVE-2024-35828",
"CVE-2024-35870",
"CVE-2024-35887",
"CVE-2024-35910",
"CVE-2024-35915",
"CVE-2024-35932",
"CVE-2024-35935",
"CVE-2024-35937",
"CVE-2024-35951",
"CVE-2024-35965",
"CVE-2024-35966",
"CVE-2024-36016",
"CVE-2024-36905",
"CVE-2024-36916",
"CVE-2024-36919",
"CVE-2024-36952",
"CVE-2024-36960",
"CVE-2024-36968",
"CVE-2024-36971"
]
}
OESA-2024-1835 (CVE-2021-47270)
Vulnerability from osv_openeuler – Published: 2024-07-12 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:
usb: fix various gadgets null ptr deref on 10gbps cabling.
This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)
In the Linux kernel, the following vulnerability has been resolved:
seg6: fix the iif in the IPv6 socket control block
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510):
IPCB(skb)->iif = skb->skb_iif;
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).
Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero).
As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied.
To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.(CVE-2021-47515)
In the Linux kernel, the following vulnerability has been resolved:
media: mxl111sf: change mutex_init() location
Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location.
Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls:
dvb_usbv2_init()
dvb_usbv2_adapter_init()
dvb_usbv2_adapter_frontend_init()
props->frontend_attach()
props->init()
Since mxl111sf_ devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_ devices, which will simply initiaize mutex.(CVE-2021-47583)
In the Linux kernel, the following vulnerability has been resolved:
mac80211: validate extended element ID is present
Before attempting to parse an extended element, verify that the extended element ID is present.(CVE-2021-47611)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix queues reservation for XDP
When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference.
i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0
This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on.
Fix this by always allocating last queue in PF queue pile for a flow director VSI.(CVE-2021-47619)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: max9759: fix underflow in speaker_gain_control_put()
Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put()(CVE-2022-48717)
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: ca8210: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. We then leak the skb structure.
Free the skb structure upon error before returning.(CVE-2022-48722)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-48736)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.(CVE-2022-48738)
In the Linux kernel, the following vulnerability has been resolved:
net: amd-xgbe: Fix skb data length underflow
There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected.
Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors.(CVE-2022-48743)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid field-overflowing memcpy()
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields.
Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler.
We were doing:
#define ETH_HLEN 14
#define VLAN_HLEN 4
...
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
...
struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);
...
struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
struct mlx5_wqe_data_seg *dseg = wqe->data;
...
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes).
struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; / 0 16 / struct mlx5_wqe_eth_seg eth; / 16 16 / struct mlx5_wqe_data_seg data[]; / 32 0 /
/* size: 32, cachelines: 1, members: 3 */
/* last cacheline: 32 bytes */
};
struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; / 0 1 / u8 swp_outer_l3_offset; / 1 1 / u8 swp_inner_l4_offset; / 2 1 / u8 swp_inner_l3_offset; / 3 1 / u8 cs_flags; / 4 1 / u8 swp_flags; / 5 1 / __be16 mss; / 6 2 / __be32 flow_table_metadata; / 8 4 / union { struct { __be16 sz; / 12 2 / u8 start[2]; / 14 2 / } inline_hdr; / 12 4 / struct { __be16 type; / 12 2 / __be16 vlan_tci; / 14 2 / } insert; / 12 4 / __be32 trailer; / 12 4 / }; / 12 4 /
/* size: 16, cachelines: 1, members: 9 */
/* last cacheline: 16 bytes */
};
struct mlx5_wqe_data_seg { __be32 byte_count; / 0 4 / __be32 lkey; / 4 4 / __be64 addr; / 8 8 /
/* size: 16, cachelines: 1, members: 3 */
/* last cacheline: 16 bytes */
};
So, split the memcpy() so the compiler can reason about the buffer sizes.
"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations).(CVE-2022-48744)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early.
Replace the fcoe_port's destroy_work queue. It's not needed.
The problem is easily reproducible with the following steps.
Example:
$ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]---(CVE-2022-48758)
In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90(CVE-2022-48772)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdio: fix possible resource leaks in some error paths
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device().
To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device().
In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced.
Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone.
unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 mmc_core
In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.(CVE-2024-23848)
In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.
When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0.
As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.
To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU.
Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: prevent kernel-infoleak
syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1].
The issue here is that 'struct tc_skbmod' has a four bytes hole.
We need to clear the structure before filling fields.
[1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 _syssendmsg+0x877/0xb60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncated---(CVE-2024-35893)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.
This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)
In the Linux kernel, the following vulnerability has been resolved:
drm/arm/malidp: fix a possible null pointer dereference
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset.(CVE-2024-36014)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: sync all devices to wait all processes being evicted
If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows:
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g);
It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(__NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
With this patch:
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument
[0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)
In the Linux kernel, the following vulnerability has been resolved:
drm: vc4: Fix possible null pointer dereference
In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)
In the Linux kernel, the following vulnerability has been resolved:
net: fec: remove .ndo_poll_controller to avoid deadlocks
There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.(CVE-2024-38553)
In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix reference count leak issue of net_device
There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak.
In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null.(CVE-2024-38554)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Ensure the copied buf is NUL terminated
Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user.(CVE-2024-38559)
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: Fix buffer size for tag 66 packet
The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer.
Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer.
This fixes the below kasan slab-out-of-bounds bug:
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK>
Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2024-38578)
In the Linux kernel, the following vulnerability has been resolved:
crypto: bcm - Fix pointer arithmetic
In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below:
nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.
The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of timer for log writer thread
Patch series "nilfs2: fix log writer related issues".
This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.
This patch (of 3):
A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure.
The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime.
Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.(CVE-2024-38583)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Set lower bound of start tick time
Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer.
This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.(CVE-2024-38618)
In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Update uart_driver_registered on driver removal
The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses:
max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0
Update the actual state so next time UART driver will be registered again.
Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)
In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 max3100
In the Linux kernel, the following vulnerability has been resolved:
greybus: lights: check return of get_channel_from_mode
If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places.
This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE.
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)
In the Linux kernel, the following vulnerability has been resolved:
enic: Validate length of nl attributes in enic_set_vf_port
enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.(CVE-2024-38659)
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning.
Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix uninit-value in p9_client_rpc()
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 slaballoc+0x1184/0x33d0 mm/slub.c:3525 slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes.
Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.(CVE-2024-39301)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2407.3.0.0285.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2407.3.0.0285.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: fix various gadgets null ptr deref on 10gbps cabling.\r\n\r\nThis avoids a null pointer dereference in\nf_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}\nby simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nseg6: fix the iif in the IPv6 socket control block\r\n\r\nWhen an IPv4 packet is received, the ip_rcv_core(...) sets the receiving\ninterface index into the IPv4 socket control block (v5.16-rc4,\nnet/ipv4/ip_input.c line 510):\r\n\r\n IPCB(skb)-\u0026gt;iif = skb-\u0026gt;skb_iif;\r\n\r\nIf that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH\nheader, the seg6_do_srh_encap(...) performs the required encapsulation.\nIn this case, the seg6_do_srh_encap function clears the IPv6 socket control\nblock (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):\r\n\r\n memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));\r\n\r\nThe memset(...) was introduced in commit ef489749aae5 (\u0026quot;ipv6: sr: clear\nIP6CB(skb) on SRH ip4ip6 encapsulation\u0026quot;) a long time ago (2019-01-29).\r\n\r\nSince the IPv6 socket control block and the IPv4 socket control block share\nthe same memory area (skb-\u0026gt;cb), the receiving interface index info is lost\n(IP6CB(skb)-\u0026gt;iif is set to zero).\r\n\r\nAs a side effect, that condition triggers a NULL pointer dereference if\ncommit 0857d6f8c759 (\u0026quot;ipv6: When forwarding count rx stats on the orig\nnetdev\u0026quot;) is applied.\r\n\r\nTo fix that issue, we set the IP6CB(skb)-\u0026gt;iif with the index of the\nreceiving interface once again.(CVE-2021-47515)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mxl111sf: change mutex_init() location\r\n\r\nSyzbot reported, that mxl111sf_ctrl_msg() uses uninitialized\nmutex. The problem was in wrong mutex_init() location.\r\n\r\nPrevious mutex_init(\u0026amp;state-\u0026gt;msg_lock) call was in -\u0026gt;init() function, but\ndvb_usbv2_init() has this order of calls:\r\n\r\n\tdvb_usbv2_init()\n\t dvb_usbv2_adapter_init()\n\t dvb_usbv2_adapter_frontend_init()\n\t props-\u0026gt;frontend_attach()\r\n\r\n\t props-\u0026gt;init()\r\n\r\nSince mxl111sf_* devices call mxl111sf_ctrl_msg() in -\u0026gt;frontend_attach()\ninternally we need to initialize state-\u0026gt;msg_lock before\nfrontend_attach(). To achieve it, -\u0026gt;probe() call added to all mxl111sf_*\ndevices, which will simply initiaize mutex.(CVE-2021-47583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac80211: validate extended element ID is present\r\n\r\nBefore attempting to parse an extended element, verify that\nthe extended element ID is present.(CVE-2021-47611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Fix queues reservation for XDP\r\n\r\nWhen XDP was configured on a system with large number of CPUs\nand X722 NIC there was a call trace with NULL pointer dereference.\r\n\r\ni40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12\ni40e 0000:87:00.0: setup of MAIN VSI failed\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nRIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]\nCall Trace:\n? i40e_reconfig_rss_queues+0x130/0x130 [i40e]\ndev_xdp_install+0x61/0xe0\ndev_xdp_attach+0x18a/0x4c0\ndev_change_xdp_fd+0x1e6/0x220\ndo_setlink+0x616/0x1030\n? ahci_port_stop+0x80/0x80\n? ata_qc_issue+0x107/0x1e0\n? lock_timer_base+0x61/0x80\n? __mod_timer+0x202/0x380\nrtnl_setlink+0xe5/0x170\n? bpf_lsm_binder_transaction+0x10/0x10\n? security_capable+0x36/0x50\nrtnetlink_rcv_msg+0x121/0x350\n? rtnl_calcit.isra.0+0x100/0x100\nnetlink_rcv_skb+0x50/0xf0\nnetlink_unicast+0x1d3/0x2a0\nnetlink_sendmsg+0x22a/0x440\nsock_sendmsg+0x5e/0x60\n__sys_sendto+0xf0/0x160\n? __sys_getsockname+0x7e/0xc0\n? _copy_from_user+0x3c/0x80\n? __sys_setsockopt+0xc8/0x1a0\n__x64_sys_sendto+0x20/0x30\ndo_syscall_64+0x33/0x40\nentry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f83fa7a39e0\r\n\r\nThis was caused by PF queue pile fragmentation due to\nflow director VSI queue being placed right after main VSI.\nBecause of this main VSI was not able to resize its\nqueue allocation for XDP resulting in no queues allocated\nfor main VSI when XDP was turned on.\r\n\r\nFix this by always allocating last queue in PF queue pile\nfor a flow director VSI.(CVE-2021-47619)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: max9759: fix underflow in speaker_gain_control_put()\r\n\r\nCheck for negative values of \u0026quot;priv-\u0026gt;gain\u0026quot; to prevent an out of bounds\naccess. The concern is that these might come from the user via:\n -\u0026gt; snd_ctl_elem_write_user()\n -\u0026gt; snd_ctl_elem_write()\n -\u0026gt; kctl-\u0026gt;put()(CVE-2022-48717)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: ca8210: Stop leaking skb\u0026apos;s\r\n\r\nUpon error the ieee802154_xmit_complete() helper is not called. Only\nieee802154_wake_queue() is called manually. We then leak the skb\nstructure.\r\n\r\nFree the skb structure upon error before returning.(CVE-2022-48722)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-48736)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw()\r\n\r\nWe don\u0026apos;t currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range.(CVE-2022-48738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: amd-xgbe: Fix skb data length underflow\r\n\r\nThere will be BUG_ON() triggered in include/linux/skbuff.h leading to\nintermittent kernel panic, when the skb length underflow is detected.\r\n\r\nFix this by dropping the packet if such length underflows are seen\nbecause of inconsistencies in the hardware descriptors.(CVE-2022-48743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Avoid field-overflowing memcpy()\r\n\r\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\r\n\r\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\r\n\r\nWe were doing:\r\n\r\n\t#define ETH_HLEN 14\n\t#define VLAN_HLEN 4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n struct mlx5_wqe_eth_seg *eseg = \u0026amp;wqe-\u0026gt;eth;\n struct mlx5_wqe_data_seg *dseg = wqe-\u0026gt;data;\n\t...\n\tmemcpy(eseg-\u0026gt;inline_hdr.start, xdptxd-\u0026gt;data, MLX5E_XDP_MIN_INLINE);\r\n\r\ntarget is wqe-\u0026gt;eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe-\u0026gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\r\n\r\nstruct mlx5e_tx_wqe {\n struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */\n struct mlx5_wqe_eth_seg eth; /* 16 16 */\n struct mlx5_wqe_data_seg data[]; /* 32 0 */\r\n\r\n /* size: 32, cachelines: 1, members: 3 */\n /* last cacheline: 32 bytes */\n};\r\n\r\nstruct mlx5_wqe_eth_seg {\n u8 swp_outer_l4_offset; /* 0 1 */\n u8 swp_outer_l3_offset; /* 1 1 */\n u8 swp_inner_l4_offset; /* 2 1 */\n u8 swp_inner_l3_offset; /* 3 1 */\n u8 cs_flags; /* 4 1 */\n u8 swp_flags; /* 5 1 */\n __be16 mss; /* 6 2 */\n __be32 flow_table_metadata; /* 8 4 */\n union {\n struct {\n __be16 sz; /* 12 2 */\n u8 start[2]; /* 14 2 */\n } inline_hdr; /* 12 4 */\n struct {\n __be16 type; /* 12 2 */\n __be16 vlan_tci; /* 14 2 */\n } insert; /* 12 4 */\n __be32 trailer; /* 12 4 */\n }; /* 12 4 */\r\n\r\n /* size: 16, cachelines: 1, members: 9 */\n /* last cacheline: 16 bytes */\n};\r\n\r\nstruct mlx5_wqe_data_seg {\n __be32 byte_count; /* 0 4 */\n __be32 lkey; /* 4 4 */\n __be64 addr; /* 8 8 */\r\n\r\n /* size: 16, cachelines: 1, members: 3 */\n /* last cacheline: 16 bytes */\n};\r\n\r\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\r\n\r\n\u0026quot;pahole\u0026quot; shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \u0026quot;objdump -d\u0026quot; shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).(CVE-2022-48744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()\r\n\r\nThe bnx2fc_destroy() functions are removing the interface before calling\ndestroy_work. This results multiple WARNings from sysfs_remove_group() as\nthe controller rport device attributes are removed too early.\r\n\r\nReplace the fcoe_port\u0026apos;s destroy_work queue. It\u0026apos;s not needed.\r\n\r\nThe problem is easily reproducible with the following steps.\r\n\r\nExample:\r\n\r\n $ dmesg -w \u0026amp;\n $ systemctl enable --now fcoe\n $ fipvlan -s -c ens2f1\n $ fcoeadm -d ens2f1.802\n [ 583.464488] host2: libfc: Link down on port (7500a1)\n [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!!\n [ 583.490468] ------------[ cut here ]------------\n [ 583.538725] sysfs group \u0026apos;power\u0026apos; not found for kobject \u0026apos;rport-2:0-0\u0026apos;\n [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80\n [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...\n [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1\n [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013\n [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]\n [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80\n [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...\n [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282\n [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000\n [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0\n [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00\n [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400\n [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004\n [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000\n [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0\n [ 584.454888] Call Trace:\n [ 584.466108] device_del+0xb2/0x3e0\n [ 584.481701] device_unregister+0x13/0x60\n [ 584.501306] bsg_unregister_queue+0x5b/0x80\n [ 584.522029] bsg_remove_queue+0x1c/0x40\n [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]\n [ 584.573823] process_one_work+0x1e3/0x3b0\n [ 584.592396] worker_thread+0x50/0x3b0\n [ 584.609256] ? rescuer_thread+0x370/0x370\n [ 584.628877] kthread+0x149/0x170\n [ 584.643673] ? set_kthread_struct+0x40/0x40\n [ 584.662909] ret_from_fork+0x22/0x30\n [ 584.680002] ---[ end trace 53575ecefa942ece ]---(CVE-2022-48758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: lgdt3306a: Add a check against null-pointer-def\r\n\r\nThe driver should check whether the client provides the platform_data.\r\n\r\nThe following log reveals it:\r\n\r\n[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40\n[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414\n[ 29.612820] Call Trace:\n[ 29.613030] \u0026lt;TASK\u0026gt;\n[ 29.613201] dump_stack_lvl+0x56/0x6f\n[ 29.613496] ? kmemdup+0x30/0x40\n[ 29.613754] print_report.cold+0x494/0x6b7\n[ 29.614082] ? kmemdup+0x30/0x40\n[ 29.614340] kasan_report+0x8a/0x190\n[ 29.614628] ? kmemdup+0x30/0x40\n[ 29.614888] kasan_check_range+0x14d/0x1d0\n[ 29.615213] memcpy+0x20/0x60\n[ 29.615454] kmemdup+0x30/0x40\n[ 29.615700] lgdt3306a_probe+0x52/0x310\n[ 29.616339] i2c_device_probe+0x951/0xa90(CVE-2022-48772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdio: fix possible resource leaks in some error paths\r\n\r\nIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can\nnot release the resources, because the sdio function is not presented\nin these two cases, it won\u0026apos;t call of_node_put() or put_device().\r\n\r\nTo fix these leaks, make sdio_func_present() only control whether\ndevice_del() needs to be called or not, then always call of_node_put()\nand put_device().\r\n\r\nIn error case in sdio_init_func(), the reference of \u0026apos;card-\u0026gt;dev\u0026apos; is\nnot get, to avoid redundant put in sdio_free_func_cis(), move the\nget_device() to sdio_alloc_func() and put_device() to sdio_release_func(),\nit can keep the get/put function be balanced.\r\n\r\nWithout this patch, while doing fault inject test, it can get the\nfollowing leak reports, after this fix, the leak is gone.\r\n\r\nunreferenced object 0xffff888112514000 (size 2048):\n comm \u0026quot;kworker/3:2\u0026quot;, pid 65, jiffies 4294741614 (age 124.774s)\n hex dump (first 32 bytes):\n 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......\n 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....\n backtrace:\n [\u0026lt;000000009e5931da\u0026gt;] kmalloc_trace+0x21/0x110\n [\u0026lt;000000002f839ccb\u0026gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]\n [\u0026lt;0000000004adcbf6\u0026gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]\n [\u0026lt;000000007538fea0\u0026gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]\n [\u0026lt;00000000d4fdeba7\u0026gt;] mmc_rescan+0x54a/0x640 [mmc_core]\r\n\r\nunreferenced object 0xffff888112511000 (size 2048):\n comm \u0026quot;kworker/3:2\u0026quot;, pid 65, jiffies 4294741623 (age 124.766s)\n hex dump (first 32 bytes):\n 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......\n 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....\n backtrace:\n [\u0026lt;000000009e5931da\u0026gt;] kmalloc_trace+0x21/0x110\n [\u0026lt;00000000fcbe706c\u0026gt;] sdio_alloc_func+0x35/0x100 [mmc_core]\n [\u0026lt;00000000c68f4b50\u0026gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]\n [\u0026lt;00000000d4fdeba7\u0026gt;] mmc_rescan+0x54a/0x640 [mmc_core](CVE-2023-52730)\r\n\r\nIn the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.(CVE-2024-23848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_skbmod: prevent kernel-infoleak\r\n\r\nsyzbot found that tcf_skbmod_dump() was copying four bytes\nfrom kernel stack to user space [1].\r\n\r\nThe issue here is that \u0026apos;struct tc_skbmod\u0026apos; has a four bytes hole.\r\n\r\nWe need to clear the structure before filling fields.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n copy_to_iter include/linux/uio.h:196 [inline]\n simple_copy_to_iter net/core/datagram.c:532 [inline]\n __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420\n skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]\n netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242\n __do_sys_recvfrom net/socket.c:2260 [inline]\n __se_sys_recvfrom net/socket.c:2256 [inline]\n __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253\n netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317\n netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351\n nlmsg_unicast include/net/netlink.h:1144 [inline]\n nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610\n rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741\n rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]\n tcf_add_notify net/sched/act_api.c:2048 [inline]\n tcf_action_add net/sched/act_api.c:2071 [inline]\n tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119\n rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559\n rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n __nla_put lib/nlattr.c:1041 [inline]\n nla_put+0x1c6/0x230 lib/nlattr.c:1099\n tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256\n tcf_action_dump_old net/sched/act_api.c:1191 [inline]\n tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227\n tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251\n tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628\n tcf_add_notify_msg net/sched/act_api.c:2023 [inline]\n tcf_add_notify net/sched/act_api.c:2042 [inline]\n tcf_action_add net/sched/act_api.c:2071 [inline]\n tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119\n rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n netlink_rcv_skb+0x375/0x650 net/netlink/af_netli\n---truncated---(CVE-2024-35893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\r\n\r\nsyzbot reported the following uninit-value access issue [1][2]:\r\n\r\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\r\n\r\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.(CVE-2024-35915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/arm/malidp: fix a possible null pointer dereference\r\n\r\nIn malidp_mw_connector_reset, new memory is allocated with kzalloc, but\nno check is performed. In order to prevent null pointer dereferencing,\nensure that mw_state is checked before calling\n__drm_atomic_helper_connector_reset.(CVE-2024-36014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namd/amdkfd: sync all devices to wait all processes being evicted\r\n\r\nIf there are more than one device doing reset in parallel, the first\ndevice will call kfd_suspend_all_processes() to evict all processes\non all devices, this call takes time to finish. other device will\nstart reset and recover without waiting. if the process has not been\nevicted before doing recover, it will be restored, then caused page\nfault.(CVE-2024-36949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Fix shift-out-of-bounds in dctcp_update_alpha().\r\n\r\nIn dctcp_update_alpha(), we use a module parameter dctcp_shift_g\nas follows:\r\n\r\n alpha -= min_not_zero(alpha, alpha \u0026gt;\u0026gt; dctcp_shift_g);\n ...\n delivered_ce \u0026lt;\u0026lt;= (10 - dctcp_shift_g);\r\n\r\nIt seems syzkaller started fuzzing module parameters and triggered\nshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:\r\n\r\n memcpy((void*)0x20000080,\n \u0026quot;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\\000\u0026quot;, 47);\n res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,\n /*flags=*/2ul, /*mode=*/0ul);\n memcpy((void*)0x20000000, \u0026quot;100\\000\u0026quot;, 4);\n syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);\r\n\r\nLet\u0026apos;s limit the max value of dctcp_shift_g by param_set_uint_minmax().\r\n\r\nWith this patch:\r\n\r\n # echo 10 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n 10\n # echo 11 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n -bash: echo: write error: Invalid argument\r\n\r\n[0]:\nUBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12\nshift exponent 100 is too large for 32-bit type \u0026apos;u32\u0026apos; (aka \u0026apos;unsigned int\u0026apos;)\nCPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468\n dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143\n tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]\n tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948\n tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711\n tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937\n sk_backlog_rcv include/net/sock.h:1106 [inline]\n __release_sock+0x20f/0x350 net/core/sock.c:2983\n release_sock+0x61/0x1f0 net/core/sock.c:3549\n mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907\n mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976\n __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072\n mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127\n inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:659 [inline]\n sock_close+0xc0/0x240 net/socket.c:1421\n __fput+0x41b/0x890 fs/file_table.c:422\n task_work_run+0x23b/0x300 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x9c8/0x2540 kernel/exit.c:878\n do_group_exit+0x201/0x2b0 kernel/exit.c:1027\n __do_sys_exit_group kernel/exit.c:1038 [inline]\n __se_sys_exit_group kernel/exit.c:1036 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f6c2b5005b6\nCode: Unable to access opcode bytes at 0x7f6c2b50058c.\nRSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6\nRDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001\nRBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;(CVE-2024-37356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: vc4: Fix possible null pointer dereference\r\n\r\nIn vc4_hdmi_audio_init() of_get_address() may return\nNULL which is later dereferenced. Fix this bug by adding NULL check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fec: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nThere is a deadlock issue found in sungem driver, please refer to the\ncommit ac0a230f719b (\u0026quot;eth: sungem: remove .ndo_poll_controller to avoid\ndeadlocks\u0026quot;). The root cause of the issue is that netpoll is in atomic\ncontext and disable_irq() is called by .ndo_poll_controller interface\nof sungem driver, however, disable_irq() might sleep. After analyzing\nthe implementation of fec_poll_controller(), the fec driver should have\nthe same issue. Due to the fec driver uses NAPI for TX completions, the\n.ndo_poll_controller is unnecessary to be implemented in the fec driver,\nso fec_poll_controller() can be safely removed.(CVE-2024-38553)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedf: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a count-sized kernel buffer and copy count from\nuserspace to that buffer. Later, we use kstrtouint on this buffer but we\ndon\u0026apos;t ensure that the string is terminated inside the buffer, this can\nlead to OOB read when using kstrtouint. Fix this issue by using\nmemdup_user_nul instead of memdup_user.(CVE-2024-38559)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\necryptfs: Fix buffer size for tag 66 packet\r\n\r\nThe \u0026apos;TAG 66 Packet Format\u0026apos; description is missing the cipher code and\nchecksum fields that are packed into the message packet. As a result,\nthe buffer allocated for the packet is 3 bytes too small and\nwrite_tag_66_packet() will write up to 3 bytes past the end of the\nbuffer.\r\n\r\nFix this by increasing the size of the allocation so the whole packet\nwill always fit in the buffer.\r\n\r\nThis fixes the below kasan slab-out-of-bounds bug:\r\n\r\n BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0\n Write of size 1 at addr ffff88800afbb2a5 by task touch/181\r\n\r\n CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x4c/0x70\n print_report+0xc5/0x610\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n ? kasan_complete_mode_report_info+0x44/0x210\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n kasan_report+0xc2/0x110\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n __asan_store1+0x62/0x80\n ecryptfs_generate_key_packet_set+0x7d6/0xde0\n ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10\n ? __alloc_pages+0x2e2/0x540\n ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]\n ? dentry_open+0x8f/0xd0\n ecryptfs_write_metadata+0x30a/0x550\n ? __pfx_ecryptfs_write_metadata+0x10/0x10\n ? ecryptfs_get_lower_file+0x6b/0x190\n ecryptfs_initialize_file+0x77/0x150\n ecryptfs_create+0x1c2/0x2f0\n path_openat+0x17cf/0x1ba0\n ? __pfx_path_openat+0x10/0x10\n do_filp_open+0x15e/0x290\n ? __pfx_do_filp_open+0x10/0x10\n ? __kasan_check_write+0x18/0x30\n ? _raw_spin_lock+0x86/0xf0\n ? __pfx__raw_spin_lock+0x10/0x10\n ? __kasan_check_write+0x18/0x30\n ? alloc_fd+0xf4/0x330\n do_sys_openat2+0x122/0x160\n ? __pfx_do_sys_openat2+0x10/0x10\n __x64_sys_openat+0xef/0x170\n ? __pfx___x64_sys_openat+0x10/0x10\n do_syscall_64+0x60/0xd0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n RIP: 0033:0x7f00a703fd67\n Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f\n RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101\n RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67\n RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c\n RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000\n R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941\n R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 181:\n kasan_save_stack+0x2f/0x60\n kasan_set_track+0x29/0x40\n kasan_save_alloc_info+0x25/0x40\n __kasan_kmalloc+0xc5/0xd0\n __kmalloc+0x66/0x160\n ecryptfs_generate_key_packet_set+0x6d2/0xde0\n ecryptfs_write_metadata+0x30a/0x550\n ecryptfs_initialize_file+0x77/0x150\n ecryptfs_create+0x1c2/0x2f0\n path_openat+0x17cf/0x1ba0\n do_filp_open+0x15e/0x290\n do_sys_openat2+0x122/0x160\n __x64_sys_openat+0xef/0x170\n do_syscall_64+0x60/0xd0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2024-38578)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: bcm - Fix pointer arithmetic\r\n\r\nIn spu2_dump_omd() value of ptr is increased by ciph_key_len\ninstead of hash_iv_len which could lead to going beyond the\nbuffer boundaries.\nFix this bug by changing ciph_key_len to hash_iv_len.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n nilfs_segctor_destroy\n nilfs_segctor_kill_thread --\u0026gt; Shut down log writer thread\n flush_work\n nilfs_iput_work_func\n nilfs_dispose_list\n iput\n nilfs_evict_inode\n nilfs_transaction_commit\n nilfs_construct_segment (if inode needs sync)\n nilfs_segctor_sync --\u0026gt; Attempt to synchronize with\n log writer thread\n *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis. Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: timer: Set lower bound of start tick time\r\n\r\nCurrently ALSA timer doesn\u0026apos;t have the lower limit of the start tick\ntime, and it allows a very small size, e.g. 1 tick with 1ns resolution\nfor hrtimer. Such a situation may lead to an unexpected RCU stall,\nwhere the callback repeatedly queuing the expire update, as reported\nby fuzzer.\r\n\r\nThis patch introduces a sanity check of the timer start tick time, so\nthat the system returns an error when a too small start size is set.\nAs of this patch, the lower limit is hard-coded to 100us, which is\nsmall enough but can still work somehow.(CVE-2024-38618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Update uart_driver_registered on driver removal\r\n\r\nThe removal of the last MAX3100 device triggers the removal of\nthe driver. However, code doesn\u0026apos;t update the respective global\nvariable and after insmod \u2014 rmmod \u2014 insmod cycle the kernel\noopses:\r\n\r\n max3100 spi-PRP0001:01: max3100_probe: adding port 0\n BUG: kernel NULL pointer dereference, address: 0000000000000408\n ...\n RIP: 0010:serial_core_register_port+0xa0/0x840\n ...\n max3100_probe+0x1b6/0x280 [max3100]\n spi_probe+0x8d/0xb0\r\n\r\nUpdate the actual state so next time UART driver will be registered\nagain.\r\n\r\nHugo also noticed, that the error path in the probe also affected\nby having the variable set, and not cleared. Instead of clearing it\nmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n ...\n Workqueue: max3100-0 max3100_work [max3100]\n RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n ...\n max3100_handlerx+0xc5/0x110 [max3100]\n max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngreybus: lights: check return of get_channel_from_mode\r\n\r\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\r\n\r\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nenic: Validate length of nl attributes in enic_set_vf_port\r\n\r\nenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE\nis of length PORT_PROFILE_MAX and that the nl attributes\nIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.\nThese attributes are validated (in the function do_setlink in rtnetlink.c)\nusing the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE\nas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and\nIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation\nusing the policy is for the max size of the attributes and not on exact\nsize so the length of these attributes might be less than the sizes that\nenic_set_vf_port expects. This might cause an out of bands\nread access in the memcpys of the data of these\nattributes in enic_set_vf_port.(CVE-2024-38659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf/sw-sync: don\u0026apos;t enable IRQ from sync_print_obj()\r\n\r\nSince commit a6aa8fca4d79 (\u0026quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\u0026quot;) by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\r\n\r\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/9p: fix uninit-value in p9_client_rpc()\r\n\r\nSyzbot with the help of KMSAN reported the following error:\r\n\r\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nIf p9_check_errors() fails early in p9_client_rpc(), req-\u0026gt;rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\r\n\r\nFix this issue by assigning default values to p9_fcall fields\nsuch as \u0026apos;tag\u0026apos; and (just in case KMSAN unearths something new) \u0026apos;id\u0026apos;\nduring the tag allocation stage.(CVE-2024-39301)",
"id": "OESA-2024-1835",
"modified": "2026-08-06T11:07:18Z",
"published": "2024-07-12T11:07:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47515"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47619"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48743"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48758"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38546"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38559"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38578"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38579"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47270",
"CVE-2021-47515",
"CVE-2021-47583",
"CVE-2021-47611",
"CVE-2021-47619",
"CVE-2022-48717",
"CVE-2022-48722",
"CVE-2022-48736",
"CVE-2022-48738",
"CVE-2022-48743",
"CVE-2022-48744",
"CVE-2022-48758",
"CVE-2022-48772",
"CVE-2023-52730",
"CVE-2024-23848",
"CVE-2024-31076",
"CVE-2024-35893",
"CVE-2024-35915",
"CVE-2024-36014",
"CVE-2024-36949",
"CVE-2024-37356",
"CVE-2024-38546",
"CVE-2024-38553",
"CVE-2024-38554",
"CVE-2024-38559",
"CVE-2024-38578",
"CVE-2024-38579",
"CVE-2024-38582",
"CVE-2024-38583",
"CVE-2024-38618",
"CVE-2024-38633",
"CVE-2024-38634",
"CVE-2024-38637",
"CVE-2024-38659",
"CVE-2024-38780",
"CVE-2024-39301"
]
}
SSA-265688
Vulnerability from csaf_siemens - Published: 2024-04-09 00:00 - Updated: 2026-05-12 00:00SUSE-SU-2024:2008-1
Vulnerability from csaf_suse - Published: 2024-06-12 11:33 - Updated: 2024-06-12 11:33SUSE-SU-2024:2019-1
Vulnerability from csaf_suse - Published: 2024-06-13 10:40 - Updated: 2024-06-13 10:40Sightings
| 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.