Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2023-52900 (GCVE-0-2023-52900)
Vulnerability from cvelistv5 – Published: 2024-08-21 06:10 – Updated: 2026-05-11 19:35| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
a60be987d45dd510aeb54389526f9957cfab106c , < 3c2a2ff67d46106715c2132021b98bd057c27545
(git)
Affected: a60be987d45dd510aeb54389526f9957cfab106c , < d9fde9eab1766170ff2ade67d09178d2cfd78749 (git) Affected: a60be987d45dd510aeb54389526f9957cfab106c , < b0ba060d3287108eba17603bee3810e4cf2c272d (git) Affected: a60be987d45dd510aeb54389526f9957cfab106c , < 712bd74eccb9d3626a0a236641962eca8e11a243 (git) Affected: a60be987d45dd510aeb54389526f9957cfab106c , < 45627a1a6450662e1e0f8174ef07b05710a20062 (git) Affected: a60be987d45dd510aeb54389526f9957cfab106c , < 0bf463939c09e5b2c35c71ed74a5fd60a74d6a04 (git) Affected: a60be987d45dd510aeb54389526f9957cfab106c , < 7633355e5c7f29c049a9048e461427d1d8ed3051 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.30
Unaffected: 0 , < 2.6.30 (semver) Unaffected: 4.14.304 , ≤ 4.14.* (semver) Unaffected: 4.19.271 , ≤ 4.19.* (semver) Unaffected: 5.4.230 , ≤ 5.4.* (semver) Unaffected: 5.10.165 , ≤ 5.10.* (semver) Unaffected: 5.15.90 , ≤ 5.15.* (semver) Unaffected: 6.1.8 , ≤ 6.1.* (semver) Unaffected: 6.2 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52900",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:03:31.052227Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-12T17:33:15.051Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/nilfs2/btree.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c2a2ff67d46106715c2132021b98bd057c27545",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "d9fde9eab1766170ff2ade67d09178d2cfd78749",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "b0ba060d3287108eba17603bee3810e4cf2c272d",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "712bd74eccb9d3626a0a236641962eca8e11a243",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "45627a1a6450662e1e0f8174ef07b05710a20062",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "0bf463939c09e5b2c35c71ed74a5fd60a74d6a04",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "7633355e5c7f29c049a9048e461427d1d8ed3051",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/nilfs2/btree.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.304",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.271",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.165",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.90",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.304",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.271",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.230",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.165",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.90",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.8",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.2",
"versionStartIncluding": "2.6.30",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix general protection fault in nilfs_btree_insert()\n\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\n\nWhen nilfs_btree_insert() receives this spurious \u0027not found\u0027 code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0027not found\u0027 check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\n\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u003cTASK\u003e\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u003c/TASK\u003e\n\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\n\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T19:35:09.947Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545"
},
{
"url": "https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749"
},
{
"url": "https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d"
},
{
"url": "https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243"
},
{
"url": "https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062"
},
{
"url": "https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04"
},
{
"url": "https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051"
}
],
"title": "nilfs2: fix general protection fault in nilfs_btree_insert()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52900",
"datePublished": "2024-08-21T06:10:40.533Z",
"dateReserved": "2024-08-21T06:07:11.014Z",
"dateUpdated": "2026-05-11T19:35:09.947Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-52900",
"date": "2026-09-17",
"epss": "0.00241",
"percentile": "0.15401"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2023-52900\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-08-21T07:15:06.297\",\"lastModified\":\"2026-06-17T06:43:53.593\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnilfs2: fix general protection fault in nilfs_btree_insert()\\n\\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\\nblock by calling __nilfs_btree_get_block() against an invalid virtual\\nblock address, it returns -ENOENT because conversion of the virtual block\\naddress to a disk block address fails. However, this return value is the\\nsame as the internal code that b-tree lookup routines return to indicate\\nthat the block being searched does not exist, so functions that operate on\\nthat b-tree may misbehave.\\n\\nWhen nilfs_btree_insert() receives this spurious \u0027not found\u0027 code from\\nnilfs_btree_do_lookup(), it misunderstands that the \u0027not found\u0027 check was\\nsuccessful and continues the insert operation using incomplete lookup path\\ndata, causing the following crash:\\n\\n general protection fault, probably for non-canonical address\\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\\n ...\\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c\\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\\n ...\\n Call Trace:\\n \u003cTASK\u003e\\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\\n __block_write_begin fs/buffer.c:2041 [inline]\\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\\n call_write_iter include/linux/fs.h:2186 [inline]\\n new_sync_write fs/read_write.c:491 [inline]\\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\\n ksys_write+0x177/0x2a0 fs/read_write.c:637\\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\\n ...\\n \u003c/TASK\u003e\\n\\nThis patch fixes the root cause of this problem by replacing the error\\ncode that __nilfs_btree_get_block() returns on block address conversion\\nfailure from -ENOENT to another internal code -EINVAL which means that the\\nb-tree metadata is corrupted.\\n\\nBy returning -EINVAL, it propagates without glitches, and for all relevant\\nb-tree operations, functions in the upper bmap layer output an error\\nmessage indicating corrupted b-tree metadata via\\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\\nit should be.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: soluciona el fallo de protecci\u00f3n general en nilfs_btree_insert() Si nilfs2 lee una imagen de disco corrupta e intenta leer un bloque de nodo de \u00e1rbol b llamando a __nilfs_btree_get_block() contra una direcci\u00f3n de bloque virtual no v\u00e1lida, devuelve -ENOENT porque falla la conversi\u00f3n de la direcci\u00f3n del bloque virtual a una direcci\u00f3n de bloque de disco. Sin embargo, este valor de retorno es el mismo que el c\u00f3digo interno que devuelven las rutinas de b\u00fasqueda del \u00e1rbol b para indicar que el bloque que se busca no existe, por lo que las funciones que operan en ese \u00e1rbol b pueden comportarse mal. Cuando nilfs_btree_insert() recibe este c\u00f3digo falso \u0027no encontrado\u0027 de nilfs_btree_do_lookup(), malinterpreta que la verificaci\u00f3n \u0027no encontrado\u0027 fue exitosa y contin\u00faa la operaci\u00f3n de inserci\u00f3n utilizando datos de ruta de b\u00fasqueda incompletos, lo que provoca el siguiente bloqueo: falla de protecci\u00f3n general, probablemente por direcci\u00f3n no can\u00f3nica 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs 2/btree.c:418 [en l\u00ednea] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [en l\u00ednea] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 C\u00f3digo: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 3 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b f 49 83 c7 02... Seguimiento de llamadas: nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [en l\u00ednea] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c: 101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [en l\u00ednea] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c :261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [en l\u00ednea] new_sync_write fs/read_write.c:491 [en l\u00ednea] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64 +0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd ... Este parche soluciona la causa ra\u00edz de este problema reemplazando el c\u00f3digo de error que devuelve __nilfs_btree_get_block() en la conversi\u00f3n de direcciones de bloque falla de -ENOENT a otro c\u00f3digo interno -EINVAL, lo que significa que los metadatos del \u00e1rbol b est\u00e1n da\u00f1ados. Al devolver -EINVAL, se propaga sin fallos y, para todas las operaciones relevantes del \u00e1rbol b, las funciones en la capa superior del mapa b generan un mensaje de error que indica metadatos del \u00e1rbol b corruptos a trav\u00e9s de nilfs_bmap_convert_error(), y el c\u00f3digo -EIO se devolver\u00e1 eventualmente cuando deber\u00eda ser.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"fs/nilfs2/btree.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"3c2a2ff67d46106715c2132021b98bd057c27545\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"d9fde9eab1766170ff2ade67d09178d2cfd78749\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"b0ba060d3287108eba17603bee3810e4cf2c272d\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"712bd74eccb9d3626a0a236641962eca8e11a243\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"45627a1a6450662e1e0f8174ef07b05710a20062\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"a60be987d45dd510aeb54389526f9957cfab106c\",\"lessThan\":\"7633355e5c7f29c049a9048e461427d1d8ed3051\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"fs/nilfs2/btree.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"2.6.30\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"2.6.30\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.14.304\",\"lessThanOrEqual\":\"4.14.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.19.271\",\"lessThanOrEqual\":\"4.19.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.4.230\",\"lessThanOrEqual\":\"5.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.165\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.90\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.8\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.2\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2024-09-10T16:03:31.052227Z\",\"id\":\"CVE-2023-52900\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"4.14.304\",\"matchCriteriaId\":\"E8A9B982-D3D6-49CA-BF0A-196ED7947B3A\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.15\",\"versionEndExcluding\":\"4.19.271\",\"matchCriteriaId\":\"D86DA289-B5BC-4629-BD56-AB453D481393\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.20\",\"versionEndExcluding\":\"5.4.230\",\"matchCriteriaId\":\"9DB7398D-9781-49C5-B2AE-1969B694B614\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.165\",\"matchCriteriaId\":\"C6002D5B-9B6A-4788-B943-E3EE01E01303\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.90\",\"matchCriteriaId\":\"E995CDA5-7223-4FDB-BAD3-81B22C763A43\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.8\",\"matchCriteriaId\":\"A6AFE6C9-3F59-4711-B2CF-7D6682FF6BD0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"FF501633-2F44-4913-A8EE-B021929F49F6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"2BDA597B-CAC1-4DF0-86F0-42E142C654E9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"725C78C9-12CE-406F-ABE8-0813A01D66E8\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"A127C155-689C-4F67-B146-44A57F4BFD85\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T14:34:11+00:00",
"cve": "CVE-2023-52900",
"id": "CVE-2023-52900",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: nilfs2: fix general protection fault in nilfs_btree_insert()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52900.json",
"version": "3"
},
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2023-52900\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-10T16:03:31.052227Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-11T12:42:19.005Z\"}}], \"cna\": {\"title\": \"nilfs2: fix general protection fault in nilfs_btree_insert()\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"3c2a2ff67d46106715c2132021b98bd057c27545\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"d9fde9eab1766170ff2ade67d09178d2cfd78749\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"b0ba060d3287108eba17603bee3810e4cf2c272d\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"712bd74eccb9d3626a0a236641962eca8e11a243\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"45627a1a6450662e1e0f8174ef07b05710a20062\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"a60be987d45dd510aeb54389526f9957cfab106c\", \"lessThan\": \"7633355e5c7f29c049a9048e461427d1d8ed3051\", \"versionType\": \"git\"}], \"programFiles\": [\"fs/nilfs2/btree.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"2.6.30\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"2.6.30\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"4.14.304\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.14.*\"}, {\"status\": \"unaffected\", \"version\": \"4.19.271\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.19.*\"}, {\"status\": \"unaffected\", \"version\": \"5.4.230\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.4.*\"}, {\"status\": \"unaffected\", \"version\": \"5.10.165\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.10.*\"}, {\"status\": \"unaffected\", \"version\": \"5.15.90\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1.8\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.2\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"fs/nilfs2/btree.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545\"}, {\"url\": \"https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749\"}, {\"url\": \"https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d\"}, {\"url\": \"https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243\"}, {\"url\": \"https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062\"}, {\"url\": \"https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\"}, {\"url\": \"https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnilfs2: fix general protection fault in nilfs_btree_insert()\\n\\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\\nblock by calling __nilfs_btree_get_block() against an invalid virtual\\nblock address, it returns -ENOENT because conversion of the virtual block\\naddress to a disk block address fails. However, this return value is the\\nsame as the internal code that b-tree lookup routines return to indicate\\nthat the block being searched does not exist, so functions that operate on\\nthat b-tree may misbehave.\\n\\nWhen nilfs_btree_insert() receives this spurious \u0027not found\u0027 code from\\nnilfs_btree_do_lookup(), it misunderstands that the \u0027not found\u0027 check was\\nsuccessful and continues the insert operation using incomplete lookup path\\ndata, causing the following crash:\\n\\n general protection fault, probably for non-canonical address\\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\\n ...\\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c\\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\\n ...\\n Call Trace:\\n \u003cTASK\u003e\\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\\n __block_write_begin fs/buffer.c:2041 [inline]\\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\\n call_write_iter include/linux/fs.h:2186 [inline]\\n new_sync_write fs/read_write.c:491 [inline]\\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\\n ksys_write+0x177/0x2a0 fs/read_write.c:637\\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\\n ...\\n \u003c/TASK\u003e\\n\\nThis patch fixes the root cause of this problem by replacing the error\\ncode that __nilfs_btree_get_block() returns on block address conversion\\nfailure from -ENOENT to another internal code -EINVAL which means that the\\nb-tree metadata is corrupted.\\n\\nBy returning -EINVAL, it propagates without glitches, and for all relevant\\nb-tree operations, functions in the upper bmap layer output an error\\nmessage indicating corrupted b-tree metadata via\\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\\nit should be.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.14.304\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.19.271\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.4.230\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.10.165\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.90\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.8\", \"versionStartIncluding\": \"2.6.30\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.2\", \"versionStartIncluding\": \"2.6.30\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-05-11T19:35:09.947Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2023-52900\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-05-11T19:35:09.947Z\", \"dateReserved\": \"2024-08-21T06:07:11.014Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-08-21T06:10:40.533Z\", \"assignerShortName\": \"Linux\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
BDU:2024-07450 (CVE-2023-52900)
Vulnerability from fstec – Published: 2024-09-24 – Updated: 2024-11-26 – View on bdu.fstec.ru Fixed- CWE-476 - Разыменование указателя NULL
{
"CVSS 2.0": "AV:L/AC:L/Au:S/C:N/I:N/A:C",
"CVSS 3.0": "AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"CVSS 4.0": null,
"remediation_\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": null,
"remediation_\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435": null,
"\u0412\u0435\u043d\u0434\u043e\u0440 \u041f\u041e": "\u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, \u041e\u041e\u041e \u00ab\u0420\u0435\u0434 \u0421\u043e\u0444\u0442\u00bb",
"\u0412\u0435\u0440\u0441\u0438\u044f \u041f\u041e": "11 (Debian GNU/Linux), 12 (Debian GNU/Linux), 7.3 (\u0420\u0415\u0414 \u041e\u0421), \u043e\u0442 5.16 \u0434\u043e 6.1.7 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 5.5 \u0434\u043e 5.10.164 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 5.11 \u0434\u043e 5.15.89 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 4.0 \u0434\u043e 4.14.303 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 4.15 \u0434\u043e 4.19.270 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux), \u043e\u0442 4.20 \u0434\u043e 5.4.229 \u0432\u043a\u043b\u044e\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e (Linux)",
"\u0412\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0435 \u043c\u0435\u0440\u044b \u043f\u043e \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044e": "\u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u043e\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u0435\u0442\u0441\u044f \u043f\u0440\u0438\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0442\u044c\u0441\u044f \"\u0420\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0439 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c LINUX\", \u0438\u0437\u043b\u043e\u0436\u0435\u043d\u043d\u044b\u0445 \u0432 \u043c\u0435\u0442\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0435 \u0424\u0421\u0422\u042d\u041a \u0420\u043e\u0441\u0441\u0438\u0438, \u0443\u0442\u0432\u0435\u0440\u0436\u0434\u0451\u043d\u043d\u043e\u043c 25 \u0434\u0435\u043a\u0430\u0431\u0440\u044f 2022 \u0433\u043e\u0434\u0430.\n\n\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439:\n\u0414\u043b\u044f Linux:\nhttps://git.kernel.org/linus/7633355e5c7f29c049a9048e461427d1d8ed3051\nhttps://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\nhttps://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545\nhttps://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062\nhttps://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243\nhttps://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051\nhttps://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d\nhttps://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749\nhttps://kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.304\nhttps://kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.271\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.165\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.90\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.230\nhttps://kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.8\nhttps://lore.kernel.org/linux-cve-announce/2024082112-CVE-2023-52900-32f2@gregkh/\n\n\u0414\u043b\u044f \u0420\u0435\u0434\u041e\u0421: http://repo.red-soft.ru/redos/7.3c/x86_64/updates/\n\n\u0414\u043b\u044f Debian GNU/Linux:\nhttps://security-tracker.debian.org/tracker/CVE-2023-52900",
"\u0414\u0430\u0442\u0430 \u0432\u044b\u044f\u0432\u043b\u0435\u043d\u0438\u044f": "11.01.2023",
"\u0414\u0430\u0442\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0433\u043e \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f": "26.11.2024",
"\u0414\u0430\u0442\u0430 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438": "24.09.2024",
"\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440": "BDU:2024-07450",
"\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440\u044b \u0434\u0440\u0443\u0433\u0438\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0439 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "CVE-2023-52900",
"\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0430",
"\u041a\u043b\u0430\u0441\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043a\u043e\u0434\u0430",
"\u041d\u0430\u0437\u0432\u0430\u043d\u0438\u0435 \u041f\u041e": "Debian GNU/Linux, \u0420\u0415\u0414 \u041e\u0421 (\u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0435\u0434\u0438\u043d\u043e\u043c \u0440\u0435\u0435\u0441\u0442\u0440\u0435 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c \u21163751), Linux",
"\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u041e\u0421 \u0438 \u0442\u0438\u043f \u0430\u043f\u043f\u0430\u0440\u0430\u0442\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b": "\u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Debian GNU/Linux 11 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Debian GNU/Linux 12 , \u041e\u041e\u041e \u00ab\u0420\u0435\u0434 \u0421\u043e\u0444\u0442\u00bb \u0420\u0415\u0414 \u041e\u0421 7.3 (\u0437\u0430\u043f\u0438\u0441\u044c \u0432 \u0435\u0434\u0438\u043d\u043e\u043c \u0440\u0435\u0435\u0441\u0442\u0440\u0435 \u0440\u043e\u0441\u0441\u0438\u0439\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c \u21163751), \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 5.11 \u0434\u043e 5.15.90 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 5.16 \u0434\u043e 6.1.8 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux 6.2 rc1 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux 6.2 rc2 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux 6.2 rc3 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux 6.2 rc4 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 4.20 \u0434\u043e 5.4.230 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 5.5 \u0434\u043e 5.10.165 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u0434\u043e 4.14.304 , \u0421\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f Linux \u043e\u0442 4.15 \u0434\u043e 4.19.271 ",
"\u041d\u0430\u0438\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432 nilfs2 \u044f\u0434\u0440\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b Linux, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u0430\u044f \u0441 \u0440\u0430\u0437\u044b\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435\u043c NULL \u0443\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044f, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e \u0432\u044b\u0437\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u0432 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u043d\u0438\u0438",
"\u041d\u0430\u043b\u0438\u0447\u0438\u0435 \u044d\u043a\u0441\u043f\u043b\u043e\u0439\u0442\u0430": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
"\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "\u0420\u0430\u0437\u044b\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435 \u0443\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044f NULL (CWE-476)",
"\u041e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0423\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u043e\u0432 nilfs2 \u044f\u0434\u0440\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b Linux \u0441\u0432\u044f\u0437\u0430\u043d\u0430 \u0441 \u0440\u0430\u0437\u044b\u043c\u0435\u043d\u043e\u0432\u0430\u043d\u0438\u0435\u043c NULL \u0443\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044f. \u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u043d\u0430\u0440\u0443\u0448\u0438\u0442\u0435\u043b\u044e \u0432\u044b\u0437\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u0432 \u043e\u0431\u0441\u043b\u0443\u0436\u0438\u0432\u0430\u043d\u0438\u0438",
"\u041f\u043e\u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u044f \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": null,
"\u041f\u0440\u043e\u0447\u0430\u044f \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f": null,
"\u0421\u0432\u044f\u0437\u044c \u0441 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u0430\u043c\u0438 \u0418\u0411": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0443\u0442\u043e\u0447\u043d\u044f\u044e\u0442\u0441\u044f",
"\u0421\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u0430",
"\u0421\u043f\u043e\u0441\u043e\u0431 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u044f": "\u041e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f",
"\u0421\u043f\u043e\u0441\u043e\u0431 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438": "\u041c\u0430\u043d\u0438\u043f\u0443\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445",
"\u0421\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0438": "https://git.kernel.org/linus/7633355e5c7f29c049a9048e461427d1d8ed3051\nhttps://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04\nhttps://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545\nhttps://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062\nhttps://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243\nhttps://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051\nhttps://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d\nhttps://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749\nhttps://kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.304\nhttps://kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.271\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.165\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.90\nhttps://kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.230\nhttps://kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.8\nhttps://lore.kernel.org/linux-cve-announce/2024082112-CVE-2023-52900-32f2@gregkh/\nhttps://redos.red-soft.ru/support/secure/\nhttps://security-tracker.debian.org/tracker/CVE-2023-52900\nhttps://www.cve.org/CVERecord?id=CVE-2023-52900",
"\u0421\u0442\u0430\u0442\u0443\u0441 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u041f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c",
"\u0422\u0438\u043f \u041f\u041e": "\u041e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430",
"\u0422\u0438\u043f \u043e\u0448\u0438\u0431\u043a\u0438 CWE": "CWE-476",
"\u0423\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438": "\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 2.0 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 4,6)\n\u0421\u0440\u0435\u0434\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 3.0 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 5,5)\n\u041d\u0435\u0442 \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 (\u0431\u0430\u0437\u043e\u0432\u0430\u044f \u043e\u0446\u0435\u043d\u043a\u0430 CVSS 4.0 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u0442 0)"
}
CERTFR-2024-AVI-0779
Vulnerability from certfr_avis - Published: 2024-09-13 - Updated: 2024-09-13
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).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.3 | ||
| SUSE | N/A | openSUSE Leap Micro 5.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| 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 | Public Cloud Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | Public Cloud Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 12 SP5 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| 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 for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| 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 Real Time Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| 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 |
| Title | Publication Time | Tags | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"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 Linux Enterprise Micro 5.3",
"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": "Public Cloud Module 15-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": "Public Cloud Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 12 SP5",
"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 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 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 15-SP5",
"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 Real Time Module 15-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": "SUSE Linux Enterprise Micro 5.4",
"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": "",
"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-2023-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3610"
},
{
"name": "CVE-2022-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40133"
},
{
"name": "CVE-2022-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38457"
},
{
"name": "CVE-2023-52458",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52458"
},
{
"name": "CVE-2024-26631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26631"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26590"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26809"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2023-52489",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52489"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2023-52498",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52498"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26808"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2021-47289",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47289"
},
{
"name": "CVE-2021-47341",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47341"
},
{
"name": "CVE-2021-47373",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47373"
},
{
"name": "CVE-2021-47425",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47425"
},
{
"name": "CVE-2021-47549",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47549"
},
{
"name": "CVE-2023-52708",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52708"
},
{
"name": "CVE-2023-52756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52756"
},
{
"name": "CVE-2023-52766",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52766"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-35965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35965"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-36936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36936"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2024-36288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36288"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-27403",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27403"
},
{
"name": "CVE-2024-26944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26944"
},
{
"name": "CVE-2024-27049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27049"
},
{
"name": "CVE-2024-27050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27050"
},
{
"name": "CVE-2024-27079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27079"
},
{
"name": "CVE-2024-27433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27433"
},
{
"name": "CVE-2022-48751",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48751"
},
{
"name": "CVE-2022-48769",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48769"
},
{
"name": "CVE-2023-52735",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52735"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-35913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35913"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-38662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38662"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2024-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-39488",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39488"
},
{
"name": "CVE-2024-39489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39489"
},
{
"name": "CVE-2024-39493",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39493"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-39500",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39500"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-39510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39510"
},
{
"name": "CVE-2024-40899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40899"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-40903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40903"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-40910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40910"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-40913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40913"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-40920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40920"
},
{
"name": "CVE-2024-40921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40921"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-40938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40938"
},
{
"name": "CVE-2024-40939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40939"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-40956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40956"
},
{
"name": "CVE-2024-40957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40957"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-40967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40967"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40994"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41001"
},
{
"name": "CVE-2024-41002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41002"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2022-48808",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48808"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2024-36881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36881"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-38563",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38563"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2021-47257",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47257"
},
{
"name": "CVE-2023-52885",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52885"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2021-47546",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47546"
},
{
"name": "CVE-2022-48775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48775"
},
{
"name": "CVE-2022-48778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48778"
},
{
"name": "CVE-2022-48786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48786"
},
{
"name": "CVE-2022-48787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48787"
},
{
"name": "CVE-2022-48788",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48788"
},
{
"name": "CVE-2022-48789",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48789"
},
{
"name": "CVE-2022-48790",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48790"
},
{
"name": "CVE-2022-48798",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48798"
},
{
"name": "CVE-2022-48802",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48802"
},
{
"name": "CVE-2022-48805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48805"
},
{
"name": "CVE-2022-48811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48811"
},
{
"name": "CVE-2022-48822",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48822"
},
{
"name": "CVE-2022-48823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48823"
},
{
"name": "CVE-2022-48824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48824"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2022-48834",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48834"
},
{
"name": "CVE-2022-48835",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48835"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2022-48837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48837"
},
{
"name": "CVE-2022-48838",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48838"
},
{
"name": "CVE-2022-48839",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48839"
},
{
"name": "CVE-2022-48843",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48843"
},
{
"name": "CVE-2022-48851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48851"
},
{
"name": "CVE-2022-48853",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48853"
},
{
"name": "CVE-2022-48856",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48856"
},
{
"name": "CVE-2022-48857",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48857"
},
{
"name": "CVE-2022-48858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48858"
},
{
"name": "CVE-2023-52886",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52886"
},
{
"name": "CVE-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-40982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40982"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-41048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41048"
},
{
"name": "CVE-2024-41057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41057"
},
{
"name": "CVE-2024-41058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41058"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-41071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41071"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-42119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42119"
},
{
"name": "CVE-2024-42120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42120"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-40936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40936"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-39483",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39483"
},
{
"name": "CVE-2024-39491",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39491"
},
{
"name": "CVE-2024-40922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40922"
},
{
"name": "CVE-2024-40926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40926"
},
{
"name": "CVE-2024-40930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40930"
},
{
"name": "CVE-2024-40944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40944"
},
{
"name": "CVE-2024-40962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40962"
},
{
"name": "CVE-2024-40964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40964"
},
{
"name": "CVE-2024-40992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40992"
},
{
"name": "CVE-2024-40997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40997"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2024-42270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42270"
},
{
"name": "CVE-2021-4440",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4440"
},
{
"name": "CVE-2021-4441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4441"
},
{
"name": "CVE-2021-47106",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47106"
},
{
"name": "CVE-2021-47517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47517"
},
{
"name": "CVE-2022-48645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48645"
},
{
"name": "CVE-2022-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48706"
},
{
"name": "CVE-2022-48865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48865"
},
{
"name": "CVE-2022-48868",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48868"
},
{
"name": "CVE-2022-48869",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48869"
},
{
"name": "CVE-2022-48870",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48870"
},
{
"name": "CVE-2022-48871",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48871"
},
{
"name": "CVE-2022-48872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48872"
},
{
"name": "CVE-2022-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48873"
},
{
"name": "CVE-2022-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48875"
},
{
"name": "CVE-2022-48878",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48878"
},
{
"name": "CVE-2022-48880",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48880"
},
{
"name": "CVE-2022-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48881"
},
{
"name": "CVE-2022-48882",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48882"
},
{
"name": "CVE-2022-48883",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48883"
},
{
"name": "CVE-2022-48884",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48884"
},
{
"name": "CVE-2022-48885",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48885"
},
{
"name": "CVE-2022-48886",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48886"
},
{
"name": "CVE-2022-48887",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48887"
},
{
"name": "CVE-2022-48888",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48888"
},
{
"name": "CVE-2022-48889",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48889"
},
{
"name": "CVE-2022-48890",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48890"
},
{
"name": "CVE-2022-48891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48891"
},
{
"name": "CVE-2022-48893",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48893"
},
{
"name": "CVE-2022-48896",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48896"
},
{
"name": "CVE-2022-48898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48898"
},
{
"name": "CVE-2022-48899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48899"
},
{
"name": "CVE-2022-48901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48901"
},
{
"name": "CVE-2022-48903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48903"
},
{
"name": "CVE-2022-48904",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48904"
},
{
"name": "CVE-2022-48905",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48905"
},
{
"name": "CVE-2022-48906",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48906"
},
{
"name": "CVE-2022-48907",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48907"
},
{
"name": "CVE-2022-48909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48909"
},
{
"name": "CVE-2022-48910",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48910"
},
{
"name": "CVE-2022-48912",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48912"
},
{
"name": "CVE-2022-48913",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48913"
},
{
"name": "CVE-2022-48914",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48914"
},
{
"name": "CVE-2022-48915",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48915"
},
{
"name": "CVE-2022-48916",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48916"
},
{
"name": "CVE-2022-48917",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48917"
},
{
"name": "CVE-2022-48918",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48918"
},
{
"name": "CVE-2022-48919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48919"
},
{
"name": "CVE-2022-48920",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48920"
},
{
"name": "CVE-2022-48921",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48921"
},
{
"name": "CVE-2022-48923",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48923"
},
{
"name": "CVE-2022-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48924"
},
{
"name": "CVE-2022-48925",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48925"
},
{
"name": "CVE-2022-48926",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48926"
},
{
"name": "CVE-2022-48927",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48927"
},
{
"name": "CVE-2022-48928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48928"
},
{
"name": "CVE-2022-48929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48929"
},
{
"name": "CVE-2022-48930",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48930"
},
{
"name": "CVE-2022-48931",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48931"
},
{
"name": "CVE-2022-48932",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48932"
},
{
"name": "CVE-2022-48933",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48933"
},
{
"name": "CVE-2022-48934",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48934"
},
{
"name": "CVE-2022-48935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
},
{
"name": "CVE-2022-48937",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48937"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2022-48939",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48939"
},
{
"name": "CVE-2022-48940",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48940"
},
{
"name": "CVE-2022-48941",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48941"
},
{
"name": "CVE-2022-48942",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48942"
},
{
"name": "CVE-2022-48943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
},
{
"name": "CVE-2023-52668",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52668"
},
{
"name": "CVE-2023-52688",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52688"
},
{
"name": "CVE-2023-52802",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52802"
},
{
"name": "CVE-2023-52859",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52859"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2023-52893",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52893"
},
{
"name": "CVE-2023-52894",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52894"
},
{
"name": "CVE-2023-52896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52896"
},
{
"name": "CVE-2023-52898",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52898"
},
{
"name": "CVE-2023-52899",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52899"
},
{
"name": "CVE-2023-52900",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52900"
},
{
"name": "CVE-2023-52901",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52901"
},
{
"name": "CVE-2023-52904",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52904"
},
{
"name": "CVE-2023-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52905"
},
{
"name": "CVE-2023-52906",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52906"
},
{
"name": "CVE-2023-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52907"
},
{
"name": "CVE-2023-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52908"
},
{
"name": "CVE-2023-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52909"
},
{
"name": "CVE-2023-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52910"
},
{
"name": "CVE-2023-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52911"
},
{
"name": "CVE-2023-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52912"
},
{
"name": "CVE-2023-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52913"
},
{
"name": "CVE-2024-26637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26637"
},
{
"name": "CVE-2024-26682",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26682"
},
{
"name": "CVE-2024-26683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26683"
},
{
"name": "CVE-2024-26849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26849"
},
{
"name": "CVE-2024-36907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36907"
},
{
"name": "CVE-2024-36970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36970"
},
{
"name": "CVE-2024-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38609"
},
{
"name": "CVE-2024-39486",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39486"
},
{
"name": "CVE-2024-41010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41010"
},
{
"name": "CVE-2024-41024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41024"
},
{
"name": "CVE-2024-41025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41025"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41032"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41037",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41037"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41061"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41084"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41094"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42064"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42107"
},
{
"name": "CVE-2024-42113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42113"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2024-42125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42125"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42132",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42132"
},
{
"name": "CVE-2024-42133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42133"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42139"
},
{
"name": "CVE-2024-42141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42141"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42144"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42159"
},
{
"name": "CVE-2024-42162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42162"
},
{
"name": "CVE-2024-42226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42226"
},
{
"name": "CVE-2024-42227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42227"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42241"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42268"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42278"
},
{
"name": "CVE-2024-42279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42279"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42298"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42303"
},
{
"name": "CVE-2024-42308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42308"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42314",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42314"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-42316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42316"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-43816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43816"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43818"
},
{
"name": "CVE-2024-43819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43819"
},
{
"name": "CVE-2024-43821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43821"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2024-43824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43824"
},
{
"name": "CVE-2024-43825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43825"
},
{
"name": "CVE-2024-43826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43826"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2024-43833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43833"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43837"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43840"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43847"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43850"
},
{
"name": "CVE-2024-43851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43851"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43864"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43874"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43876"
},
{
"name": "CVE-2024-43877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43877"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43881"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43885"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43895"
},
{
"name": "CVE-2024-43897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43897"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43903"
},
{
"name": "CVE-2024-43904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43904"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43906"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-44931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44931"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
}
],
"initial_release_date": "2024-09-13T00:00:00",
"last_revision_date": "2024-09-13T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-0779",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-09-13T00: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-10",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3189-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243189-1"
},
{
"published_at": "2024-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3195-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243195-1"
},
{
"published_at": "2024-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3190-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243190-1"
},
{
"published_at": "2024-09-12",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3225-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243225-1"
},
{
"published_at": "2024-09-12",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3227-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243227-1"
},
{
"published_at": "2024-09-11",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3209-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243209-1"
},
{
"published_at": "2024-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3194-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243194-1"
}
]
}
CERTFR-2024-AVI-0822
Vulnerability from certfr_avis - Published: 2024-09-27 - Updated: 2024-09-27
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 exécution de code arbitraire, une élévation de privilèges et une atteinte à la confidentialité 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 | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.5 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | SUSE Manager Retail Branch Server | SUSE Manager Retail Branch Server 4.3 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.4 | ||
| SUSE | Basesystem Module | Basesystem Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro for Rancher 5.4 | ||
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.6 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | Legacy Module 15-SP6 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro for Rancher 5.3 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | SUSE Manager Proxy | SUSE Manager Proxy 4.3 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Desktop | SUSE Linux Enterprise Desktop 15 SP6 | ||
| SUSE | SUSE Linux Enterprise Desktop | SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 15 SP6 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.5 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | SUSE Manager Server | SUSE Manager Server 4.3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP6 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | N/A | Development Tools Module 15-SP6 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.3",
"product": {
"name": "SUSE Manager Retail Branch Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Basesystem Module 15-SP6",
"product": {
"name": "Basesystem Module",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP4",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.4",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Legacy Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.3",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.3",
"product": {
"name": "SUSE Manager Proxy",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Desktop",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4",
"product": {
"name": "SUSE Linux Enterprise Desktop",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.3",
"product": {
"name": "SUSE Manager Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Development Tools Module 15-SP6",
"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-2022-4382",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4382"
},
{
"name": "CVE-2023-6546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6546"
},
{
"name": "CVE-2023-52340",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52340"
},
{
"name": "CVE-2024-26622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26622"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2024-26631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26631"
},
{
"name": "CVE-2024-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23307"
},
{
"name": "CVE-2024-26766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26766"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26590"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26809"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2023-52489",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52489"
},
{
"name": "CVE-2024-26610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26610"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-26808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26808"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2022-48651",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48651"
},
{
"name": "CVE-2022-48662",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48662"
},
{
"name": "CVE-2024-26930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26930"
},
{
"name": "CVE-2024-26828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26828"
},
{
"name": "CVE-2024-27398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27398"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-35817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35817"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2023-52772",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52772"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2024-36288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36288"
},
{
"name": "CVE-2024-27403",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27403"
},
{
"name": "CVE-2024-26944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26944"
},
{
"name": "CVE-2024-27049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27049"
},
{
"name": "CVE-2024-27050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27050"
},
{
"name": "CVE-2024-27079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27079"
},
{
"name": "CVE-2024-27433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27433"
},
{
"name": "CVE-2023-52735",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52735"
},
{
"name": "CVE-2023-52846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52846"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-35913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35913"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-38662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38662"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2024-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-39488",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39488"
},
{
"name": "CVE-2024-39489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39489"
},
{
"name": "CVE-2024-39493",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39493"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-39500",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39500"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-39510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39510"
},
{
"name": "CVE-2024-40899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40899"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-40903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40903"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-40910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40910"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-40913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40913"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-40920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40920"
},
{
"name": "CVE-2024-40921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40921"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-40938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40938"
},
{
"name": "CVE-2024-40939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40939"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-40956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40956"
},
{
"name": "CVE-2024-40957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40957"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-40967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40967"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40994"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41001"
},
{
"name": "CVE-2024-41002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41002"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2024-36881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36881"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-38563",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38563"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2023-52885",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52885"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2023-52886",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52886"
},
{
"name": "CVE-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-40982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40982"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-41048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41048"
},
{
"name": "CVE-2024-41057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41057"
},
{
"name": "CVE-2024-41058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41058"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-41071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41071"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-42119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42119"
},
{
"name": "CVE-2024-42120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42120"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-40936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40936"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-39483",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39483"
},
{
"name": "CVE-2024-39491",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39491"
},
{
"name": "CVE-2024-40922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40922"
},
{
"name": "CVE-2024-40926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40926"
},
{
"name": "CVE-2024-40930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40930"
},
{
"name": "CVE-2024-40944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40944"
},
{
"name": "CVE-2024-40962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40962"
},
{
"name": "CVE-2024-40964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40964"
},
{
"name": "CVE-2024-40992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40992"
},
{
"name": "CVE-2024-40997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40997"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2024-42270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42270"
},
{
"name": "CVE-2021-4441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4441"
},
{
"name": "CVE-2022-48868",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48868"
},
{
"name": "CVE-2022-48869",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48869"
},
{
"name": "CVE-2022-48870",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48870"
},
{
"name": "CVE-2022-48871",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48871"
},
{
"name": "CVE-2022-48872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48872"
},
{
"name": "CVE-2022-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48873"
},
{
"name": "CVE-2022-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48875"
},
{
"name": "CVE-2022-48878",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48878"
},
{
"name": "CVE-2022-48880",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48880"
},
{
"name": "CVE-2022-48890",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48890"
},
{
"name": "CVE-2022-48891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48891"
},
{
"name": "CVE-2022-48896",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48896"
},
{
"name": "CVE-2022-48898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48898"
},
{
"name": "CVE-2022-48899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48899"
},
{
"name": "CVE-2022-48903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48903"
},
{
"name": "CVE-2022-48904",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48904"
},
{
"name": "CVE-2022-48905",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48905"
},
{
"name": "CVE-2022-48907",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48907"
},
{
"name": "CVE-2022-48909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48909"
},
{
"name": "CVE-2022-48912",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48912"
},
{
"name": "CVE-2022-48913",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48913"
},
{
"name": "CVE-2022-48914",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48914"
},
{
"name": "CVE-2022-48915",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48915"
},
{
"name": "CVE-2022-48916",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48916"
},
{
"name": "CVE-2022-48917",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48917"
},
{
"name": "CVE-2022-48918",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48918"
},
{
"name": "CVE-2022-48919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48919"
},
{
"name": "CVE-2022-48921",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48921"
},
{
"name": "CVE-2022-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48924"
},
{
"name": "CVE-2022-48925",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48925"
},
{
"name": "CVE-2022-48926",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48926"
},
{
"name": "CVE-2022-48927",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48927"
},
{
"name": "CVE-2022-48928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48928"
},
{
"name": "CVE-2022-48929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48929"
},
{
"name": "CVE-2022-48930",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48930"
},
{
"name": "CVE-2022-48931",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48931"
},
{
"name": "CVE-2022-48932",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48932"
},
{
"name": "CVE-2022-48934",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48934"
},
{
"name": "CVE-2022-48935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
},
{
"name": "CVE-2022-48937",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48937"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2022-48941",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48941"
},
{
"name": "CVE-2022-48942",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48942"
},
{
"name": "CVE-2022-48943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
},
{
"name": "CVE-2023-52668",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52668"
},
{
"name": "CVE-2023-52688",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52688"
},
{
"name": "CVE-2023-52859",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52859"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2023-52893",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52893"
},
{
"name": "CVE-2023-52894",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52894"
},
{
"name": "CVE-2023-52896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52896"
},
{
"name": "CVE-2023-52898",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52898"
},
{
"name": "CVE-2023-52900",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52900"
},
{
"name": "CVE-2023-52901",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52901"
},
{
"name": "CVE-2023-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52905"
},
{
"name": "CVE-2023-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52907"
},
{
"name": "CVE-2023-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52911"
},
{
"name": "CVE-2024-26637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26637"
},
{
"name": "CVE-2024-26682",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26682"
},
{
"name": "CVE-2024-26683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26683"
},
{
"name": "CVE-2024-26849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26849"
},
{
"name": "CVE-2024-36907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36907"
},
{
"name": "CVE-2024-36970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36970"
},
{
"name": "CVE-2024-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38609"
},
{
"name": "CVE-2024-39486",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39486"
},
{
"name": "CVE-2024-41010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41010"
},
{
"name": "CVE-2024-41024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41024"
},
{
"name": "CVE-2024-41025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41025"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41032"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41037",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41037"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41061"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41084"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41094"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42064"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42107"
},
{
"name": "CVE-2024-42113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42113"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2024-42125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42125"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42132",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42132"
},
{
"name": "CVE-2024-42133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42133"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42139"
},
{
"name": "CVE-2024-42141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42141"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42144"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42159"
},
{
"name": "CVE-2024-42162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42162"
},
{
"name": "CVE-2024-42226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42226"
},
{
"name": "CVE-2024-42227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42227"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42241"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42268"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42278"
},
{
"name": "CVE-2024-42279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42279"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42298"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42303"
},
{
"name": "CVE-2024-42308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42308"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42314",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42314"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-42316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42316"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-43816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43816"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43818"
},
{
"name": "CVE-2024-43819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43819"
},
{
"name": "CVE-2024-43821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43821"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2024-43824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43824"
},
{
"name": "CVE-2024-43825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43825"
},
{
"name": "CVE-2024-43826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43826"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2024-43833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43833"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43837"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43840"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43847"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43850"
},
{
"name": "CVE-2024-43851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43851"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43864"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43874"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43876"
},
{
"name": "CVE-2024-43877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43877"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43881"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43885"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43895"
},
{
"name": "CVE-2024-43897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43897"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43903"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43906"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-44931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44931"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
}
],
"initial_release_date": "2024-09-27T00:00:00",
"last_revision_date": "2024-09-27T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-0822",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-09-27T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"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 ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3398-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243398-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3399-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243399-1"
},
{
"published_at": "2024-09-24",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3425-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243425-1"
},
{
"published_at": "2024-09-24",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3408-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243408-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3370-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243370-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3403-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243403-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3387-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243387-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3379-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243379-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3368-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243368-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3363-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243363-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3405-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243405-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3365-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243365-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3361-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243361-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3383-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243383-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3395-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243395-1"
},
{
"published_at": "2024-09-23",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3375-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243375-1"
}
]
}
CERTFR-2024-AVI-0840
Vulnerability from certfr_avis - Published: 2024-10-04 - Updated: 2024-10-04
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 | Legacy Module 15-SP5 | ||
| SUSE | N/A | openSUSE Leap Micro 5.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 11 SP4 LTSS EXTREME CORE 11-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 11 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.1 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 | ||
| 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 for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | N/A | SUSE Manager Server 4.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 Business Critical Linux 15-SP2 | ||
| SUSE | N/A | SUSE Manager Proxy 4.1 | ||
| SUSE | N/A | Basesystem Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 15 SP5 | ||
| SUSE | N/A | Development Tools Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 | ||
| 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 |
| Title | Publication Time | Tags | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Legacy Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"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 Linux Enterprise Server for SAP Applications 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 11 SP4 LTSS EXTREME CORE 11-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 11 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2",
"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 Manager Retail Branch Server 4.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2",
"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 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 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.1",
"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 Linux Enterprise High Availability Extension 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2 Business Critical Linux 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Basesystem Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Development Tools Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2",
"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-2021-4204",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4204"
},
{
"name": "CVE-2022-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23222"
},
{
"name": "CVE-2022-20368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-20368"
},
{
"name": "CVE-2022-0854",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0854"
},
{
"name": "CVE-2022-2964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2964"
},
{
"name": "CVE-2022-28748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28748"
},
{
"name": "CVE-2022-0500",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0500"
},
{
"name": "CVE-2022-4382",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4382"
},
{
"name": "CVE-2023-1582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1582"
},
{
"name": "CVE-2023-2176",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2176"
},
{
"name": "CVE-2023-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3610"
},
{
"name": "CVE-2022-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40133"
},
{
"name": "CVE-2022-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38457"
},
{
"name": "CVE-2023-52458",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52458"
},
{
"name": "CVE-2024-26631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26631"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2023-52489",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52489"
},
{
"name": "CVE-2023-52498",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52498"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26808"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2022-48686",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48686"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-36936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36936"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2024-27403",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27403"
},
{
"name": "CVE-2024-27079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27079"
},
{
"name": "CVE-2023-52846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52846"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-38662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38662"
},
{
"name": "CVE-2024-39489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39489"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2022-48808",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48808"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2021-47546",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47546"
},
{
"name": "CVE-2022-48791",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
},
{
"name": "CVE-2022-48802",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48802"
},
{
"name": "CVE-2022-48805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48805"
},
{
"name": "CVE-2022-48839",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48839"
},
{
"name": "CVE-2022-48853",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48853"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-42119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42119"
},
{
"name": "CVE-2024-42120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42120"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2021-4441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4441"
},
{
"name": "CVE-2021-47106",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47106"
},
{
"name": "CVE-2021-47517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47517"
},
{
"name": "CVE-2022-48645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48645"
},
{
"name": "CVE-2022-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48706"
},
{
"name": "CVE-2022-48865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48865"
},
{
"name": "CVE-2022-48868",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48868"
},
{
"name": "CVE-2022-48869",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48869"
},
{
"name": "CVE-2022-48870",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48870"
},
{
"name": "CVE-2022-48871",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48871"
},
{
"name": "CVE-2022-48872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48872"
},
{
"name": "CVE-2022-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48873"
},
{
"name": "CVE-2022-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48875"
},
{
"name": "CVE-2022-48878",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48878"
},
{
"name": "CVE-2022-48880",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48880"
},
{
"name": "CVE-2022-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48881"
},
{
"name": "CVE-2022-48882",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48882"
},
{
"name": "CVE-2022-48883",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48883"
},
{
"name": "CVE-2022-48884",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48884"
},
{
"name": "CVE-2022-48885",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48885"
},
{
"name": "CVE-2022-48886",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48886"
},
{
"name": "CVE-2022-48887",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48887"
},
{
"name": "CVE-2022-48888",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48888"
},
{
"name": "CVE-2022-48889",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48889"
},
{
"name": "CVE-2022-48890",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48890"
},
{
"name": "CVE-2022-48891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48891"
},
{
"name": "CVE-2022-48893",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48893"
},
{
"name": "CVE-2022-48896",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48896"
},
{
"name": "CVE-2022-48898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48898"
},
{
"name": "CVE-2022-48899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48899"
},
{
"name": "CVE-2022-48901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48901"
},
{
"name": "CVE-2022-48903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48903"
},
{
"name": "CVE-2022-48904",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48904"
},
{
"name": "CVE-2022-48905",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48905"
},
{
"name": "CVE-2022-48906",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48906"
},
{
"name": "CVE-2022-48907",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48907"
},
{
"name": "CVE-2022-48909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48909"
},
{
"name": "CVE-2022-48910",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48910"
},
{
"name": "CVE-2022-48912",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48912"
},
{
"name": "CVE-2022-48913",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48913"
},
{
"name": "CVE-2022-48914",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48914"
},
{
"name": "CVE-2022-48915",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48915"
},
{
"name": "CVE-2022-48916",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48916"
},
{
"name": "CVE-2022-48917",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48917"
},
{
"name": "CVE-2022-48918",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48918"
},
{
"name": "CVE-2022-48919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48919"
},
{
"name": "CVE-2022-48920",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48920"
},
{
"name": "CVE-2022-48921",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48921"
},
{
"name": "CVE-2022-48923",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48923"
},
{
"name": "CVE-2022-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48924"
},
{
"name": "CVE-2022-48925",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48925"
},
{
"name": "CVE-2022-48926",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48926"
},
{
"name": "CVE-2022-48927",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48927"
},
{
"name": "CVE-2022-48928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48928"
},
{
"name": "CVE-2022-48929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48929"
},
{
"name": "CVE-2022-48930",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48930"
},
{
"name": "CVE-2022-48931",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48931"
},
{
"name": "CVE-2022-48932",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48932"
},
{
"name": "CVE-2022-48934",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48934"
},
{
"name": "CVE-2022-48937",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48937"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2022-48939",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48939"
},
{
"name": "CVE-2022-48940",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48940"
},
{
"name": "CVE-2022-48941",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48941"
},
{
"name": "CVE-2022-48942",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48942"
},
{
"name": "CVE-2022-48943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
},
{
"name": "CVE-2023-52859",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52859"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2023-52893",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52893"
},
{
"name": "CVE-2023-52894",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52894"
},
{
"name": "CVE-2023-52896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52896"
},
{
"name": "CVE-2023-52898",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52898"
},
{
"name": "CVE-2023-52899",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52899"
},
{
"name": "CVE-2023-52900",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52900"
},
{
"name": "CVE-2023-52901",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52901"
},
{
"name": "CVE-2023-52904",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52904"
},
{
"name": "CVE-2023-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52905"
},
{
"name": "CVE-2023-52906",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52906"
},
{
"name": "CVE-2023-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52907"
},
{
"name": "CVE-2023-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52908"
},
{
"name": "CVE-2023-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52909"
},
{
"name": "CVE-2023-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52910"
},
{
"name": "CVE-2023-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52911"
},
{
"name": "CVE-2023-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52912"
},
{
"name": "CVE-2023-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52913"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42107"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42139"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42162"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42268"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42308"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-43816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43816"
},
{
"name": "CVE-2024-43818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43818"
},
{
"name": "CVE-2024-43819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43819"
},
{
"name": "CVE-2024-43821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43821"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43837"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43895"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43903"
},
{
"name": "CVE-2024-43904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43904"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
}
],
"initial_release_date": "2024-10-04T00:00:00",
"last_revision_date": "2024-10-04T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-0840",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-10-04T00: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-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3467-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243467-1"
},
{
"published_at": "2024-09-30",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3499-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243499-1"
},
{
"published_at": "2024-09-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3483-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243483-1"
},
{
"published_at": "2024-09-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3468-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243468-1"
}
]
}
FKIE_CVE-2023-52900
Vulnerability from fkie_nvd - Published: 2024-08-21 07:15 - Updated: 2026-06-17 06:43| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.2 | |
| linux | linux_kernel | 6.2 | |
| linux | linux_kernel | 6.2 | |
| linux | linux_kernel | 6.2 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/nilfs2/btree.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c2a2ff67d46106715c2132021b98bd057c27545",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "d9fde9eab1766170ff2ade67d09178d2cfd78749",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "b0ba060d3287108eba17603bee3810e4cf2c272d",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "712bd74eccb9d3626a0a236641962eca8e11a243",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "45627a1a6450662e1e0f8174ef07b05710a20062",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "0bf463939c09e5b2c35c71ed74a5fd60a74d6a04",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
},
{
"lessThan": "7633355e5c7f29c049a9048e461427d1d8ed3051",
"status": "affected",
"version": "a60be987d45dd510aeb54389526f9957cfab106c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/nilfs2/btree.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.304",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.271",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.165",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.90",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E8A9B982-D3D6-49CA-BF0A-196ED7947B3A",
"versionEndExcluding": "4.14.304",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D86DA289-B5BC-4629-BD56-AB453D481393",
"versionEndExcluding": "4.19.271",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9DB7398D-9781-49C5-B2AE-1969B694B614",
"versionEndExcluding": "5.4.230",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C6002D5B-9B6A-4788-B943-E3EE01E01303",
"versionEndExcluding": "5.10.165",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E995CDA5-7223-4FDB-BAD3-81B22C763A43",
"versionEndExcluding": "5.15.90",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A6AFE6C9-3F59-4711-B2CF-7D6682FF6BD0",
"versionEndExcluding": "6.1.8",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*",
"matchCriteriaId": "FF501633-2F44-4913-A8EE-B021929F49F6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*",
"matchCriteriaId": "2BDA597B-CAC1-4DF0-86F0-42E142C654E9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*",
"matchCriteriaId": "725C78C9-12CE-406F-ABE8-0813A01D66E8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*",
"matchCriteriaId": "A127C155-689C-4F67-B146-44A57F4BFD85",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix general protection fault in nilfs_btree_insert()\n\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\n\nWhen nilfs_btree_insert() receives this spurious \u0027not found\u0027 code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0027not found\u0027 check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\n\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u003cTASK\u003e\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u003c/TASK\u003e\n\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\n\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: soluciona el fallo de protecci\u00f3n general en nilfs_btree_insert() Si nilfs2 lee una imagen de disco corrupta e intenta leer un bloque de nodo de \u00e1rbol b llamando a __nilfs_btree_get_block() contra una direcci\u00f3n de bloque virtual no v\u00e1lida, devuelve -ENOENT porque falla la conversi\u00f3n de la direcci\u00f3n del bloque virtual a una direcci\u00f3n de bloque de disco. Sin embargo, este valor de retorno es el mismo que el c\u00f3digo interno que devuelven las rutinas de b\u00fasqueda del \u00e1rbol b para indicar que el bloque que se busca no existe, por lo que las funciones que operan en ese \u00e1rbol b pueden comportarse mal. Cuando nilfs_btree_insert() recibe este c\u00f3digo falso \u0027no encontrado\u0027 de nilfs_btree_do_lookup(), malinterpreta que la verificaci\u00f3n \u0027no encontrado\u0027 fue exitosa y contin\u00faa la operaci\u00f3n de inserci\u00f3n utilizando datos de ruta de b\u00fasqueda incompletos, lo que provoca el siguiente bloqueo: falla de protecci\u00f3n general, probablemente por direcci\u00f3n no can\u00f3nica 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs 2/btree.c:418 [en l\u00ednea] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [en l\u00ednea] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 C\u00f3digo: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 3 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b f 49 83 c7 02... Seguimiento de llamadas: nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [en l\u00ednea] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c: 101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [en l\u00ednea] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c :261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [en l\u00ednea] new_sync_write fs/read_write.c:491 [en l\u00ednea] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64 +0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd ... Este parche soluciona la causa ra\u00edz de este problema reemplazando el c\u00f3digo de error que devuelve __nilfs_btree_get_block() en la conversi\u00f3n de direcciones de bloque falla de -ENOENT a otro c\u00f3digo interno -EINVAL, lo que significa que los metadatos del \u00e1rbol b est\u00e1n da\u00f1ados. Al devolver -EINVAL, se propaga sin fallos y, para todas las operaciones relevantes del \u00e1rbol b, las funciones en la capa superior del mapa b generan un mensaje de error que indica metadatos del \u00e1rbol b corruptos a trav\u00e9s de nilfs_bmap_convert_error(), y el c\u00f3digo -EIO se devolver\u00e1 eventualmente cuando deber\u00eda ser."
}
],
"id": "CVE-2023-52900",
"lastModified": "2026-06-17T06:43:53.593",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2023-52900",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:03:31.052227Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-08-21T07:15:06.297",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-8HWX-G945-2V69
Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-09-13 15:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:
general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ...
This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.
{
"affected": [],
"aliases": [
"CVE-2023-52900"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix general protection fault in nilfs_btree_insert()\n\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\n\nWhen nilfs_btree_insert() receives this spurious \u0027not found\u0027 code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0027not found\u0027 check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\n\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u003cTASK\u003e\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u003c/TASK\u003e\n\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\n\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.",
"id": "GHSA-8hwx-g945-2v69",
"modified": "2024-09-13T15:31:31Z",
"published": "2024-08-21T09:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52900"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749"
}
],
"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"
}
]
}
oesa-2024-2079
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix data TLB miss in sba_unmap_sg
Rolf Eike Beer reported the following bug:
[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)
The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code:
while (sg_dma_len(sglist) && nents--) {
The fix is simply to test nents first and move the decrement of nents into the loop.(CVE-2022-48795)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix GEM handle creation UAF
Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done after we are done dereferencing the object.(CVE-2022-48899)
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: fix memory leak in int3400_notify()
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30
Fix it by calling kfree() accordingly.(CVE-2022-48924)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: men_z188_adc: Fix a resource leak in an error handling path
If iio_device_register() fails, a previous ioremap() is left unbalanced.
Update the error handling path and add the missing iounmap() call, as already done in the remove function.(CVE-2022-48928)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: make apf token non-zero to fix bug
In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event.
This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)
In the Linux kernel, the following vulnerability has been resolved:
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device(CVE-2023-52898)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:
general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK>
This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)
In the Linux kernel, the following vulnerability has been resolved:
drivers: core: synchronize really_probe() and dev_uevent()
Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:
Thread #1:
really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }
Thread #2:
dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }
really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:
dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Similar cases are reported by syzkaller in
https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a
But these are regarding the initialization of dev->driver
dev->driver = drv;
As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).
The same issue was reported and tried to be fixed back in 2015 in
https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/
already.(CVE-2024-39501)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_check_dir_entry()
This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.(CVE-2024-41015)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix sclp_init() cleanup on failure
If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning:
------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30
Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.(CVE-2024-41068)
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)
In the Linux kernel, the following vulnerability has been resolved:
protect the fetch of ->fd[fd] in do_dup2() from mispredictions
both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix use after free in iucv_sock_close()
iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn().
Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing.
Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix a use after free in hfcmulti_tx()
Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipc_udp_addr2str() on error
tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.(CVE-2024-42284)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:
conn_id->cm_id.iw = cm_id;
cm_id->context = conn_id;
cm_id->cm_handler = cma_iw_handler;
rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: During vport delete send async logout explicitly
During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 </TASK>
Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to don't dirty inode for readonly filesystem
syzbot reports f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b
The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)
- umount
- kill_f2fs_super
- kill_block_super
- generic_shutdown_super
- sync_filesystem : sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic
When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)
In the Linux kernel, the following vulnerability has been resolved:
ext4: check dot and dotdot of dx_root before making dir indexed
Syzbot reports a issue as follows:
BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================
The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.
do_split
unsigned split
dx_make_map
count = 1
split = count/2 = 0;
continued = hash2 == map[split - 1].hash;
---> map[4294967295]
The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.
But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:
bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024
So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called.
In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.
Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: fix memory leak for not ip packets
Free the unused skb when not ip packets arrive.(CVE-2024-43861)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning:
kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]
Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)
In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not set-id:
---------x 1 root root 16048 Aug 7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug 7 13:16 target
it is possible to gain root privileges when execution should have been disallowed.
While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root".
Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.(CVE-2024-43882)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2408.5.0.0292.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\nparisc: Fix data TLB miss in sba_unmap_sg\r\n\r\nRolf Eike Beer reported the following bug:\r\n\r\n[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018\n[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4\n[1274934.746891] Hardware name: 9000/785/C8000\n[1274934.746891]\n[1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI\n[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted\n[1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000\n[1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001\n[1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001\n[1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0\n[1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007\n[1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001\n[1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0\n[1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118\n[1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800\n[1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[1274934.746891]\n[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec\n[1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018\n[1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff\n[1274934.746891] ORIG_R28: 0000000040acdd58\n[1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118\n[1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118\n[1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118\n[1274934.746891] Backtrace:\n[1274934.746891] [\u0026lt;00000000402740cc\u0026gt;] dma_unmap_sg_attrs+0x6c/0x70\n[1274934.746891] [\u0026lt;000000004074d6bc\u0026gt;] scsi_dma_unmap+0x54/0x60\n[1274934.746891] [\u0026lt;00000000407a3488\u0026gt;] mptscsih_io_done+0x150/0xd70\n[1274934.746891] [\u0026lt;0000000040798600\u0026gt;] mpt_interrupt+0x168/0xa68\n[1274934.746891] [\u0026lt;0000000040255a48\u0026gt;] __handle_irq_event_percpu+0xc8/0x278\n[1274934.746891] [\u0026lt;0000000040255c34\u0026gt;] handle_irq_event_percpu+0x3c/0xd8\n[1274934.746891] [\u0026lt;000000004025ecb4\u0026gt;] handle_percpu_irq+0xb4/0xf0\n[1274934.746891] [\u0026lt;00000000402548e0\u0026gt;] generic_handle_irq+0x50/0x70\n[1274934.746891] [\u0026lt;000000004019a254\u0026gt;] call_on_stack+0x18/0x24\n[1274934.746891]\n[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)\r\n\r\nThe bug is caused by overrunning the sglist and incorrectly testing\nsg_dma_len(sglist) before nents. Normally this doesn\u0026apos;t cause a crash,\nbut in this case sglist crossed a page boundary. This occurs in the\nfollowing code:\r\n\r\n\twhile (sg_dma_len(sglist) \u0026amp;\u0026amp; nents--) {\r\n\r\nThe fix is simply to test nents first and move the decrement of nents\ninto the loop.(CVE-2022-48795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/virtio: Fix GEM handle creation UAF\r\n\r\nUserspace can guess the handle value and try to race GEM object creation\nwith handle close, resulting in a use-after-free if we dereference the\nobject after dropping the handle\u0026apos;s reference. For that reason, dropping\nthe handle\u0026apos;s reference must be done *after* we are done dereferencing\nthe object.(CVE-2022-48899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: int340x: fix memory leak in int3400_notify()\r\n\r\nIt is easy to hit the below memory leaks in my TigerLake platform:\r\n\r\nunreferenced object 0xffff927c8b91dbc0 (size 32):\n comm \u0026quot;kworker/0:2\u0026quot;, pid 112, jiffies 4294893323 (age 83.604s)\n hex dump (first 32 bytes):\n 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The\n 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.\n backtrace:\n [\u0026lt;ffffffff9c502c3e\u0026gt;] __kmalloc_track_caller+0x2fe/0x4a0\n [\u0026lt;ffffffff9c7b7c15\u0026gt;] kvasprintf+0x65/0xd0\n [\u0026lt;ffffffff9c7b7d6e\u0026gt;] kasprintf+0x4e/0x70\n [\u0026lt;ffffffffc04cb662\u0026gt;] int3400_notify+0x82/0x120 [int3400_thermal]\n [\u0026lt;ffffffff9c8b7358\u0026gt;] acpi_ev_notify_dispatch+0x54/0x71\n [\u0026lt;ffffffff9c88f1a7\u0026gt;] acpi_os_execute_deferred+0x17/0x30\n [\u0026lt;ffffffff9c2c2c0a\u0026gt;] process_one_work+0x21a/0x3f0\n [\u0026lt;ffffffff9c2c2e2a\u0026gt;] worker_thread+0x4a/0x3b0\n [\u0026lt;ffffffff9c2cb4dd\u0026gt;] kthread+0xfd/0x130\n [\u0026lt;ffffffff9c201c1f\u0026gt;] ret_from_fork+0x1f/0x30\r\n\r\nFix it by calling kfree() accordingly.(CVE-2022-48924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: men_z188_adc: Fix a resource leak in an error handling path\r\n\r\nIf iio_device_register() fails, a previous ioremap() is left unbalanced.\r\n\r\nUpdate the error handling path and add the missing iounmap() call, as\nalready done in the remove function.(CVE-2022-48928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86/mmu: make apf token non-zero to fix bug\r\n\r\nIn current async pagefault logic, when a page is ready, KVM relies on\nkvm_arch_can_dequeue_async_page_present() to determine whether to deliver\na READY event to the Guest. This function test token value of struct\nkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a\nREADY event is finished by Guest. If value is zero meaning that a READY\nevent is done, so the KVM can deliver another.\nBut the kvm_arch_setup_async_pf() may produce a valid token with zero\nvalue, which is confused with previous mention and may lead the loss of\nthis READY event.\r\n\r\nThis bug may cause task blocked forever in Guest:\n INFO: task stress:7532 blocked for more than 1254 seconds.\n Not tainted 5.10.0 #16\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:stress state:D stack: 0 pid: 7532 ppid: 1409\n flags:0x00000080\n Call Trace:\n __schedule+0x1e7/0x650\n schedule+0x46/0xb0\n kvm_async_pf_task_wait_schedule+0xad/0xe0\n ? exit_to_user_mode_prepare+0x60/0x70\n __kvm_handle_async_pf+0x4f/0xb0\n ? asm_exc_page_fault+0x8/0x30\n exc_page_fault+0x6f/0x110\n ? asm_exc_page_fault+0x8/0x30\n asm_exc_page_fault+0x1e/0x30\n RIP: 0033:0x402d00\n RSP: 002b:00007ffd31912500 EFLAGS: 00010206\n RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0\n RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0\n RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086\n R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000\n R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngsmi: fix null-deref in gsmi_get_variable\r\n\r\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\r\n\r\ncommit 859748255b43 (\u0026quot;efi: pstore: Omit efivars caching EFI varstore\naccess layer\u0026quot;) added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.(CVE-2023-52893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix null pointer dereference when host dies\r\n\r\nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race\nand cause null pointer dereference when host suddenly dies.\r\n\r\nUsb core may call xhci_free_dev() which frees the xhci-\u0026gt;devs[slot_id]\nvirt device at the same time that xhci_kill_endpoint_urbs() tries to\nloop through all the device\u0026apos;s endpoints, checking if there are any\ncancelled urbs left to give back.\r\n\r\nhold the xhci spinlock while freeing the virt device(CVE-2023-52898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix general protection fault in nilfs_btree_insert()\r\n\r\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\r\n\r\nWhen nilfs_btree_insert() receives this spurious \u0026apos;not found\u0026apos; code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0026apos;not found\u0026apos; check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\r\n\r\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\r\n\r\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.(CVE-2023-52900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n ...\n dev-\u0026gt;driver = NULL; // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n ...\n }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n // after above check, the system crashes\n add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0 \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed. That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966] [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330] [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336] [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341] [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345] [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815] [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820] [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826] [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832] [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841] [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321] [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n conn_id-\u0026gt;cm_id.iw = cm_id;\n cm_id-\u0026gt;context = conn_id;\n cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: During vport delete send async logout explicitly\r\n\r\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array. For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n ? qla2x00_status_entry+0x768/0x2830\n ? newidle_balance+0x2f0/0x430\n ? dequeue_entity+0x100/0x3c0\n ? qla24xx_process_response_queue+0x6a1/0x19e0\n ? __schedule+0x2d5/0x1140\n ? qla_do_work+0x47/0x60\n ? process_one_work+0x267/0x440\n ? process_one_work+0x440/0x440\n ? worker_thread+0x2d/0x3d0\n ? process_one_work+0x440/0x440\n ? kthread+0x156/0x180\n ? set_kthread_struct+0x50/0x50\n ? ret_from_fork+0x22/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nSend out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to don\u0026apos;t dirty inode for readonly filesystem\r\n\r\nsyzbot reports f2fs bug as below:\r\n\r\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n - __f2fs_find_entry\n - f2fs_i_depth_write\n - f2fs_mark_inode_dirty_sync\n - f2fs_dirty_inode\n - set_inode_flag(inode, FI_DIRTY_INODE)\r\n\r\n- umount\n - kill_f2fs_super\n - kill_block_super\n - generic_shutdown_super\n - sync_filesystem\n : sb is readonly, skip sync_filesystem()\n - evict_inodes\n - iput\n - f2fs_evict_inode\n - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n : trigger kernel panic\r\n\r\nWhen we try to repair i_current_depth in readonly filesystem, let\u0026apos;s\nskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n do_split\n unsigned split\n dx_make_map\n count = 1\n split = count/2 = 0;\n continued = hash2 == map[split - 1].hash;\n ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n bus dentry1 hole dentry2 free\n|xx--|xx-------------|...............|xx-------------|...............|\n0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\r\n\r\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\r\n\r\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\r\n\r\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug 7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug 7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)",
"id": "OESA-2024-2079",
"modified": "2026-08-06T11:07:33Z",
"published": "2024-08-30T11:07:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2079"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48928"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48943"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48795",
"CVE-2022-48899",
"CVE-2022-48924",
"CVE-2022-48928",
"CVE-2022-48943",
"CVE-2023-52893",
"CVE-2023-52898",
"CVE-2023-52900",
"CVE-2024-39501",
"CVE-2024-41015",
"CVE-2024-41068",
"CVE-2024-42153",
"CVE-2024-42265",
"CVE-2024-42271",
"CVE-2024-42280",
"CVE-2024-42284",
"CVE-2024-42285",
"CVE-2024-42289",
"CVE-2024-42297",
"CVE-2024-42305",
"CVE-2024-43861",
"CVE-2024-43879",
"CVE-2024-43882"
]
}
oesa-2024-2185
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Fix use-after-free race condition for maps
It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted.
Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted.
Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall(CVE-2022-48872)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.(CVE-2023-52691)
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:
usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device.
AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
// halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6]
// word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8]
// x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9]
// loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19]
// x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]
which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT;
/ SPEED_CHANGE data is up/down speeds in bits/sec / data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic.
AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...(CVE-2023-52894)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:
general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK>
This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: tproxy: bail out if IP has been disabled on the device
syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168
__in_dev_get_rcu() can return NULL, so check for this.(CVE-2024-36270)
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
syzbot reported unsafe calls to copy_from_sockptr() [1]
Use copy_safe_from_sockptr() instead.
[1]
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 nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078
CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #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 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 do_sock_setsockopt+0x3b1/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+0xfd/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.
Fix the issue by checking for the existence of all proper endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2024-38565)
In the Linux kernel, the following vulnerability has been resolved:
jfs: don't walk off the end of ealist
Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value in copy_name
[syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix null pointer dereference on error
If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]
Do not access ata_port struct members unconditionally.(CVE-2024-41098)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: add missing check for inode numbers on directory entries
Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn().
As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case).
The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.
Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.(CVE-2024-42104)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip finding free audio for unknown engine_id
[WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.
[HOW] Skip and return NULL.
This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)
In the Linux kernel, the following vulnerability has been resolved:
kobject_uevent: Fix OOB access within zap_modalias_env()
zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix pti_clone_pgtable() alignment assumption
Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then
DF from the stack guard.
It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.
These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?
Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: avoid possible UaF when selecting endp
select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.
A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)
In the Linux kernel, the following vulnerability has been resolved:
gtp: pull network headers in gtp_dev_xmit()
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.
Use pskb_inet_may_pull() to fix this issue.
[1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:
- File A has inode i_reg and an ea inode i_ea
- getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
-
Then, following three processes running like this:
PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:
- File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
- getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
- Then, following three processes running like this:
PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---(CVE-2024-45003)
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_test: Fix NULL dereference on allocation failure
If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.(CVE-2024-45028)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case.
This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index for mc_data[] when i = 0.(CVE-2024-46731)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve leaks in cow_file_range
In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked
Cases 2 and 3 in the out_reserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfs_free_qgroup_data.(CVE-2024-46733)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: sanity check symbolic link size
Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.
This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.
The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:
-
squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.
-
Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.
-
The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.
This patch adds a sanity check which checks that the symbolic link size is not larger than expected.
--
V2: fix spelling mistake.(CVE-2024-46744)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - reject requests with unreasonable number of slots
When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.
Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)
In the Linux kernel, the following vulnerability has been resolved:
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()
Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.(CVE-2024-46751)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).(CVE-2024-46752)
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: fix checks for huge PMDs
Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.
The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version:
- The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).
- As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().
- On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.
I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2.
This patch (of 2):
This fixes two issues.
I discovered that the following race can occur:
mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(dst_pmd)> BUG_ON(pmd_none(dst_pmd))
I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers.
On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map_lock to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table.
The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs).
On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table.
Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different).
If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table.
As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway.
Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.95.0.176.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.95.0.176.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.95.0.176.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc: fastrpc: Fix use-after-free race condition for maps\r\n\r\nIt is possible that in between calling fastrpc_map_get() until\nmap-\u0026gt;fl-\u0026gt;lock is taken in fastrpc_free_map(), another thread can call\nfastrpc_map_lookup() and get a reference to a map that is about to be\ndeleted.\r\n\r\nRewrite fastrpc_map_get() to only increase the reference count of a map\nif it\u0026apos;s non-zero. Propagate this to callers so they can know if a map is\nabout to be deleted.\r\n\r\nFixes this warning:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate\n...\nCall trace:\n refcount_warn_saturate\n [fastrpc_map_get inlined]\n [fastrpc_map_lookup inlined]\n fastrpc_map_create\n fastrpc_internal_invoke\n fastrpc_device_ioctl\n __arm64_sys_ioctl\n invoke_syscall(CVE-2022-48872)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\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\nusb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()\r\n\r\nIn Google internal bug 265639009 we\u0026apos;ve received an (as yet) unreproducible\ncrash report from an aarch64 GKI 5.10.149-android13 running device.\r\n\r\nAFAICT the source code is at:\n https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10\r\n\r\nThe call stack is:\n ncm_close() -\u0026gt; ncm_notify() -\u0026gt; ncm_do_notify()\nwith the crash at:\n ncm_do_notify+0x98/0x270\nCode: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)\r\n\r\nWhich I believe disassembles to (I don\u0026apos;t know ARM assembly, but it looks sane enough to me...):\r\n\r\n // halfword (16-bit) store presumably to event-\u0026gt;wLength (at offset 6 of struct usb_cdc_notification)\n 0B 0D 00 79 strh w11, [x8, #6]\r\n\r\n // word (32-bit) store presumably to req-\u0026gt;Length (at offset 8 of struct usb_request)\n 6C 0A 00 B9 str w12, [x19, #8]\r\n\r\n // x10 (NULL) was read here from offset 0 of valid pointer x9\n // IMHO we\u0026apos;re reading \u0026apos;cdev-\u0026gt;gadget\u0026apos; and getting NULL\n // gadget is indeed at offset 0 of struct usb_composite_dev\n 2A 01 40 F9 ldr x10, [x9]\r\n\r\n // loading req-\u0026gt;buf pointer, which is at offset 0 of struct usb_request\n 69 02 40 F9 ldr x9, [x19]\r\n\r\n // x10 is null, crash, appears to be attempt to read cdev-\u0026gt;gadget-\u0026gt;max_speed\n 4B 5D 40 B9 ldr w11, [x10, #0x5c]\r\n\r\nwhich seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:\r\n\r\n event-\u0026gt;wLength = cpu_to_le16(8);\n req-\u0026gt;length = NCM_STATUS_BYTECOUNT;\r\n\r\n /* SPEED_CHANGE data is up/down speeds in bits/sec */\n data = req-\u0026gt;buf + sizeof *event;\n data[0] = cpu_to_le32(ncm_bitrate(cdev-\u0026gt;gadget));\r\n\r\nMy analysis of registers and NULL ptr deref crash offset\n (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)\nheavily suggests that the crash is due to \u0026apos;cdev-\u0026gt;gadget\u0026apos; being NULL when executing:\n data[0] = cpu_to_le32(ncm_bitrate(cdev-\u0026gt;gadget));\nwhich calls:\n ncm_bitrate(NULL)\nwhich then calls:\n gadget_is_superspeed(NULL)\nwhich reads\n ((struct usb_gadget *)NULL)-\u0026gt;max_speed\nand hits a panic.\r\n\r\nAFAICT, if I\u0026apos;m counting right, the offset of max_speed is indeed 0x5C.\n(remember there\u0026apos;s a GKI KABI reservation of 16 bytes in struct work_struct)\r\n\r\nIt\u0026apos;s not at all clear to me how this is all supposed to work...\nbut returning 0 seems much better than panic-ing...(CVE-2023-52894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix general protection fault in nilfs_btree_insert()\r\n\r\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\r\n\r\nWhen nilfs_btree_insert() receives this spurious \u0026apos;not found\u0026apos; code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0026apos;not found\u0026apos; check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\r\n\r\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\r\n\r\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.(CVE-2023-52900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: tproxy: bail out if IP has been disabled on the device\r\n\r\nsyzbot reports:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n[..]\nRIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62\nCall Trace:\n nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]\n nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168\r\n\r\n__in_dev_get_rcu() can return NULL, so check for this.(CVE-2024-36270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: llcp: fix nfc_llcp_setsockopt() unsafe copies\r\n\r\nsyzbot reported unsafe calls to copy_from_sockptr() [1]\r\n\r\nUse copy_safe_from_sockptr() instead.\r\n\r\n[1]\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\nRead of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078\r\n\r\nCPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\n do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfd/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7f7fac07fd89\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89\nRDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: don\u0026apos;t walk off the end of ealist\r\n\r\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfsplus: fix uninit-value in copy_name\r\n\r\n[syzbot reported]\nBUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160\n sized_strscpy+0xc4/0x160\n copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411\n hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3877 [inline]\n slab_alloc_node mm/slub.c:3918 [inline]\n kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065\n kmalloc include/linux/slab.h:628 [inline]\n hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[Fix]\nWhen allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix null pointer dereference on error\r\n\r\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\r\n\r\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\r\n\r\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nDo not access ata_port struct members unconditionally.(CVE-2024-41098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip finding free audio for unknown engine_id\r\n\r\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\r\n\r\n[HOW]\nSkip and return NULL.\r\n\r\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkobject_uevent: Fix OOB access within zap_modalias_env()\r\n\r\nzap_modalias_env() wrongly calculates size of memory block to move, so\nwill cause OOB memory access issue if variable MODALIAS is not the last\none within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: avoid possible UaF when selecting endp\r\n\r\nselect_local_address() and select_signal_address() both select an\nendpoint entry from the list inside an RCU protected section, but return\na reference to it, to be read later on. If the entry is dereferenced\nafter the RCU unlock, reading info could cause a Use-after-Free.\r\n\r\nA simple solution is to copy the required info while inside the RCU\nprotected section to avoid any risk of UaF later. The address ID might\nneed to be modified later to handle the ID0 case later, so a copy seems\nOK to deal with.(CVE-2024-44974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n \u2502\n \u25bc\n ......\nsetup tc \u2502\n \u2502 \u25bc\n \u25bc DOWN: napi_disable()\nnapi_disable()(skip) \u2502\n \u2502 \u2502\n \u25bc \u25bc\n ...... ......\n \u2502 \u2502\n \u25bc \u2502\nnapi_enable() \u2502\n \u25bc\n UINIT: netif_napi_del()\n \u2502\n \u25bc\n ......\n \u2502\n \u25bc\n INIT: netif_napi_add()\n \u2502\n \u25bc\n ...... global reset start\n \u2502 \u2502\n \u25bc \u25bc\n UP: napi_enable()(skip) ......\n \u2502 \u2502\n \u25bc \u25bc\n ...... napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n xmit_one net/core/dev.c:3580 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3145 [inline]\n packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3994 [inline]\n slab_alloc_node mm/slub.c:4037 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n alloc_skb include/linux/skbuff.h:1320 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n packet_snd net/packet/af_packet.c:3088 [inline]\n packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n PA PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(i_reg)\n spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n spin_unlock(lru_lock)\n rm file A\n i_reg-\u0026gt;nlink = 0\n iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n ext4_evict_inode\n ext4_xattr_delete_inode\n ext4_xattr_inode_dec_ref_all\n ext4_xattr_inode_iget\n ext4_iget(i_ea-\u0026gt;i_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n PA PB PC\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n ixa-\u0026gt;i_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(ib)\n spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n spin_unlock(lru_lock)\n rm file B\n ib-\u0026gt;nlink = 0\n rm file A\n iput(ia)\n ubifs_evict_inode(ia)\n ubifs_jnl_delete_inode(ia)\n ubifs_jnl_write_inode(ia)\n make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n ubifs_iget(ixa-\u0026gt;i_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(ixa)\n | iput(ib) // ib-\u0026gt;nlink is 0, do evict\n | ubifs_evict_inode\n | ubifs_jnl_delete_inode(ib)\n \u2193 ubifs_jnl_write_inode\n ABBA deadlock \u2190-----make_reservation(BASEHD)\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference. Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n ------------[ cut here ]------------\n WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? __warn.cold+0x8e/0xea\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? report_bug+0xff/0x140\n ? handle_bug+0x3b/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? close_ctree+0x222/0x4d0 [btrfs]\n generic_shutdown_super+0x70/0x160\n kill_anon_super+0x11/0x40\n btrfs_kill_super+0x11/0x20 [btrfs]\n deactivate_locked_super+0x2e/0xa0\n cleanup_mnt+0xb5/0x150\n task_work_run+0x57/0x80\n syscall_exit_to_user_mode+0x121/0x130\n do_syscall_64+0xab/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f916847a887\n ---[ end trace 0000000000000000 ]---\n BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n link from disk. This assigns the corrupted value\n 3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n this corrupted value to the length variable, which being a\n signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n the copied bytes is less than length, which being negative means\n the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n some extra mdelay() calls. See the commit message for a description\n of the race scenario.\n On older kernels (before 6.5), I think the same bug can even\n theoretically lead to accessing transhuge page contents as a page table\n if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n detecting PMDs that don\u0026apos;t point to page tables.\n On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n wide race to hit this.\n I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n to yank page tables out from under us (though I haven\u0026apos;t tested that),\n so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n mfill_atomic other thread\n ============ ============\n \u0026lt;zap PMD\u0026gt;\n pmdp_get_lockless() [reads none pmd]\n \u0026lt;bail if trans_huge\u0026gt;\n \u0026lt;if none:\u0026gt;\n \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n __pte_alloc [no-op]\n \u0026lt;zap PMD\u0026gt;\n \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)",
"id": "OESA-2024-2185",
"modified": "2026-08-06T11:07:39Z",
"published": "2024-09-27T11:07:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48872"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42292"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46787"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48828",
"CVE-2022-48872",
"CVE-2023-52691",
"CVE-2023-52748",
"CVE-2023-52894",
"CVE-2023-52900",
"CVE-2024-36270",
"CVE-2024-36915",
"CVE-2024-38565",
"CVE-2024-41017",
"CVE-2024-41059",
"CVE-2024-41098",
"CVE-2024-42104",
"CVE-2024-42119",
"CVE-2024-42292",
"CVE-2024-44965",
"CVE-2024-44974",
"CVE-2024-44995",
"CVE-2024-44999",
"CVE-2024-45003",
"CVE-2024-45028",
"CVE-2024-46714",
"CVE-2024-46723",
"CVE-2024-46731",
"CVE-2024-46733",
"CVE-2024-46744",
"CVE-2024-46745",
"CVE-2024-46747",
"CVE-2024-46751",
"CVE-2024-46752",
"CVE-2024-46787"
]
}
SUSE-SU-2024:3190-1
Vulnerability from csaf_suse - Published: 2024-09-10 08:46 - Updated: 2024-09-10 08:46SUSE-SU-2024:3209-1
Vulnerability from csaf_suse - Published: 2024-09-11 15:39 - Updated: 2024-09-11 15:39Sightings
| 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.