mirror of
https://github.com/fkie-cad/nvd-json-data-feeds.git
synced 2025-06-19 17:31:42 +00:00
Auto-Update: 2024-06-20T14:00:20.555063+00:00
This commit is contained in:
cad-safe-bot
parent
2088100700
commit
a8f86b31a4
@ -2,8 +2,8 @@
|
|||||||
"id": "CVE-2018-25103",
|
"id": "CVE-2018-25103",
|
||||||
"sourceIdentifier": "cret@cert.org",
|
"sourceIdentifier": "cret@cert.org",
|
||||||
"published": "2024-06-17T18:15:12.650",
|
"published": "2024-06-17T18:15:12.650",
|
||||||
"lastModified": "2024-06-18T15:15:51.310",
|
"lastModified": "2024-06-20T12:44:22.977",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
|
|||||||
48
CVE-2021/CVE-2021-44xx/CVE-2021-4439.json
Normal file
48
CVE-2021/CVE-2021-44xx/CVE-2021-4439.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2021-4439",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:10.447",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nisdn: cpai: check ctr->cnr to avoid array index out of bound\n\nThe cmtp_add_connection() would add a cmtp session to a controller\nand run a kernel thread to process cmtp.\n\n\t__module_get(THIS_MODULE);\n\tsession->task = kthread_run(cmtp_session, session, \"kcmtpd_ctr_%d\",\n\t\t\t\t\t\t\t\tsession->num);\n\nDuring this process, the kernel thread would call detach_capi_ctr()\nto detach a register controller. if the controller\nwas not attached yet, detach_capi_ctr() would\ntrigger an array-index-out-bounds bug.\n\n[ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in\ndrivers/isdn/capi/kcapi.c:483:21\n[ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]'\n[ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted\n5.15.0-rc2+ #8\n[ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX,\n1996), BIOS 1.14.0-2 04/01/2014\n[ 46.870107][ T6479] Call Trace:\n[ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d\n[ 46.870974][ T6479] ubsan_epilogue+0x5/0x40\n[ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48\n[ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0\n[ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0\n[ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60\n[ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120\n[ 46.874256][ T6479] kthread+0x147/0x170\n[ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40\n[ 46.875248][ T6479] ret_from_fork+0x1f/0x30\n[ 46.875773][ T6479]"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787ff91e4d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/7d91adc0ccb060ce564103315189466eb822cc6a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/7f221ccbee4ec662e2292d490a43ce6c314c4594",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9b6b2db77bc3121fe435f1d4b56e34de443bec75",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cc20226e218a2375d50dd9ac14fb4121b43375ff",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e8b8de17e164c9f1b7777f1c6f99d05539000036",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47576",
|
"id": "CVE-2021-47576",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.117",
|
"published": "2024-06-19T15:15:52.117",
|
||||||
"lastModified": "2024-06-19T15:15:52.117",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()\n\nIn resp_mode_select() sanity check the block descriptor len to avoid UAF.\n\nBUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509\nRead of size 1 at addr ffff888026670f50 by task scsicmd/15032\n\nCPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nCall Trace:\n <TASK>\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107\n print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257\n kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443\n __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306\n resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509\n schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483\n scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537\n scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63\n sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837\n sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775\n sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()\n\nIn resp_mode_select() sanity check the block descriptor len to avoid UAF.\n\nBUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509\nRead of size 1 at addr ffff888026670f50 by task scsicmd/15032\n\nCPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nCall Trace:\n <TASK>\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107\n print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257\n kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443\n __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306\n resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509\n schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483\n scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537\n scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63\n sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837\n sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775\n sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: Verifique la longitud del descriptor del bloque en resp_mode_select() En resp_mode_select(), verifique la longitud del descriptor del bloque para evitar UAF. ERROR: KASAN: use-after-free en resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 Lectura del tama\u00f1o 1 en la direcci\u00f3n ffff888026670f50 por tarea scsicmd/15032 CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0 -01d0625 #15 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), seguimiento de llamadas del BIOS: dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/ report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c: 2509 Schedule_resp+0x4af/0x1a10 controladores/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 controladores/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 controladores/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 bloque/ blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/ 0x150 cuadra/blk-mq. c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 ched.c:474 blk_execute_rq_nowait+0x16b /0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 controladores/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 controladores/scsi/sg.c:775 sg_ioctl_common+0x14d6 /0x2710 controladores/scsi/sg.c:941 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common. c:50 entrada_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47577",
|
"id": "CVE-2021-47577",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.223",
|
"published": "2024-06-19T15:15:52.223",
|
||||||
"lastModified": "2024-06-19T15:15:52.223",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio-wq: check for wq exit after adding new worker task_work\n\nWe check IO_WQ_BIT_EXIT before attempting to create a new worker, and\nwq exit cancels pending work if we have any. But it's possible to have\na race between the two, where creation checks exit finding it not set,\nbut we're in the process of exiting. The exit side will cancel pending\ncreation task_work, but there's a gap where we add task_work after we've\ncanceled existing creations at exit time.\n\nFix this by checking the EXIT bit post adding the creation task_work.\nIf it's set, run the same cancelation that exit does."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio-wq: check for wq exit after adding new worker task_work\n\nWe check IO_WQ_BIT_EXIT before attempting to create a new worker, and\nwq exit cancels pending work if we have any. But it's possible to have\na race between the two, where creation checks exit finding it not set,\nbut we're in the process of exiting. The exit side will cancel pending\ncreation task_work, but there's a gap where we add task_work after we've\ncanceled existing creations at exit time.\n\nFix this by checking the EXIT bit post adding the creation task_work.\nIf it's set, run the same cancelation that exit does."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io-wq: comprueba la salida de wq despu\u00e9s de agregar un nuevo trabajador task_work Comprobamos IO_WQ_BIT_EXIT antes de intentar crear un nuevo trabajador, y wq exit cancela el trabajo pendiente si tenemos alguno. Pero es posible tener una carrera entre los dos, donde las comprobaciones de creaci\u00f3n salen y descubren que no est\u00e1 configurado, pero estamos en el proceso de salir. El lado de salida cancelar\u00e1 la creaci\u00f3n pendiente task_work, pero hay un espacio en el que agregamos task_work despu\u00e9s de haber cancelado las creaciones existentes en el momento de la salida. Solucione este problema marcando la publicaci\u00f3n del bit EXIT agregando la tarea de creaci\u00f3n_trabajo. Si est\u00e1 configurado, ejecute la misma cancelaci\u00f3n que realiza la salida."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47578",
|
"id": "CVE-2021-47578",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.320",
|
"published": "2024-06-19T15:15:52.320",
|
||||||
"lastModified": "2024-06-19T15:15:52.320",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Don't call kcalloc() if size arg is zero\n\nIf the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of\nthat, for a following NULL pointer check to work on the returned pointer,\nkcalloc() must not be called with the size arg equal to zero. Return early\nwithout error before the kcalloc() call if size arg is zero.\n\nBUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\nWrite of size 4 at addr 0000000000000010 by task syz-executor.1/22789\n\nCPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n __kasan_report mm/kasan/report.c:446 [inline]\n kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x3b/0x60 mm/kasan/shadow.c:66\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\n do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]\n do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]\n resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n blk_execute_rq+0xdb/0x360 block/blk-exec.c:102\n sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]\n scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930\n sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Don't call kcalloc() if size arg is zero\n\nIf the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of\nthat, for a following NULL pointer check to work on the returned pointer,\nkcalloc() must not be called with the size arg equal to zero. Return early\nwithout error before the kcalloc() call if size arg is zero.\n\nBUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\nWrite of size 4 at addr 0000000000000010 by task syz-executor.1/22789\n\nCPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n __kasan_report mm/kasan/report.c:446 [inline]\n kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x3b/0x60 mm/kasan/shadow.c:66\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\n do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]\n do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]\n resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n blk_execute_rq+0xdb/0x360 block/blk-exec.c:102\n sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]\n scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930\n sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: no llamar a kcalloc() si el tama\u00f1o arg es cero. Si el tama\u00f1o arg de kcalloc() es cero, devuelve ZERO_SIZE_PTR. Por eso, para que una siguiente verificaci\u00f3n de puntero NULL funcione en el puntero devuelto, no se debe llamar a kcalloc() con el tama\u00f1o arg igual a cero. Regrese temprano sin errores antes de la llamada a kcalloc() si el tama\u00f1o arg es cero. ERROR: KASAN: null-ptr-deref en memcpy include/linux/fortify-string.h:191 [en l\u00ednea] ERROR: KASAN: null-ptr-deref en sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 Escritura de tama\u00f1o 4 en la direcci\u00f3n 0000000000000010 por tarea syz-executor.1/22789 CPU: 1 PID: 22789 Comm: syz-executor.1 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0-2 Seguimiento de llamadas : __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 __kasan_report mm/kasan/report.c:446 [en l\u00ednea] kasan_report.cold.14+0x112/0x117 mm/kasan/ report.c:459 check_region_inline mm/kasan/generic.c:183 [en l\u00ednea] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x3b/0x60 mm/kasan/shadow.c:66 memcpy include/linux /fortify-string.h:191 [en l\u00ednea] sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 controladores do_dout_fetch/scsi/scsi_debug.c:2954 [en l\u00ednea] controladores do_dout_fetch/scsi/scsi_debug.c:2946 [en l\u00ednea] resp_verify +0x49e/0x930 controladores/scsi/scsi_debug.c:4276 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi /scsi_lib.c: 1520 [en l\u00ednea] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 lk-mq-sched.c:325 blk_mq_sched_dispatch_requests+ 0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 cola+0x18d/0x350 bloque/negro -mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 blk_execute_rq+0xdb/0x360 block/blk-exec.c:102 sg_scsi_ioctl controladores/scsi/scsi_ioctl.c:621 [en l\u00ednea] scsi_ioctl+0x8bb/0x15c0 controladores/scsi/scsi_ioctl.c:930 sg_ioctl_common+0x172d/0x2710 controladores/scsi/sg.c:1112 sg_ioctl+0xa2/0 controladores x180/scsi/ SG.C: 1165 VFS_IOCTL FS/IOCTL.C: 51 [INLINE] __DO_SYS_IOCTL FS/IOCTL.C: 874 [INLINE] __SE_SYS_IOCTL FS/IOCTL.C: 860 [Inline] __X64_SY 60 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47579",
|
"id": "CVE-2021-47579",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.427",
|
"published": "2024-06-19T15:15:52.427",
|
||||||
"lastModified": "2024-06-19T15:15:52.427",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix warning in ovl_create_real()\n\nSyzbot triggered the following warning in ovl_workdir_create() ->\novl_create_real():\n\n\tif (!err && WARN_ON(!newdentry->d_inode)) {\n\nThe reason is that the cgroup2 filesystem returns from mkdir without\ninstantiating the new dentry.\n\nWeird filesystems such as this will be rejected by overlayfs at a later\nstage during setup, but to prevent such a warning, call ovl_mkdir_real()\ndirectly from ovl_workdir_create() and reject this case early."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix warning in ovl_create_real()\n\nSyzbot triggered the following warning in ovl_workdir_create() ->\novl_create_real():\n\n\tif (!err && WARN_ON(!newdentry->d_inode)) {\n\nThe reason is that the cgroup2 filesystem returns from mkdir without\ninstantiating the new dentry.\n\nWeird filesystems such as this will be rejected by overlayfs at a later\nstage during setup, but to prevent such a warning, call ovl_mkdir_real()\ndirectly from ovl_workdir_create() and reject this case early."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corregir advertencia en ovl_create_real() Syzbot activ\u00f3 la siguiente advertencia en ovl_workdir_create() -> ovl_create_real(): if (!err && WARN_ON(!newdentry->d_inode)) { La raz\u00f3n es que el sistema de archivos cgroup2 regresa desde mkdir sin crear una instancia del nuevo dentry. Los sistemas de archivos extra\u00f1os como este ser\u00e1n rechazados por overlayfs en una etapa posterior durante la instalaci\u00f3n, pero para evitar dicha advertencia, llame a ovl_mkdir_real() directamente desde ovl_workdir_create() y rechace este caso anticipadamente."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47580",
|
"id": "CVE-2021-47580",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.537",
|
"published": "2024-06-19T15:15:52.537",
|
||||||
"lastModified": "2024-06-19T15:15:52.537",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Fix type in min_t to avoid stack OOB\n\nChange min_t() to use type \"u32\" instead of type \"int\" to avoid stack out\nof bounds. With min_t() type \"int\" the values get sign extended and the\nlarger value gets used causing stack out of bounds.\n\nBUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\nRead of size 127 at addr ffff888072607128 by task syz-executor.7/18707\n\nCPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x23/0x60 mm/kasan/shadow.c:65\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\n sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000\n fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162\n fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]\n resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836\n sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774\n sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Fix type in min_t to avoid stack OOB\n\nChange min_t() to use type \"u32\" instead of type \"int\" to avoid stack out\nof bounds. With min_t() type \"int\" the values get sign extended and the\nlarger value gets used causing stack out of bounds.\n\nBUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\nRead of size 127 at addr ffff888072607128 by task syz-executor.7/18707\n\nCPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x23/0x60 mm/kasan/shadow.c:65\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\n sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000\n fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162\n fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]\n resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836\n sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774\n sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: scsi_debug: corrige el tipo min_t para evitar la pila OOB. Cambie min_t() para usar el tipo \"u32\" en lugar de \"int\" para evitar la pila fuera de los l\u00edmites. Con min_t() escriba \"int\", los valores se extienden y el valor mayor se usa provocando que la pila est\u00e9 fuera de los l\u00edmites. ERROR: KASAN: pila fuera de los l\u00edmites en memcpy include/linux/fortify-string.h:191 [en l\u00ednea] ERROR: KASAN: pila fuera de los l\u00edmites en sg_copy_buffer+0x1de/0x240 lib/scatterlist.c: 976 Lectura del tama\u00f1o 127 en la direcci\u00f3n ffff888072607128 mediante la tarea syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0 -2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan /report.c:442 [en l\u00ednea] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en l\u00ednea] kasan_check_range+0x1a3/0x210 mm/kasan/generic .c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [en l\u00ednea] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 controladores/scsi/scsi_debug.c:1162 fill_from_dev_buffer controladores/scsi/scsi_debug.c:1888 [en l\u00ednea] resp_readcap16+0x365/0x3b0 controladores/scsi/scsi_debug.c :1887 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi/scsi_lib.c:1520 [en l\u00ednea] Controladores 0x16b0/0x2d40/ scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x10 5/0x190 cuadra/blk-mq-programado. c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 :1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570 /0x8c0 controladores/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 controladores/scsi/sg.c:939 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [en l\u00ednea] __do_sys_ioctl fs/ioctl.c:874 [en l\u00ednea] __se_sys_ioctl fs/ioctl.c:860 [en l\u00ednea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] llamada al sistema_64 +0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47582",
|
"id": "CVE-2021-47582",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.743",
|
"published": "2024-06-19T15:15:52.743",
|
||||||
"lastModified": "2024-06-19T15:15:52.743",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\n\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value. If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \"Task X blocked for more than N\nseconds\", as found in testing by syzbot:\n\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n Not tainted 5.14.0-rc7-syzkaller #0\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\n\nTo fix this problem, this patch replaces usbfs's calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\n\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value. If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \"Task X blocked for more than N\nseconds\", as found in testing by syzbot:\n\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n Not tainted 5.14.0-rc7-syzkaller #0\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\n\nTo fix this problem, this patch replaces usbfs's calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: Hacer que do_proc_control() y do_proc_bulk() se puedan eliminar. Los ioctls USBDEVFS_CONTROL y USBDEVFS_BULK invocan usb_start_wait_urb(), que contiene una espera ininterrumpida con un valor de tiempo de espera especificado por el usuario. Si el valor del tiempo de espera es muy grande y el dispositivo al que se accede no responde en un per\u00edodo de tiempo razonable, el kernel se quejar\u00e1 de \"Tarea X bloqueada durante m\u00e1s de N segundos\", como se encontr\u00f3 en las pruebas realizadas por syzbot: INFORMACI\u00d3N: tarea syz-executor .0:8700 bloqueado durante m\u00e1s de 143 segundos. Not tainted 5.14.0-rc7-syzkaller #0 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" desactiva este mensaje. tarea:syz-executor.0 estado:D pila:23192 pid: 8700 ppid: 8455 banderas:0x00004004 Seguimiento de llamadas: context_switch kernel/sched/core.c:4681 [en l\u00ednea] __schedule+0xc07/0x11f0 kernel/sched/core.c :5938 programaci\u00f3n+0x14b/0x210 kernel/sched/core.c:6017 Schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion .c:106 [en l\u00ednea] wait_for_common kernel/sched/completion.c:117 [en l\u00ednea] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 controladores/usb/core/devio.c:1236 controladores proc_bulk/usb/core/devio.c:1273 [en l\u00ednea] usbdev_do_ioctl controladores/usb/core/devio.c:2547 [en l\u00ednea] usbdev_ioctl+0x3441/ 0x6b10 drivers/usb/core/devio.c:2713 ... Para solucionar este problema, este parche reemplaza las llamadas de usbfs a usb_control_msg() y usb_bulk_msg() con c\u00f3digo de prop\u00f3sito especial que hace esencialmente lo mismo (como se recomienda en el comentario para usb_start_wait_urb()), excepto que siempre usa una espera eliminable y usa GFP_KERNEL en lugar de GFP_NOIO."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47583",
|
"id": "CVE-2021-47583",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.843",
|
"published": "2024-06-19T15:15:52.843",
|
||||||
"lastModified": "2024-06-19T15:15:52.843",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mxl111sf: change mutex_init() location\n\nSyzbot reported, that mxl111sf_ctrl_msg() uses uninitialized\nmutex. The problem was in wrong mutex_init() location.\n\nPrevious mutex_init(&state->msg_lock) call was in ->init() function, but\ndvb_usbv2_init() has this order of calls:\n\n\tdvb_usbv2_init()\n\t dvb_usbv2_adapter_init()\n\t dvb_usbv2_adapter_frontend_init()\n\t props->frontend_attach()\n\n\t props->init()\n\nSince mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()\ninternally we need to initialize state->msg_lock before\nfrontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*\ndevices, which will simply initiaize mutex."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mxl111sf: change mutex_init() location\n\nSyzbot reported, that mxl111sf_ctrl_msg() uses uninitialized\nmutex. The problem was in wrong mutex_init() location.\n\nPrevious mutex_init(&state->msg_lock) call was in ->init() function, but\ndvb_usbv2_init() has this order of calls:\n\n\tdvb_usbv2_init()\n\t dvb_usbv2_adapter_init()\n\t dvb_usbv2_adapter_frontend_init()\n\t props->frontend_attach()\n\n\t props->init()\n\nSince mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()\ninternally we need to initialize state->msg_lock before\nfrontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*\ndevices, which will simply initiaize mutex."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: medio: mxl111sf: cambiar la ubicaci\u00f3n de mutex_init() Syzbot inform\u00f3 que mxl111sf_ctrl_msg() usa un mutex no inicializado. El problema estaba en la ubicaci\u00f3n mutex_init() incorrecta. La llamada anterior a mutex_init(&state->msg_lock) estaba en la funci\u00f3n ->init(), pero dvb_usbv2_init() tiene este orden de llamadas: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Desde Los dispositivos mxl111sf_* llaman a mxl111sf_ctrl_msg() en ->frontend_attach() internamente, necesitamos inicializar state->msg_lock antes de frontend_attach(). Para lograrlo, se agrega la llamada ->probe() a todos los dispositivos mxl111sf_*, lo que simplemente iniciar\u00e1 el mutex."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47584",
|
"id": "CVE-2021-47584",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:52.947",
|
"published": "2024-06-19T15:15:52.947",
|
||||||
"lastModified": "2024-06-19T15:15:52.947",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niocost: Fix divide-by-zero on donation from low hweight cgroup\n\nThe donation calculation logic assumes that the donor has non-zero\nafter-donation hweight, so the lowest active hweight a donating cgroup can\nhave is 2 so that it can donate 1 while keeping the other 1 for itself.\nEarlier, we only donated from cgroups with sizable surpluses so this\ncondition was always true. However, with the precise donation algorithm\nimplemented, f1de2439ec43 (\"blk-iocost: revamp donation amount\ndetermination\") made the donation amount calculation exact enabling even low\nhweight cgroups to donate.\n\nThis means that in rare occasions, a cgroup with active hweight of 1 can\nenter donation calculation triggering the following warning and then a\ndivide-by-zero oops.\n\n WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]\n ...\n RIP: 0010:transfer_surpluses.cold+0x0/0x53\n Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0\n4\n ...\n Call Trace:\n <IRQ>\n ioc_timer_fn+0x1043/0x1390\n call_timer_fn+0xa1/0x2c0\n __run_timers.part.0+0x1ec/0x2e0\n run_timer_softirq+0x35/0x70\n ...\n iocg: invalid donation weights in /a/b: active=1 donating=1 after=0\n\nFix it by excluding cgroups w/ active hweight < 2 from donating. Excluding\nthese extreme low hweight donations shouldn't affect work conservation in\nany meaningful way."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niocost: Fix divide-by-zero on donation from low hweight cgroup\n\nThe donation calculation logic assumes that the donor has non-zero\nafter-donation hweight, so the lowest active hweight a donating cgroup can\nhave is 2 so that it can donate 1 while keeping the other 1 for itself.\nEarlier, we only donated from cgroups with sizable surpluses so this\ncondition was always true. However, with the precise donation algorithm\nimplemented, f1de2439ec43 (\"blk-iocost: revamp donation amount\ndetermination\") made the donation amount calculation exact enabling even low\nhweight cgroups to donate.\n\nThis means that in rare occasions, a cgroup with active hweight of 1 can\nenter donation calculation triggering the following warning and then a\ndivide-by-zero oops.\n\n WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]\n ...\n RIP: 0010:transfer_surpluses.cold+0x0/0x53\n Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0\n4\n ...\n Call Trace:\n <IRQ>\n ioc_timer_fn+0x1043/0x1390\n call_timer_fn+0xa1/0x2c0\n __run_timers.part.0+0x1ec/0x2e0\n run_timer_softirq+0x35/0x70\n ...\n iocg: invalid donation weights in /a/b: active=1 donating=1 after=0\n\nFix it by excluding cgroups w/ active hweight < 2 from donating. Excluding\nthese extreme low hweight donations shouldn't affect work conservation in\nany meaningful way."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iocost: corrige la divisi\u00f3n por cero en la donaci\u00f3n de un grupo c de bajo peso. La l\u00f3gica de c\u00e1lculo de la donaci\u00f3n supone que el donante tiene un peso posterior a la donaci\u00f3n distinto de cero, por lo que el peso activo m\u00e1s bajo es una donaci\u00f3n. cgroup puede tener 2 para poder donar 1 y conservar el otro para s\u00ed mismo. Anteriormente, solo don\u00e1bamos de grupos comunitarios con excedentes considerables, por lo que esta condici\u00f3n siempre fue cierta. Sin embargo, con el algoritmo de donaci\u00f3n preciso implementado, f1de2439ec43 (\"blk-iocost: renovar la determinaci\u00f3n del monto de la donaci\u00f3n\") hizo que el c\u00e1lculo del monto de la donaci\u00f3n fuera exacto, permitiendo que incluso los grupos de bajo peso donaran. Esto significa que, en raras ocasiones, un grupo con un peso activo de 1 puede ingresar al c\u00e1lculo de la donaci\u00f3n, lo que genera la siguiente advertencia y luego una divisi\u00f3n por cero. ADVERTENCIA: CPU: 4 PID: 0 en block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867] ... RIP: 0010:transfer_surpluses.cold+0x0/0x53 C\u00f3digo: 92 y siguientes 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0 4 ... Seguimiento de llamadas: ioc_timer_fn+0x1043/0x1390 call_timer_fn+0xa1/0x2c0 __run_timers.part.0+0x1ec/0x2e0 run_timer_softirq+0x35/0x70 ... iocg : pesos de donaci\u00f3n no v\u00e1lidos en /a/b: activo=1 donaci\u00f3n=1 despu\u00e9s=0 Corr\u00edjalo excluyendo cgroups con hweight activo < 2 de la donaci\u00f3n. Excluir estas donaciones de peso extremadamente bajo no deber\u00eda afectar la conservaci\u00f3n del trabajo de ninguna manera significativa."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47585",
|
"id": "CVE-2021-47585",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.057",
|
"published": "2024-06-19T15:15:53.057",
|
||||||
"lastModified": "2024-06-19T15:15:53.057",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory leak in __add_inode_ref()\n\nLine 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),\nbut when the function returns in line 1184 (#4) victim_name allocated\nby line 1169 (#3) is not freed, which will lead to a memory leak.\nThere is a similar snippet of code in this function as allocating a memory\nchunk for victim_name in line 1104 (#1) as well as releasing the memory\nin line 1116 (#2).\n\nWe should kfree() victim_name when the return value of backref_in_log()\nis less than zero and before the function returns in line 1184 (#4).\n\n1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,\n1058 \t\t\t\t struct btrfs_root *root,\n1059 \t\t\t\t struct btrfs_path *path,\n1060 \t\t\t\t struct btrfs_root *log_root,\n1061 \t\t\t\t struct btrfs_inode *dir,\n1062 \t\t\t\t struct btrfs_inode *inode,\n1063 \t\t\t\t u64 inode_objectid, u64 parent_objectid,\n1064 \t\t\t\t u64 ref_index, char *name, int namelen,\n1065 \t\t\t\t int *search_done)\n1066 {\n\n1104 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #1: kmalloc (victim_name-1)\n1105 \tif (!victim_name)\n1106 \t\treturn -ENOMEM;\n\n1112\tret = backref_in_log(log_root, &search_key,\n1113\t\t\tparent_objectid, victim_name,\n1114\t\t\tvictim_name_len);\n1115\tif (ret < 0) {\n1116\t\tkfree(victim_name); // #2: kfree (victim_name-1)\n1117\t\treturn ret;\n1118\t} else if (!ret) {\n\n1169 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #3: kmalloc (victim_name-2)\n1170 \tif (!victim_name)\n1171 \t\treturn -ENOMEM;\n\n1180 \tret = backref_in_log(log_root, &search_key,\n1181 \t\t\tparent_objectid, victim_name,\n1182 \t\t\tvictim_name_len);\n1183 \tif (ret < 0) {\n1184 \t\treturn ret; // #4: missing kfree (victim_name-2)\n1185 \t} else if (!ret) {\n\n1241 \treturn 0;\n1242 }"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory leak in __add_inode_ref()\n\nLine 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),\nbut when the function returns in line 1184 (#4) victim_name allocated\nby line 1169 (#3) is not freed, which will lead to a memory leak.\nThere is a similar snippet of code in this function as allocating a memory\nchunk for victim_name in line 1104 (#1) as well as releasing the memory\nin line 1116 (#2).\n\nWe should kfree() victim_name when the return value of backref_in_log()\nis less than zero and before the function returns in line 1184 (#4).\n\n1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,\n1058 \t\t\t\t struct btrfs_root *root,\n1059 \t\t\t\t struct btrfs_path *path,\n1060 \t\t\t\t struct btrfs_root *log_root,\n1061 \t\t\t\t struct btrfs_inode *dir,\n1062 \t\t\t\t struct btrfs_inode *inode,\n1063 \t\t\t\t u64 inode_objectid, u64 parent_objectid,\n1064 \t\t\t\t u64 ref_index, char *name, int namelen,\n1065 \t\t\t\t int *search_done)\n1066 {\n\n1104 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #1: kmalloc (victim_name-1)\n1105 \tif (!victim_name)\n1106 \t\treturn -ENOMEM;\n\n1112\tret = backref_in_log(log_root, &search_key,\n1113\t\t\tparent_objectid, victim_name,\n1114\t\t\tvictim_name_len);\n1115\tif (ret < 0) {\n1116\t\tkfree(victim_name); // #2: kfree (victim_name-1)\n1117\t\treturn ret;\n1118\t} else if (!ret) {\n\n1169 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #3: kmalloc (victim_name-2)\n1170 \tif (!victim_name)\n1171 \t\treturn -ENOMEM;\n\n1180 \tret = backref_in_log(log_root, &search_key,\n1181 \t\t\tparent_objectid, victim_name,\n1182 \t\t\tvictim_name_len);\n1183 \tif (ret < 0) {\n1184 \t\treturn ret; // #4: missing kfree (victim_name-2)\n1185 \t} else if (!ret) {\n\n1241 \treturn 0;\n1242 }"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: btrfs: corrige la p\u00e9rdida de memoria en __add_inode_ref() La l\u00ednea 1169 (#3) asigna un fragmento de memoria para victim_name mediante kmalloc(), pero cuando la funci\u00f3n regresa en la l\u00ednea 1184 (#4) victim_name asignado por la l\u00ednea 1169 (#3) no se libera, lo que provocar\u00e1 una p\u00e9rdida de memoria. Hay un fragmento de c\u00f3digo similar en esta funci\u00f3n para asignar un fragmento de memoria para victim_name en la l\u00ednea 1104 (n.\u00ba 1), as\u00ed como para liberar la memoria en la l\u00ednea 1116 (n.\u00ba 2). Deber\u00edamos kfree() victim_name cuando el valor de retorno de backref_in_log() sea menor que cero y antes de que la funci\u00f3n regrese en la l\u00ednea 1184 (#4). 1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans, 1058 struct btrfs_root *root, 1059 struct btrfs_path *path, 1060 struct btrfs_root *log_root, 1061 struct btrfs_inode *dir, 1062 struct btrfs_inode *inode, 63 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char *nombre, int nombrelen, 1065 int *search_done) 1066 { 1104 nombre_v\u00edctima = kmalloc(nombre_v\u00edctima_len, GFP_NOFS); // #1: kmalloc (nombre_v\u00edctima-1) 1105 if (!nombre_v\u00edctima) 1106 return -ENOMEM; 1112 ret = backref_in_log(log_root, &search_key, 1113 parent_objectid, victim_name, 1114 victim_name_len); 1115 if (ret < 0) { 1116 kfree(nombre_v\u00edctima); // #2: kfree (nombre_v\u00edctima-1) 1117 return ret; 1118 } else if (!ret) { 1169 nombre_v\u00edctima = kmalloc(nombre_v\u00edctima_len, GFP_NOFS); // #3: kmalloc (nombre_v\u00edctima-2) 1170 if (!nombre_v\u00edctima) 1171 return -ENOMEM; 1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 si (ret < 0) { 1184 retorno ret; // #4: falta kfree (nombre_v\u00edctima-2) 1185 } else if (!ret) { 1241 return 0; 1242 }"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47586",
|
"id": "CVE-2021-47586",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.160",
|
"published": "2024-06-19T15:15:53.160",
|
||||||
"lastModified": "2024-06-19T15:15:53.160",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-rk: fix oob read in rk_gmac_setup\n\nKASAN reports an out-of-bounds read in rk_gmac_setup on the line:\n\n\twhile (ops->regs[i]) {\n\nThis happens for most platforms since the regs flexible array member is\nempty, so the memory after the ops structure is being read here. It\nseems that mostly this happens to contain zero anyway, so we get lucky\nand everything still works.\n\nTo avoid adding redundant data to nearly all the ops structures, add a\nnew flag to indicate whether the regs field is valid and avoid this loop\nwhen it is not."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-rk: fix oob read in rk_gmac_setup\n\nKASAN reports an out-of-bounds read in rk_gmac_setup on the line:\n\n\twhile (ops->regs[i]) {\n\nThis happens for most platforms since the regs flexible array member is\nempty, so the memory after the ops structure is being read here. It\nseems that mostly this happens to contain zero anyway, so we get lucky\nand everything still works.\n\nTo avoid adding redundant data to nearly all the ops structures, add a\nnew flag to indicate whether the regs field is valid and avoid this loop\nwhen it is not."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup KASAN informa una lectura fuera de los l\u00edmites en rk_gmac_setup en la l\u00ednea: while (ops->regs[i]) { Esto sucede en la mayor\u00eda de las plataformas, ya que el miembro de la matriz flexible regs est\u00e1 vac\u00edo, por lo que aqu\u00ed se lee la memoria despu\u00e9s de la estructura de operaciones. Parece que la mayor parte de esto contiene cero de todos modos, as\u00ed que tenemos suerte y todo sigue funcionando. Para evitar agregar datos redundantes a casi todas las estructuras de operaciones, agregue un nuevo indicador para indicar si el campo regs es v\u00e1lido y evite este bucle cuando no lo sea."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47587",
|
"id": "CVE-2021-47587",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.260",
|
"published": "2024-06-19T15:15:53.260",
|
||||||
"lastModified": "2024-06-19T15:15:53.260",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: systemport: agregue bloqueo global para el ciclo de vida del descriptor. La lista de descriptores es un recurso compartido entre todas las colas de transmisi\u00f3n y el mecanismo de bloqueo que se usa hoy solo protege la concurrencia en una cola de transmisi\u00f3n determinada. entre la transmisi\u00f3n y la recuperaci\u00f3n. Esto crea una oportunidad para que el hardware de SYSTEMPORT funcione con descriptores corruptos si tenemos varios productores a la vez, como es el caso cuando utilizamos varias colas de transmisi\u00f3n. Esto fue particularmente notable cuando se usaban m\u00faltiples flujos/colas de transmisi\u00f3n y se mostr\u00f3 de manera interesante en que los paquetes UDP obtendr\u00edan una suma de verificaci\u00f3n de encabezado UDP correcta al calcularse sobre una longitud de paquete incorrecta. De manera similar, los paquetes TCP obtendr\u00edan una suma de verificaci\u00f3n igualmente correcta calculada por el hardware en una longitud de paquete incorrecta. El hardware de SYSTEMPORT mantiene una lista de descriptores internos que reorganiza cuando el controlador produce un nuevo descriptor cada vez que escribe en los registros WRITE_PORT_{HI,LO}. Sin embargo, hay cierto retraso en el hardware para reorganizar sus descriptores y es Es posible que las colas de TX simult\u00e1neas eventualmente rompan este esquema de asignaci\u00f3n interna hasta el punto en que la parte de longitud/estado del descriptor se use para un b\u00fafer de datos incorrecto. La soluci\u00f3n es imponer una serializaci\u00f3n global para todas las colas de TX en la secci\u00f3n corta donde escribimos en los registros WRITE_PORT_{HI,LO}, lo que resuelve la corrupci\u00f3n incluso cuando se utilizan varias colas de TX simult\u00e1neas."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47588",
|
"id": "CVE-2021-47588",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.383",
|
"published": "2024-06-19T15:15:53.383",
|
||||||
"lastModified": "2024-06-19T15:15:53.383",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsit: do not call ipip6_dev_free() from sit_init_net()\n\nipip6_dev_free is sit dev->priv_destructor, already called\nby register_netdevice() if something goes wrong.\n\nAlternative would be to make ipip6_dev_free() robust against\nmultiple invocations, but other drivers do not implement this\nstrategy.\n\nsyzbot reported:\n\ndst_release underflow\nWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173\nModules linked in:\nCPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173\nCode: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48\nRSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246\nRAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000\nRDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000\nRBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c\nR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358\nR13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000\nFS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160\n ipip6_dev_free net/ipv6/sit.c:1414 [inline]\n sit_init_net+0x229/0x550 net/ipv6/sit.c:1936\n ops_init+0x313/0x430 net/core/net_namespace.c:140\n setup_net+0x35b/0x9d0 net/core/net_namespace.c:326\n copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470\n create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226\n ksys_unshare+0x57d/0xb50 kernel/fork.c:3075\n __do_sys_unshare kernel/fork.c:3146 [inline]\n __se_sys_unshare kernel/fork.c:3144 [inline]\n __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f66c882ce99\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200\nRBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000\n </TASK>"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsit: do not call ipip6_dev_free() from sit_init_net()\n\nipip6_dev_free is sit dev->priv_destructor, already called\nby register_netdevice() if something goes wrong.\n\nAlternative would be to make ipip6_dev_free() robust against\nmultiple invocations, but other drivers do not implement this\nstrategy.\n\nsyzbot reported:\n\ndst_release underflow\nWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173\nModules linked in:\nCPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173\nCode: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48\nRSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246\nRAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000\nRDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000\nRBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c\nR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358\nR13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000\nFS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160\n ipip6_dev_free net/ipv6/sit.c:1414 [inline]\n sit_init_net+0x229/0x550 net/ipv6/sit.c:1936\n ops_init+0x313/0x430 net/core/net_namespace.c:140\n setup_net+0x35b/0x9d0 net/core/net_namespace.c:326\n copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470\n create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226\n ksys_unshare+0x57d/0xb50 kernel/fork.c:3075\n __do_sys_unshare kernel/fork.c:3146 [inline]\n __se_sys_unshare kernel/fork.c:3144 [inline]\n __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f66c882ce99\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200\nRBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000\n </TASK>"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sit: no llame a ipip6_dev_free() desde sit_init_net() ipip6_dev_free es sit dev->priv_destructor, ya llamado por Register_netdevice() si algo sale mal. La alternativa ser\u00eda hacer que ipip6_dev_free() sea robusto contra m\u00faltiples invocaciones, pero otros controladores no implementan esta estrategia. syzbot inform\u00f3: dst_release underflow ADVERTENCIA: CPU: 0 PID: 5059 en net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 M\u00f3dulos vinculados en: CPU: 1 PID: 5059 Comm: syz -executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c :173 C\u00f3digo: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08 : ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb135 8 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ ipv6/sit.c:1414 [en l\u00ednea] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c :326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 .c :3075 __do_sys_unshare kernel/fork.c:3146 [en l\u00ednea] __se_sys_unshare kernel/fork.c:3144 [en l\u00ednea] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea ] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 C\u00f3digo: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 1f 40 00 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 bc ff ff ff f7 d8 64 89 01 48 RSP:00 007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000 000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000 00246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000 "
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47589",
|
"id": "CVE-2021-47589",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.490",
|
"published": "2024-06-19T15:15:53.490",
|
||||||
"lastModified": "2024-06-19T15:15:53.490",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigbvf: fix double free in `igbvf_probe`\n\nIn `igbvf_probe`, if register_netdev() fails, the program will go to\nlabel err_hw_init, and then to label err_ioremap. In free_netdev() which\nis just below label err_ioremap, there is `list_for_each_entry_safe` and\n`netif_napi_del` which aims to delete all entries in `dev->napi_list`.\nThe program has added an entry `adapter->rx_ring->napi` which is added by\n`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has\nbeen freed below label err_hw_init. So this a UAF.\n\nIn terms of how to patch the problem, we can refer to igbvf_remove() and\ndelete the entry before `adapter->rx_ring`.\n\nThe KASAN logs are as follows:\n\n[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450\n[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366\n[ 35.128360]\n[ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14\n[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 35.131749] Call Trace:\n[ 35.132199] dump_stack_lvl+0x59/0x7b\n[ 35.132865] print_address_description+0x7c/0x3b0\n[ 35.133707] ? free_netdev+0x1fd/0x450\n[ 35.134378] __kasan_report+0x160/0x1c0\n[ 35.135063] ? free_netdev+0x1fd/0x450\n[ 35.135738] kasan_report+0x4b/0x70\n[ 35.136367] free_netdev+0x1fd/0x450\n[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]\n[ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]\n[ 35.138751] local_pci_probe+0x13c/0x1f0\n[ 35.139461] pci_device_probe+0x37e/0x6c0\n[ 35.165526]\n[ 35.165806] Allocated by task 366:\n[ 35.166414] ____kasan_kmalloc+0xc4/0xf0\n[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]\n[ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]\n[ 35.168866] local_pci_probe+0x13c/0x1f0\n[ 35.169565] pci_device_probe+0x37e/0x6c0\n[ 35.179713]\n[ 35.179993] Freed by task 366:\n[ 35.180539] kasan_set_track+0x4c/0x80\n[ 35.181211] kasan_set_free_info+0x1f/0x40\n[ 35.181942] ____kasan_slab_free+0x103/0x140\n[ 35.182703] kfree+0xe3/0x250\n[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]\n[ 35.184040] local_pci_probe+0x13c/0x1f0"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigbvf: fix double free in `igbvf_probe`\n\nIn `igbvf_probe`, if register_netdev() fails, the program will go to\nlabel err_hw_init, and then to label err_ioremap. In free_netdev() which\nis just below label err_ioremap, there is `list_for_each_entry_safe` and\n`netif_napi_del` which aims to delete all entries in `dev->napi_list`.\nThe program has added an entry `adapter->rx_ring->napi` which is added by\n`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has\nbeen freed below label err_hw_init. So this a UAF.\n\nIn terms of how to patch the problem, we can refer to igbvf_remove() and\ndelete the entry before `adapter->rx_ring`.\n\nThe KASAN logs are as follows:\n\n[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450\n[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366\n[ 35.128360]\n[ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14\n[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 35.131749] Call Trace:\n[ 35.132199] dump_stack_lvl+0x59/0x7b\n[ 35.132865] print_address_description+0x7c/0x3b0\n[ 35.133707] ? free_netdev+0x1fd/0x450\n[ 35.134378] __kasan_report+0x160/0x1c0\n[ 35.135063] ? free_netdev+0x1fd/0x450\n[ 35.135738] kasan_report+0x4b/0x70\n[ 35.136367] free_netdev+0x1fd/0x450\n[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]\n[ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]\n[ 35.138751] local_pci_probe+0x13c/0x1f0\n[ 35.139461] pci_device_probe+0x37e/0x6c0\n[ 35.165526]\n[ 35.165806] Allocated by task 366:\n[ 35.166414] ____kasan_kmalloc+0xc4/0xf0\n[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]\n[ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]\n[ 35.168866] local_pci_probe+0x13c/0x1f0\n[ 35.169565] pci_device_probe+0x37e/0x6c0\n[ 35.179713]\n[ 35.179993] Freed by task 366:\n[ 35.180539] kasan_set_track+0x4c/0x80\n[ 35.181211] kasan_set_free_info+0x1f/0x40\n[ 35.181942] ____kasan_slab_free+0x103/0x140\n[ 35.182703] kfree+0xe3/0x250\n[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]\n[ 35.184040] local_pci_probe+0x13c/0x1f0"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igbvf: corrige double free en `igbvf_probe` En `igbvf_probe`, si Register_netdev() falla, el programa ir\u00e1 a la etiqueta err_hw_init y luego a la etiqueta err_ioremap. En free_netdev(), que est\u00e1 justo debajo de la etiqueta err_ioremap, est\u00e1n `list_for_each_entry_safe` y `netif_napi_del` que tienen como objetivo eliminar todas las entradas en `dev->napi_list`. El programa ha agregado una entrada `adapter->rx_ring->napi` que se agrega mediante `netif_napi_add` en igbvf_alloc_queues(). Sin embargo, adaptador->rx_ring se ha liberado debajo de la etiqueta err_hw_init. Entonces esto es una UAF. En t\u00e9rminos de c\u00f3mo solucionar el problema, podemos consultar igbvf_remove() y eliminar la entrada antes de `adapter->rx_ring`. Los registros de KASAN son los siguientes: [35.126075] ERROR: KASAN: use-after-free en free_netdev+0x1fd/0x450 [35.127170] Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff88810126d990 mediante la tarea modprobe/366 [35.128360] [35.128643] CPU: 1 PID : 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01 /2014 [35.131749] Seguimiento de llamadas: [35.132199] dump_stack_lvl+0x59/0x7b [35.132865] print_address_description+0x7c/0x3b0 [35.133707] ? free_netdev+0x1fd/0x450 [ 35.134378] __kasan_report+0x160/0x1c0 [ 35.135063] ? free_netdev+0x1fd/0x450 [ 35.135738] kasan_report+0x4b/0x70 [ 35.136367] free_netdev+0x1fd/0x450 [ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf] [ 35.137808 ] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf] [ 35.138751] local_pci_probe+0x13c/0x1f0 [ 35.139461] pci_device_probe+0x37e/0x6c0 [ 35.165526] [ 35.165806] por tarea 366: [35.166414] ____kasan_kmalloc+0xc4/0xf0 [35.167117] foo_kmem_cache_alloc_trace+0x3c/ 0x50 [igbvf] [ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf] [ 35.168866] local_pci_probe+0x13c/0x1f0 [ 35.169565] pci_device_probe+0x37e/0x6c0 [ 35.179713 ] [35.179993] Liberado por la tarea 366: [35.180539] kasan_set_track+0x4c/0x80 [ 35.181211] kasan_set_free_info+0x1f/0x40 [ 35.181942] ____kasan_slab_free+0x103/0x140 [ 35.182703] kfree+0xe3/0x250 [ 35.183239] igbvf_probe+0x1173/0x1a10 vf] [35.184040] local_pci_probe+0x13c/0x1f0"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47590",
|
"id": "CVE-2021-47590",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.610",
|
"published": "2024-06-19T15:15:53.610",
|
||||||
"lastModified": "2024-06-19T15:15:53.610",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix deadlock in __mptcp_push_pending()\n\n__mptcp_push_pending() may call mptcp_flush_join_list() with subflow\nsocket lock held. If such call hits mptcp_sockopt_sync_all() then\nsubsequently __mptcp_sockopt_sync() could try to lock the subflow\nsocket for itself, causing a deadlock.\n\nsysrq: Show Blocked State\ntask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000\nCall Trace:\n <TASK>\n __schedule+0x2d6/0x10c0\n ? __mod_memcg_state+0x4d/0x70\n ? csum_partial+0xd/0x20\n ? _raw_spin_lock_irqsave+0x26/0x50\n schedule+0x4e/0xc0\n __lock_sock+0x69/0x90\n ? do_wait_intr_irq+0xa0/0xa0\n __lock_sock_fast+0x35/0x50\n mptcp_sockopt_sync_all+0x38/0xc0\n __mptcp_push_pending+0x105/0x200\n mptcp_sendmsg+0x466/0x490\n sock_sendmsg+0x57/0x60\n __sys_sendto+0xf0/0x160\n ? do_wait_intr_irq+0xa0/0xa0\n ? fpregs_restore_userregs+0x12/0xd0\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9ba546c2d0\nRSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0\nRDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234\nRBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060\nR13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8\n </TASK>\n\nFix the issue by using __mptcp_flush_join_list() instead of plain\nmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by\nFlorian. The sockopt sync will be deferred to the workqueue."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix deadlock in __mptcp_push_pending()\n\n__mptcp_push_pending() may call mptcp_flush_join_list() with subflow\nsocket lock held. If such call hits mptcp_sockopt_sync_all() then\nsubsequently __mptcp_sockopt_sync() could try to lock the subflow\nsocket for itself, causing a deadlock.\n\nsysrq: Show Blocked State\ntask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000\nCall Trace:\n <TASK>\n __schedule+0x2d6/0x10c0\n ? __mod_memcg_state+0x4d/0x70\n ? csum_partial+0xd/0x20\n ? _raw_spin_lock_irqsave+0x26/0x50\n schedule+0x4e/0xc0\n __lock_sock+0x69/0x90\n ? do_wait_intr_irq+0xa0/0xa0\n __lock_sock_fast+0x35/0x50\n mptcp_sockopt_sync_all+0x38/0xc0\n __mptcp_push_pending+0x105/0x200\n mptcp_sendmsg+0x466/0x490\n sock_sendmsg+0x57/0x60\n __sys_sendto+0xf0/0x160\n ? do_wait_intr_irq+0xa0/0xa0\n ? fpregs_restore_userregs+0x12/0xd0\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9ba546c2d0\nRSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0\nRDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234\nRBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060\nR13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8\n </TASK>\n\nFix the issue by using __mptcp_flush_join_list() instead of plain\nmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by\nFlorian. The sockopt sync will be deferred to the workqueue."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mptcp: corrige el punto muerto en __mptcp_push_pending() __mptcp_push_pending() puede llamar a mptcp_flush_join_list() con el bloqueo del socket de subflujo retenido. Si dicha llamada llega a mptcp_sockopt_sync_all(), posteriormente __mptcp_sockopt_sync() podr\u00eda intentar bloquear el socket de subflujo por s\u00ed mismo, provocando un punto muerto. sysrq: Mostrar estado bloqueado tarea: estado del servidor ss: D pila: 0 pid: 938 ppid: 1 banderas: 0x00000000 Seguimiento de llamadas: __schedule+0x2d6/0x10c0? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20? _raw_spin_lock_irqsave+0x26/0x50 horario+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160? do_wait_intr_irq+0xa0/0xa0? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9ba546c2d0 RSP: dc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0 RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234 RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060 R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8 Solucione el problema usando __mptcp_flush_join_list() en su lugar de mptcp_flush_join_list() simple dentro __mptcp_push_pending(), como sugiere Florian. La sincronizaci\u00f3n de sockopt se aplazar\u00e1 a la cola de trabajo."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47591",
|
"id": "CVE-2021-47591",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.700",
|
"published": "2024-06-19T15:15:53.700",
|
||||||
"lastModified": "2024-06-19T15:15:53.700",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: remove tcp ulp setsockopt support\n\nTCP_ULP setsockopt cannot be used for mptcp because its already\nused internally to plumb subflow (tcp) sockets to the mptcp layer.\n\nsyzbot managed to trigger a crash for mptcp connections that are\nin fallback mode:\n\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nCPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0\nRIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline]\n[..]\n __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]\n tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160\n do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391\n mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638\n\nRemove support for TCP_ULP setsockopt."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: remove tcp ulp setsockopt support\n\nTCP_ULP setsockopt cannot be used for mptcp because its already\nused internally to plumb subflow (tcp) sockets to the mptcp layer.\n\nsyzbot managed to trigger a crash for mptcp connections that are\nin fallback mode:\n\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nCPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0\nRIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline]\n[..]\n __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]\n tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160\n do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391\n mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638\n\nRemove support for TCP_ULP setsockopt."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mptcp: elimina el soporte de tcp ulp setsockopt TCP_ULP setsockopt no se puede usar para mptcp porque ya se usa internamente para conectar sockets de subflujo (tcp) a la capa mptcp. syzbot logr\u00f3 desencadenar un bloqueo para las conexiones mptcp que est\u00e1n en modo alternativo: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2- syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [en l\u00ednea] [..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [en l\u00ednea] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c: 160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638 Elimina la compatibilidad con TCP_ULP setsockopt."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47592",
|
"id": "CVE-2021-47592",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.793",
|
"published": "2024-06-19T15:15:53.793",
|
||||||
"lastModified": "2024-06-19T15:15:53.793",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix tc flower deletion for VLAN priority Rx steering\n\nTo replicate the issue:-\n\n1) Add 1 flower filter for VLAN Priority based frame steering:-\n$ IFDEVNAME=eth0\n$ tc qdisc add dev $IFDEVNAME ingress\n$ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \\\n map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \\\n queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0\n$ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \\\n flower vlan_prio 0 hw_tc 0\n\n2) Get the 'pref' id\n$ tc filter show dev $IFDEVNAME ingress\n\n3) Delete a specific tc flower record (say pref 49151)\n$ tc filter del dev $IFDEVNAME parent ffff: pref 49151\n\nFrom dmesg, we will observe kernel NULL pointer ooops\n\n[ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 197.171367] #PF: supervisor read access in kernel mode\n[ 197.171367] #PF: error_code(0x0000) - not-present page\n[ 197.171367] PGD 0 P4D 0\n[ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI\n\n<snip>\n\n[ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]\n\n<snip>\n\n[ 197.171367] Call Trace:\n[ 197.171367] <TASK>\n[ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]\n[ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]\n[ 197.171367] tc_setup_cb_destroy+0xb3/0x180\n[ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n\nThe above issue is due to previous incorrect implementation of\ntc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()\nto get struct flow_rule *rule which is no longer valid for tc filter\ndelete operation.\n\n struct flow_rule *rule = flow_cls_offload_flow_rule(cls);\n struct flow_dissector *dissector = rule->match.dissector;\n\nSo, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for\nearlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),\nthis patch introduces stmmac_rfs_entry as driver-side flow_cls_offload\nrecord for 'RX frame steering' tc flower, currently used for VLAN\npriority. The implementation has taken consideration for future extension\nto include other type RX frame steering such as EtherType based.\n\nv2:\n - Clean up overly extensive backtrace and rewrite git message to better\n explain the kernel NULL pointer issue."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix tc flower deletion for VLAN priority Rx steering\n\nTo replicate the issue:-\n\n1) Add 1 flower filter for VLAN Priority based frame steering:-\n$ IFDEVNAME=eth0\n$ tc qdisc add dev $IFDEVNAME ingress\n$ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \\\n map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \\\n queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0\n$ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \\\n flower vlan_prio 0 hw_tc 0\n\n2) Get the 'pref' id\n$ tc filter show dev $IFDEVNAME ingress\n\n3) Delete a specific tc flower record (say pref 49151)\n$ tc filter del dev $IFDEVNAME parent ffff: pref 49151\n\nFrom dmesg, we will observe kernel NULL pointer ooops\n\n[ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 197.171367] #PF: supervisor read access in kernel mode\n[ 197.171367] #PF: error_code(0x0000) - not-present page\n[ 197.171367] PGD 0 P4D 0\n[ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI\n\n<snip>\n\n[ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]\n\n<snip>\n\n[ 197.171367] Call Trace:\n[ 197.171367] <TASK>\n[ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]\n[ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]\n[ 197.171367] tc_setup_cb_destroy+0xb3/0x180\n[ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n\nThe above issue is due to previous incorrect implementation of\ntc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()\nto get struct flow_rule *rule which is no longer valid for tc filter\ndelete operation.\n\n struct flow_rule *rule = flow_cls_offload_flow_rule(cls);\n struct flow_dissector *dissector = rule->match.dissector;\n\nSo, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for\nearlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),\nthis patch introduces stmmac_rfs_entry as driver-side flow_cls_offload\nrecord for 'RX frame steering' tc flower, currently used for VLAN\npriority. The implementation has taken consideration for future extension\nto include other type RX frame steering such as EtherType based.\n\nv2:\n - Clean up overly extensive backtrace and rewrite git message to better\n explain the kernel NULL pointer issue."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: stmmac: corrija la eliminaci\u00f3n de flores tc para la direcci\u00f3n Rx con prioridad de VLAN Para replicar el problema: - 1) Agregue 1 filtro de flores para la direcci\u00f3n de cuadros basada en prioridad de VLAN: - $ IFDEVNAME=eth0 $ tc qdisc agregar dev $IFDEVNAME ingreso $ tc qdisc agregar dev $IFDEVNAME ra\u00edz mqprio num_tc 8 \\ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 \\ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc filter add dev $IFDEVNAME parent ffff: protocolo 802.1Q \\ flower vlan_prio 0 hw_tc 0 2) Obtener el id 'pref' $ tc filter show dev $IFDEVNAME ingress 3 ) Eliminar un registro de flor tc espec\u00edfico (digamos pref 49151) $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 Desde dmesg, observaremos el puntero NULL del kernel ooops [ 197.170464] ERROR: desreferencia del puntero NULL del kernel, direcci\u00f3n: 00000000000000000 [ 197.171367] #PF: acceso de lectura de supervisor en modo kernel [ 197.171367] #PF: error_code(0x0000) - p\u00e1gina no presente [ 197.171367] PGD 0 P4D 0 [ 197.171367] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac] [ 197.171367] Seguimiento de llamadas: [ 197.171367] [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac] [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac] [ 197.171367] tc_setup_cb_destroy+0xb3/0x180 [ 197.171367] destroy_filter+0x94/0xc0 [cls_flower] El problema anterior se debe a una implementaci\u00f3n anterior incorrecta de tc_del_vlan_flow( ), que se muestra a continuaci\u00f3n, que usa flow_cls_offload_flow_rule() para obtener la estructura flow_rule *rule que ya no es v\u00e1lida para la operaci\u00f3n de eliminaci\u00f3n del filtro tc. estructura flow_rule *regla = flow_cls_offload_flow_rule(cls); estructura flow_dissector *dissector = regla->match.dissector; Por lo tanto, para garantizar que tc_del_vlan_flow() elimine el registro VLAN cls correcto para la cola RX configurada anteriormente (configurada por hw_tc) en tc_add_vlan_flow(), este parche introduce stmmac_rfs_entry como registro flow_cls_offload del lado del controlador para la flor tc 'Direcci\u00f3n de trama RX', actualmente utilizada para Prioridad de VLAN. La implementaci\u00f3n ha tenido en cuenta una futura ampliaci\u00f3n para incluir otro tipo de direcci\u00f3n de bastidor RX, como la basada en EtherType. v2: - Limpiar el rastreo demasiado extenso y reescribir el mensaje de git para explicar mejor el problema del puntero NULL del kernel."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47593",
|
"id": "CVE-2021-47593",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.890",
|
"published": "2024-06-19T15:15:53.890",
|
||||||
"lastModified": "2024-06-19T15:15:53.890",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: clear 'kern' flag from fallback sockets\n\nThe mptcp ULP extension relies on sk->sk_sock_kern being set correctly:\nIt prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, \"mptcp\", 6); from\nworking for plain tcp sockets (any userspace-exposed socket).\n\nBut in case of fallback, accept() can return a plain tcp sk.\nIn such case, sk is still tagged as 'kernel' and setsockopt will work.\n\nThis will crash the kernel, The subflow extension has a NULL ctx->conn\nmptcp socket:\n\nBUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0\nCall Trace:\n tcp_data_ready+0xf8/0x370\n [..]"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: clear 'kern' flag from fallback sockets\n\nThe mptcp ULP extension relies on sk->sk_sock_kern being set correctly:\nIt prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, \"mptcp\", 6); from\nworking for plain tcp sockets (any userspace-exposed socket).\n\nBut in case of fallback, accept() can return a plain tcp sk.\nIn such case, sk is still tagged as 'kernel' and setsockopt will work.\n\nThis will crash the kernel, The subflow extension has a NULL ctx->conn\nmptcp socket:\n\nBUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0\nCall Trace:\n tcp_data_ready+0xf8/0x370\n [..]"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: borrar el indicador 'kern' de los sockets de reserva La extensi\u00f3n mptcp ULP depende de que sk->sk_sock_kern est\u00e9 configurado correctamente: impide que setsockopt(fd, IPPROTO_TCP, TCP_ULP, \"mptcp\", 6); de funcionar para sockets tcp simples (cualquier socket expuesto al espacio de usuario). Pero en caso de respaldo, aceptar() puede devolver un sk tcp simple. En tal caso, sk todav\u00eda est\u00e1 etiquetado como 'kernel' y setsockopt funcionar\u00e1. Esto bloquear\u00e1 el kernel. La extensi\u00f3n de subflujo tiene un socket NULL ctx->conn mptcp: ERROR: KASAN: null-ptr-deref en subflow_data_ready+0x181/0x2b0 Seguimiento de llamadas: tcp_data_ready+0xf8/0x370 [..]"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47594",
|
"id": "CVE-2021-47594",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:53.983",
|
"published": "2024-06-19T15:15:53.983",
|
||||||
"lastModified": "2024-06-19T15:15:53.983",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: never allow the PM to close a listener subflow\n\nCurrently, when deleting an endpoint the netlink PM treverses\nall the local MPTCP sockets, regardless of their status.\n\nIf an MPTCP listener socket is bound to the IP matching the\ndelete endpoint, the listener TCP socket will be closed.\nThat is unexpected, the PM should only affect data subflows.\n\nAdditionally, syzbot was able to trigger a NULL ptr dereference\ndue to the above:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nCPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897\nCode: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff\nRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016\nRAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000\nR13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001\nFS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0\nCall Trace:\n <TASK>\n lock_acquire kernel/locking/lockdep.c:5637 [inline]\n lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162\n finish_wait+0xc0/0x270 kernel/sched/wait.c:400\n inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]\n inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497\n mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865\n inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739\n mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345\n do_accept+0x382/0x510 net/socket.c:1773\n __sys_accept4_file+0x7e/0xe0 net/socket.c:1816\n __sys_accept4+0xb0/0x100 net/socket.c:1846\n __do_sys_accept net/socket.c:1864 [inline]\n __se_sys_accept net/socket.c:1861 [inline]\n __x64_sys_accept+0x71/0xb0 net/socket.c:1861\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f177cd8b8e9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 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\nRSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c\nR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000\n </TASK>\n\nFix the issue explicitly skipping MPTCP socket in TCP_LISTEN\nstatus."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: never allow the PM to close a listener subflow\n\nCurrently, when deleting an endpoint the netlink PM treverses\nall the local MPTCP sockets, regardless of their status.\n\nIf an MPTCP listener socket is bound to the IP matching the\ndelete endpoint, the listener TCP socket will be closed.\nThat is unexpected, the PM should only affect data subflows.\n\nAdditionally, syzbot was able to trigger a NULL ptr dereference\ndue to the above:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nCPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897\nCode: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff\nRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016\nRAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000\nR13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001\nFS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0\nCall Trace:\n <TASK>\n lock_acquire kernel/locking/lockdep.c:5637 [inline]\n lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162\n finish_wait+0xc0/0x270 kernel/sched/wait.c:400\n inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]\n inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497\n mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865\n inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739\n mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345\n do_accept+0x382/0x510 net/socket.c:1773\n __sys_accept4_file+0x7e/0xe0 net/socket.c:1816\n __sys_accept4+0xb0/0x100 net/socket.c:1846\n __do_sys_accept net/socket.c:1864 [inline]\n __se_sys_accept net/socket.c:1861 [inline]\n __x64_sys_accept+0x71/0xb0 net/socket.c:1861\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f177cd8b8e9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 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\nRSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c\nR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000\n </TASK>\n\nFix the issue explicitly skipping MPTCP socket in TCP_LISTEN\nstatus."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: nunca permitir que el PM cierre un subflujo de escucha Actualmente, al eliminar un endpoint, el PM de netlink atraviesa todos los sockets MPTCP locales, independientemente de su estado. Si un socket de escucha MPTCP est\u00e1 vinculado a la IP que coincide con el endpoint de eliminaci\u00f3n, el socket TCP de escucha se cerrar\u00e1. Esto es inesperado, el PM solo deber\u00eda afectar los subflujos de datos. Adem\u00e1s, syzbot pudo activar una desreferencia de ptr NULL debido a lo anterior: falla de protecci\u00f3n general, probablemente para la direcci\u00f3n no can\u00f3nica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000018-0x0000000000000001f] CPU: 1 PID: 6550 Comm: syz-executor122 No contaminado 5.16.0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897 C\u00f3digo: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016 RAX: 00 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000000 a R12: 0000000000000000 R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0 Seguimiento de llamadas: lock_acquire kernel/locking/lockdep.c:5637 [en l\u00ednea] +0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en l\u00ednea] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 Finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [en l\u00ednea] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket. c:1864 [en l\u00ednea] __se_sys_accept net/socket.c:1861 [en l\u00ednea] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x35/0xb0 arch /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f177cd8b8e9 C\u00f3digo: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 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:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX : ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f177 ce13400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c R13: cde1004 R14: 6d705f706374706d R15: 0000000000022000 Arreglar el problema al omitir expl\u00edcitamente el socket MPTCP en el estado TCP_LISTEN."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47595",
|
"id": "CVE-2021-47595",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.097",
|
"published": "2024-06-19T15:15:54.097",
|
||||||
"lastModified": "2024-06-19T15:15:54.097",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_ets: don't remove idle classes from the round-robin list\n\nShuang reported that the following script:\n\n 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7\n 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp &\n 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3\n\ncrashes systematically when line 2) is commented:\n\n list_del corruption, ffff8e028404bd30->next is LIST_POISON1 (dead000000000100)\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:47!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478\n Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014\n RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47\n Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe\n RSP: 0018:ffffae46807a3888 EFLAGS: 00010246\n RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202\n RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff\n RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff\n R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800\n R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400\n FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0\n Call Trace:\n <TASK>\n ets_qdisc_change+0x58b/0xa70 [sch_ets]\n tc_modify_qdisc+0x323/0x880\n rtnetlink_rcv_msg+0x169/0x4a0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x1a5/0x280\n netlink_sendmsg+0x257/0x4d0\n sock_sendmsg+0x5b/0x60\n ____sys_sendmsg+0x1f2/0x260\n ___sys_sendmsg+0x7c/0xc0\n __sys_sendmsg+0x57/0xa0\n do_syscall_64+0x3a/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7efdc8031338\n Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55\n RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338\n RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940\n R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001\n R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets]\n ---[ end trace f35878d1912655c2 ]---\n RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47\n Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe\n RSP: 0018:ffffae46807a3888 EFLAGS: 00010246\n RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202\n RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff\n RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff\n R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800\n R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400\n FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000\n---truncated---"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_ets: don't remove idle classes from the round-robin list\n\nShuang reported that the following script:\n\n 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7\n 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp &\n 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3\n\ncrashes systematically when line 2) is commented:\n\n list_del corruption, ffff8e028404bd30->next is LIST_POISON1 (dead000000000100)\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:47!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478\n Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014\n RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47\n Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe\n RSP: 0018:ffffae46807a3888 EFLAGS: 00010246\n RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202\n RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff\n RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff\n R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800\n R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400\n FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0\n Call Trace:\n <TASK>\n ets_qdisc_change+0x58b/0xa70 [sch_ets]\n tc_modify_qdisc+0x323/0x880\n rtnetlink_rcv_msg+0x169/0x4a0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x1a5/0x280\n netlink_sendmsg+0x257/0x4d0\n sock_sendmsg+0x5b/0x60\n ____sys_sendmsg+0x1f2/0x260\n ___sys_sendmsg+0x7c/0xc0\n __sys_sendmsg+0x57/0xa0\n do_syscall_64+0x3a/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7efdc8031338\n Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55\n RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338\n RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940\n R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001\n R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets]\n ---[ end trace f35878d1912655c2 ]---\n RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47\n Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe\n RSP: 0018:ffffae46807a3888 EFLAGS: 00010246\n RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202\n RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff\n RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff\n R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800\n R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400\n FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000\n---truncated---"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net/sched: sch_ets: no elimine las clases inactivas de la lista de turnos Shuang inform\u00f3 que el siguiente script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bandas 8 estricto 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a propio -b 00:c1:a0: c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 estricto 2 cuantos 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 falla sistem\u00e1ticamente cuando la l\u00ednea 2) se comenta: corrupci\u00f3n list_del, ffff8e028404bd30->el siguiente es LIST_POISON1 (dead000000000100) ------------[ cortar aqu\u00ed ]------------ ERROR del kernel en lib/list_debug. c:47! c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comunicaciones: tc Not tainted 5.16.0-rc4+ #478 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066 +0f1aadab 01/04/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 C\u00f3digo: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 4 8 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 246 RAX: 000000000000004eRBX : 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 00000000000 00000 R09: c0000000ffff7fff R10: 00000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 000000000035 0ef0 Seguimiento de llamadas: ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/ 0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7efdc8031338 C\u00f3digo: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: de RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 00000000000000246 R12: 0000000000000001 R 13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 M\u00f3dulos vinculados en: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common pcs pkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [\u00faltima descarga: sch_ets] ---[ fin de seguimiento f35878d191 2655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 C\u00f3digo: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX 000 0000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: FFFFFAE46807A36A8 R12: FFFFF8E028404B800 R13: FFFF8E028404BD30 R14: Dead000000000100 R15: FFFFF8E02FAFA2400 FUT: GS: FFFF8E02FB600000 (0000) KNLGS: 000000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 - --truncado---"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47596",
|
"id": "CVE-2021-47596",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.197",
|
"published": "2024-06-19T15:15:54.197",
|
||||||
"lastModified": "2024-06-19T15:15:54.197",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix use-after-free bug in hclgevf_send_mbx_msg\n\nCurrently, the hns3_remove function firstly uninstall client instance,\nand then uninstall acceletion engine device. The netdevice is freed in\nclient instance uninstall process, but acceletion engine device uninstall\nprocess still use it to trace runtime information. This causes a use after\nfree problem.\n\nSo fixes it by check the instance register state to avoid use after free."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix use-after-free bug in hclgevf_send_mbx_msg\n\nCurrently, the hns3_remove function firstly uninstall client instance,\nand then uninstall acceletion engine device. The netdevice is freed in\nclient instance uninstall process, but acceletion engine device uninstall\nprocess still use it to trace runtime information. This causes a use after\nfree problem.\n\nSo fixes it by check the instance register state to avoid use after free."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: hns3: corrige el error de use-after-free en hclgevf_send_mbx_msg Actualmente, la funci\u00f3n hns3_remove desinstala primero la instancia del cliente y luego desinstala el dispositivo del motor de aceleraci\u00f3n. El dispositivo de red se libera en el proceso de desinstalaci\u00f3n de la instancia del cliente, pero el proceso de desinstalaci\u00f3n del dispositivo del motor de aceleraci\u00f3n a\u00fan lo utiliza para rastrear la informaci\u00f3n del tiempo de ejecuci\u00f3n. Esto provoca un problema de use-after-free. Entonces lo soluciona verificando el estado del registro de la instancia para evitar use after free."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47597",
|
"id": "CVE-2021-47597",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.290",
|
"published": "2024-06-19T15:15:54.290",
|
||||||
"lastModified": "2024-06-19T15:15:54.290",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet_diag: fix kernel-infoleak for UDP sockets\n\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\n\nAfter analysis it turned out UDP was not initializing\nr->idiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x63f/0xe30 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBytes 68-71 of 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\n\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet_diag: fix kernel-infoleak for UDP sockets\n\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\n\nAfter analysis it turned out UDP was not initializing\nr->idiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x63f/0xe30 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBytes 68-71 of 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\n\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: inet_diag: corrige la fuga de informaci\u00f3n del kernel para sockets UDP KMSAN inform\u00f3 una fuga de informaci\u00f3n del kernel [1], que puede ser explotada por usuarios sin privilegios. Despu\u00e9s del an\u00e1lisis result\u00f3 que UDP no estaba inicializando r->idiag_expires. Otros usuarios de inet_sk_diag_fill() podr\u00edan cometer el mismo error en el futuro, as\u00ed que solucione este problema en inet_sk_diag_fill(). [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:121 [en l\u00ednea] ERROR: KMSAN: kernel-infoleak en copia lib/iov_iter.c:156 [en l\u00ednea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [en l\u00ednea] copia lib/iov_iter.c:156 [en l\u00ednea] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [en l\u00ednea] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram .c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [en l\u00ednea] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [en l\u00ednea] sock_recvmsg net/socket.c:962 [en l\u00ednea] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [en l\u00ednea] new_sync_read fs/read_write.c:400 [en l\u00ednea] vfs_read+0x1631/0x1980 fs/read_write.c: 481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [en l\u00ednea] __se_sys_read fs/read_write.c:627 [en l\u00ednea] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 _arco x64/ x86/entry/common.c:51 [en l\u00ednea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit se cre\u00f3 en: slab_post_alloc_hook mm/slab.h:524 [en l\u00ednea] slab_alloc_node mm/slub.c:3251 [en l\u00ednea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en l\u00ednea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en l\u00ednea] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [en l\u00ednea] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c: 1319 [en l\u00ednea] netlink_unicast+0x1095/0x1360 netLink/af_netlink.c: 1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_etlink.c: 1916 sockm. C: 704 [ en l\u00ednea] sock_sendmsg net/socket.c:724 [en l\u00ednea] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:9 24 [en l\u00ednea] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [en l\u00ednea] __se_sys_writev fs/read_write.c:1037 [en l\u00ednea] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 _syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Los bytes 68-71 de 312 no est\u00e1n inicializados El acceso a la memoria de tama\u00f1o 312 comienza en ffff88812ab54000 Datos copiados a la direcci\u00f3n de usuario 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47598",
|
"id": "CVE-2021-47598",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.383",
|
"published": "2024-06-19T15:15:54.383",
|
||||||
"lastModified": "2024-06-19T15:15:54.383",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_cake: do not call cake_destroy() from cake_init()\n\nqdiscs are not supposed to call their own destroy() method\nfrom init(), because core stack already does that.\n\nsyzbot was able to trigger use after free:\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]\nWARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740\nModules linked in:\nCPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]\nRIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740\nCode: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8\nRSP: 0018:ffffc9000627f290 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44\nRBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000\nFS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0\nCall Trace:\n <TASK>\n tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810\n tcf_block_put_ext net/sched/cls_api.c:1381 [inline]\n tcf_block_put_ext net/sched/cls_api.c:1376 [inline]\n tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394\n cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695\n qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293\n tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660\n rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571\n netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f1bb06badb9\nCode: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.\nRSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9\nRDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003\nR10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688\nR13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2\n </TASK>"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_cake: do not call cake_destroy() from cake_init()\n\nqdiscs are not supposed to call their own destroy() method\nfrom init(), because core stack already does that.\n\nsyzbot was able to trigger use after free:\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]\nWARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740\nModules linked in:\nCPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]\nRIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740\nCode: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8\nRSP: 0018:ffffc9000627f290 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44\nRBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000\nFS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0\nCall Trace:\n <TASK>\n tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810\n tcf_block_put_ext net/sched/cls_api.c:1381 [inline]\n tcf_block_put_ext net/sched/cls_api.c:1376 [inline]\n tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394\n cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695\n qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293\n tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660\n rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571\n netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f1bb06badb9\nCode: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.\nRSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9\nRDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003\nR10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688\nR13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2\n </TASK>"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_cake: no llamar a cake_destroy() desde cake_init() Se supone que las qdiscs no deben llamar a su propio m\u00e9todo destroy() desde init(), porque la pila central ya lo hace. syzbot pudo activar el use-after-free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [en l\u00ednea] ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 M\u00f3dulos vinculados en: CPU: 0 PID: 21902 Comm: syz-executor189 No contaminado 5.16 .0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [en l\u00ednea] RIP: 0010:__mutex_lock+ 0x9ec/0x12f0 kernel/locking/mutex.c:740 C\u00f3digo: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 00000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 000055556abc400(0000) GS:ffff8880b9c0000 0(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Seguimiento de llamadas: tcf_chain0_head_change_cb_del+0x2e/0 x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [ en l\u00ednea] tcf_block_put_ext net/sched/cls_api.c:1376 [en l\u00ednea] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da /0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/ af_netlink. c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en l\u00ednea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c :704 [en l\u00ednea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b 0 red/toma. c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1bb06badb9 C\u00f3digo: No se puede acceder al c\u00f3digo de operaci\u00f3n bytes en RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000000000003 RCX: 00007f1bb06badb9 RDX: 000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 00000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2 "
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47599",
|
"id": "CVE-2021-47599",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.483",
|
"published": "2024-06-19T15:15:54.483",
|
||||||
"lastModified": "2024-06-19T15:15:54.483",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: use latest_dev in btrfs_show_devname\n\nThe test case btrfs/238 reports the warning below:\n\n WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]\n CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72\n Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n btrfs_show_devname+0x108/0x1b4 [btrfs]\n show_mountinfo+0x234/0x2c4\n m_show+0x28/0x34\n seq_read_iter+0x12c/0x3c4\n vfs_read+0x29c/0x2c8\n ksys_read+0x80/0xec\n __arm64_sys_read+0x28/0x34\n invoke_syscall+0x50/0xf8\n do_el0_svc+0x88/0x138\n el0_svc+0x2c/0x8c\n el0t_64_sync_handler+0x84/0xe4\n el0t_64_sync+0x198/0x19c\n\nReason:\nWhile btrfs_prepare_sprout() moves the fs_devices::devices into\nfs_devices::seed_list, the btrfs_show_devname() searches for the devices\nand found none, leading to the warning as in above.\n\nFix:\nlatest_dev is updated according to the changes to the device list.\nThat means we could use the latest_dev->name to show the device name in\n/proc/self/mounts, the pointer will be always valid as it's assigned\nbefore the device is deleted from the list in remove or replace.\nThe RCU protection is sufficient as the device structure is freed after\nsynchronization."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: use latest_dev in btrfs_show_devname\n\nThe test case btrfs/238 reports the warning below:\n\n WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]\n CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72\n Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n btrfs_show_devname+0x108/0x1b4 [btrfs]\n show_mountinfo+0x234/0x2c4\n m_show+0x28/0x34\n seq_read_iter+0x12c/0x3c4\n vfs_read+0x29c/0x2c8\n ksys_read+0x80/0xec\n __arm64_sys_read+0x28/0x34\n invoke_syscall+0x50/0xf8\n do_el0_svc+0x88/0x138\n el0_svc+0x2c/0x8c\n el0t_64_sync_handler+0x84/0xe4\n el0t_64_sync+0x198/0x19c\n\nReason:\nWhile btrfs_prepare_sprout() moves the fs_devices::devices into\nfs_devices::seed_list, the btrfs_show_devname() searches for the devices\nand found none, leading to the warning as in above.\n\nFix:\nlatest_dev is updated according to the changes to the device list.\nThat means we could use the latest_dev->name to show the device name in\n/proc/self/mounts, the pointer will be always valid as it's assigned\nbefore the device is deleted from the list in remove or replace.\nThe RCU protection is sufficient as the device structure is freed after\nsynchronization."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: utilice Latest_dev en btrfs_show_devname El caso de prueba btrfs/238 informa la siguiente advertencia: ADVERTENCIA: CPU: 3 PID: 481 en fs/btrfs/super.c:2509 btrfs_show_devname+0x104 /0x1e8 [btrfs] CPU: 2 PID: 1 Comunicaci\u00f3n: systemd Contaminado: GWO 5.14.0-rc1-custom #72 Nombre de hardware: QEMU M\u00e1quina virtual QEMU, BIOS 0.0.0 06/02/2015 Rastreo de llamadas: btrfs_show_devname+0x108/ 0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler +0x84/0xe4 el0t_64_sync+0x198/0x19c Motivo: mientras btrfs_prepare_sprout() mueve fs_devices::devices a fs_devices::seed_list, btrfs_show_devname() busca los dispositivos y no encuentra ninguno, lo que genera la advertencia como se muestra arriba. Soluci\u00f3n: last_dev se actualiza seg\u00fan los cambios en la lista de dispositivos. Eso significa que podr\u00edamos usar el \u00faltimo_dev->name para mostrar el nombre del dispositivo en /proc/self/mounts, el puntero siempre ser\u00e1 v\u00e1lido tal como est\u00e1 asignado antes de que el dispositivo se elimine de la lista en eliminar o reemplazar. La protecci\u00f3n de la RCU es suficiente, ya que la estructura del dispositivo se libera despu\u00e9s de la sincronizaci\u00f3n."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47600",
|
"id": "CVE-2021-47600",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.567",
|
"published": "2024-06-19T15:15:54.567",
|
||||||
"lastModified": "2024-06-19T15:15:54.567",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm btree remove: fix use after free in rebalance_children()\n\nMove dm_tm_unlock() after dm_tm_dec()."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm btree remove: fix use after free in rebalance_children()\n\nMove dm_tm_unlock() after dm_tm_dec()."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm btree remove: corrige el use after free en rebalance_children() Mueve dm_tm_unlock() despu\u00e9s de dm_tm_dec()."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47601",
|
"id": "CVE-2021-47601",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.670",
|
"published": "2024-06-19T15:15:54.670",
|
||||||
"lastModified": "2024-06-19T15:15:54.670",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntee: amdtee: fix an IS_ERR() vs NULL bug\n\nThe __get_free_pages() function does not return error pointers it returns\nNULL so fix this condition to avoid a NULL dereference."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntee: amdtee: fix an IS_ERR() vs NULL bug\n\nThe __get_free_pages() function does not return error pointers it returns\nNULL so fix this condition to avoid a NULL dereference."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tee: amdtee: corrige un error IS_ERR() vs NULL La funci\u00f3n __get_free_pages() no devuelve punteros de error, devuelve NULL, as\u00ed que corrija esta condici\u00f3n para evitar una desreferencia a NULL."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47602",
|
"id": "CVE-2021-47602",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.760",
|
"published": "2024-06-19T15:15:54.760",
|
||||||
"lastModified": "2024-06-19T15:15:54.760",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: track only QoS data frames for admission control\n\nFor admission control, obviously all of that only works for\nQoS data frames, otherwise we cannot even access the QoS\nfield in the header.\n\nSyzbot reported (see below) an uninitialized value here due\nto a status of a non-QoS nullfunc packet, which isn't even\nlong enough to contain the QoS header.\n\nFix this to only do anything for QoS data packets."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: track only QoS data frames for admission control\n\nFor admission control, obviously all of that only works for\nQoS data frames, otherwise we cannot even access the QoS\nfield in the header.\n\nSyzbot reported (see below) an uninitialized value here due\nto a status of a non-QoS nullfunc packet, which isn't even\nlong enough to contain the QoS header.\n\nFix this to only do anything for QoS data packets."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mac80211: rastrea solo frameworks de datos QoS para control de admisi\u00f3n. Para el control de admisi\u00f3n, obviamente todo eso solo funciona para frameworks de datos QoS; de lo contrario, ni siquiera podemos acceder al campo QoS en el encabezado. Syzbot inform\u00f3 (ver m\u00e1s abajo) un valor no inicializado aqu\u00ed debido al estado de un paquete nullfunc sin QoS, que ni siquiera es lo suficientemente largo para contener el encabezado de QoS. Solucione este problema para hacer algo \u00fanicamente con los paquetes de datos QoS."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47603",
|
"id": "CVE-2021-47603",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.863",
|
"published": "2024-06-19T15:15:54.863",
|
||||||
"lastModified": "2024-06-19T15:15:54.863",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\naudit: improve robustness of the audit queue handling\n\nIf the audit daemon were ever to get stuck in a stopped state the\nkernel's kauditd_thread() could get blocked attempting to send audit\nrecords to the userspace audit daemon. With the kernel thread\nblocked it is possible that the audit queue could grow unbounded as\ncertain audit record generating events must be exempt from the queue\nlimits else the system enter a deadlock state.\n\nThis patch resolves this problem by lowering the kernel thread's\nsocket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks\nthe kauditd_send_queue() function to better manage the various audit\nqueues when connection problems occur between the kernel and the\naudit daemon. With this patch, the backlog may temporarily grow\nbeyond the defined limits when the audit daemon is stopped and the\nsystem is under heavy audit pressure, but kauditd_thread() will\ncontinue to make progress and drain the queues as it would for other\nconnection problems. For example, with the audit daemon put into a\nstopped state and the system configured to audit every syscall it\nwas still possible to shutdown the system without a kernel panic,\ndeadlock, etc.; granted, the system was slow to shutdown but that is\nto be expected given the extreme pressure of recording every syscall.\n\nThe timeout value of HZ/10 was chosen primarily through\nexperimentation and this developer's \"gut feeling\". There is likely\nno one perfect value, but as this scenario is limited in scope (root\nprivileges would be needed to send SIGSTOP to the audit daemon), it\nis likely not worth exposing this as a tunable at present. This can\nalways be done at a later date if it proves necessary."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\naudit: improve robustness of the audit queue handling\n\nIf the audit daemon were ever to get stuck in a stopped state the\nkernel's kauditd_thread() could get blocked attempting to send audit\nrecords to the userspace audit daemon. With the kernel thread\nblocked it is possible that the audit queue could grow unbounded as\ncertain audit record generating events must be exempt from the queue\nlimits else the system enter a deadlock state.\n\nThis patch resolves this problem by lowering the kernel thread's\nsocket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks\nthe kauditd_send_queue() function to better manage the various audit\nqueues when connection problems occur between the kernel and the\naudit daemon. With this patch, the backlog may temporarily grow\nbeyond the defined limits when the audit daemon is stopped and the\nsystem is under heavy audit pressure, but kauditd_thread() will\ncontinue to make progress and drain the queues as it would for other\nconnection problems. For example, with the audit daemon put into a\nstopped state and the system configured to audit every syscall it\nwas still possible to shutdown the system without a kernel panic,\ndeadlock, etc.; granted, the system was slow to shutdown but that is\nto be expected given the extreme pressure of recording every syscall.\n\nThe timeout value of HZ/10 was chosen primarily through\nexperimentation and this developer's \"gut feeling\". There is likely\nno one perfect value, but as this scenario is limited in scope (root\nprivileges would be needed to send SIGSTOP to the audit daemon), it\nis likely not worth exposing this as a tunable at present. This can\nalways be done at a later date if it proves necessary."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditor\u00eda: mejora la solidez del manejo de la cola de auditor\u00eda. Si el daemon de auditor\u00eda alguna vez se atascara en un estado detenido, kauditd_thread() del kernel podr\u00eda bloquearse al intentar enviar registros de auditor\u00eda al espacio de usuario. daemon de auditor\u00eda. Con el subproceso del n\u00facleo bloqueado, es posible que la cola de auditor\u00eda crezca sin l\u00edmites, ya que ciertos eventos que generan registros de auditor\u00eda deben estar exentos de los l\u00edmites de la cola, de lo contrario, el sistema entrar\u00e1 en un estado de bloqueo. Este parche resuelve este problema reduciendo el tiempo de espera de env\u00edo del socket del subproceso del n\u00facleo de MAX_SCHEDULE_TIMEOUT a HZ/10 y modifica la funci\u00f3n kauditd_send_queue() para gestionar mejor las distintas colas de auditor\u00eda cuando se producen problemas de conexi\u00f3n entre el n\u00facleo y el daemon de auditor\u00eda. Con este parche, el trabajo pendiente puede crecer temporalmente m\u00e1s all\u00e1 de los l\u00edmites definidos cuando se detiene el daemon de auditor\u00eda y el sistema est\u00e1 bajo una fuerte presi\u00f3n de auditor\u00eda, pero kauditd_thread() continuar\u00e1 progresando y drenando las colas como lo har\u00eda con otros problemas de conexi\u00f3n. Por ejemplo, con el daemon de auditor\u00eda en estado detenido y el sistema configurado para auditar cada llamada al sistema, a\u00fan era posible apagar el sistema sin p\u00e1nico en el kernel, interbloqueo, etc.; Por supuesto, el sistema tard\u00f3 en cerrarse, pero eso es de esperarse dada la presi\u00f3n extrema de registrar cada llamada al sistema. El valor de tiempo de espera de HZ/10 se eligi\u00f3 principalmente a trav\u00e9s de la experimentaci\u00f3n y el \"instinto\" de este desarrollador. Probablemente no exista un valor perfecto, pero como este escenario tiene un alcance limitado (se necesitar\u00edan privilegios de root para enviar SIGSTOP al daemon de auditor\u00eda), probablemente no valga la pena exponerlo como un ajuste ajustable en este momento. Esto siempre se puede hacer en una fecha posterior si resulta necesario."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47604",
|
"id": "CVE-2021-47604",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:54.973",
|
"published": "2024-06-19T15:15:54.973",
|
||||||
"lastModified": "2024-06-19T15:15:54.973",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: check that offset is within bounds in get_config()\n\nThis condition checks \"len\" but it does not check \"offset\" and that\ncould result in an out of bounds read if \"offset > dev->config_size\".\nThe problem is that since both variables are unsigned the\n\"dev->config_size - offset\" subtraction would result in a very high\nunsigned value.\n\nI think these checks might not be necessary because \"len\" and \"offset\"\nare supposed to already have been validated using the\nvhost_vdpa_config_validate() function. But I do not know the code\nperfectly, and I like to be safe."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: check that offset is within bounds in get_config()\n\nThis condition checks \"len\" but it does not check \"offset\" and that\ncould result in an out of bounds read if \"offset > dev->config_size\".\nThe problem is that since both variables are unsigned the\n\"dev->config_size - offset\" subtraction would result in a very high\nunsigned value.\n\nI think these checks might not be necessary because \"len\" and \"offset\"\nare supposed to already have been validated using the\nvhost_vdpa_config_validate() function. But I do not know the code\nperfectly, and I like to be safe."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vduse: verifique que el desplazamiento est\u00e9 dentro de los l\u00edmites en get_config() Esta condici\u00f3n verifica \"len\" pero no verifica \"desplazamiento\" y eso podr\u00eda resultar en una lectura fuera de los l\u00edmites si \" desplazamiento > dev->config_size\". El problema es que, dado que ambas variables no est\u00e1n firmadas, la resta \"dev->config_size - offset\" dar\u00eda como resultado un valor sin firmar muy alto. Creo que estas comprobaciones podr\u00edan no ser necesarias porque se supone que \"len\" y \"offset\" ya se han validado mediante la funci\u00f3n vhost_vdpa_config_validate(). Pero no conozco el c\u00f3digo a la perfecci\u00f3n y me gusta estar seguro."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47605",
|
"id": "CVE-2021-47605",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.067",
|
"published": "2024-06-19T15:15:55.067",
|
||||||
"lastModified": "2024-06-19T15:15:55.067",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: fix memory corruption in vduse_dev_ioctl()\n\nThe \"config.offset\" comes from the user. There needs to a check to\nprevent it being out of bounds. The \"config.offset\" and\n\"dev->config_size\" variables are both type u32. So if the offset if\nout of bounds then the \"dev->config_size - config.offset\" subtraction\nresults in a very high u32 value. The out of bounds offset can result\nin memory corruption."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: fix memory corruption in vduse_dev_ioctl()\n\nThe \"config.offset\" comes from the user. There needs to a check to\nprevent it being out of bounds. The \"config.offset\" and\n\"dev->config_size\" variables are both type u32. So if the offset if\nout of bounds then the \"dev->config_size - config.offset\" subtraction\nresults in a very high u32 value. The out of bounds offset can result\nin memory corruption."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vduse: corrige corrupci\u00f3n de memoria en vduse_dev_ioctl() El \"config.offset\" proviene del usuario. Es necesario realizar un control para evitar que est\u00e9 fuera de los l\u00edmites. Las variables \"config.offset\" y \"dev->config_size\" son ambas del tipo u32. Entonces, si el desplazamiento est\u00e1 fuera de los l\u00edmites, entonces la resta \"dev->config_size - config.offset\" da como resultado un valor u32 muy alto. El desplazamiento fuera de los l\u00edmites puede provocar da\u00f1os en la memoria."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47606",
|
"id": "CVE-2021-47606",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.153",
|
"published": "2024-06-19T15:15:55.153",
|
||||||
"lastModified": "2024-06-19T15:15:55.153",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: netlink: af_netlink: Prevent empty skb by adding a check on len.\n\nAdding a check on len parameter to avoid empty skb. This prevents a\ndivision error in netem_enqueue function which is caused when skb->len=0\nand skb->data_len=0 in the randomized corruption step as shown below.\n\nskb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);\n\nCrash Report:\n[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family\n0 port 6081 - 0\n[ 343.216110] netem: version 1.3\n[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\n[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+\n[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS 1.11.0-2.el7 04/01/2014\n[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]\n[ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff\nff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f\n74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03\n[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246\n[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:\n0000000000000000\n[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:\nffff88800f8eda40\n[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:\nffffffff94fb8445\n[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:\n0000000000000000\n[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:\n0000000000000020\n[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)\nknlGS:0000000000000000\n[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:\n00000000000006e0\n[ 343.250076] Call Trace:\n[ 343.250423] <TASK>\n[ 343.250713] ? memcpy+0x4d/0x60\n[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem]\n[ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem]\n[ 343.253102] ? stack_trace_save+0x87/0xb0\n[ 343.253655] ? filter_irq_stacks+0xb0/0xb0\n[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem]\n[ 343.254837] ? __kasan_check_write+0x14/0x20\n[ 343.255418] ? _raw_spin_lock+0x88/0xd6\n[ 343.255953] dev_qdisc_enqueue+0x50/0x180\n[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090\n[ 343.257083] ? netdev_core_pick_tx+0x300/0x300\n[ 343.257690] ? check_kcov_mode+0x10/0x40\n[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40\n[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30\n[ 343.259529] ? setup_object.isra.71+0x23/0x90\n[ 343.260121] ? new_slab+0x26e/0x4b0\n[ 343.260609] ? kasan_poison+0x3a/0x50\n[ 343.261118] ? kasan_unpoison+0x28/0x50\n[ 343.261637] ? __kasan_slab_alloc+0x71/0x90\n[ 343.262214] ? memcpy+0x4d/0x60\n[ 343.262674] ? write_comp_data+0x2f/0x90\n[ 343.263209] ? __kasan_check_write+0x14/0x20\n[ 343.263802] ? __skb_clone+0x5d6/0x840\n[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.264958] dev_queue_xmit+0x1c/0x20\n[ 343.265470] netlink_deliver_tap+0x652/0x9c0\n[ 343.266067] netlink_unicast+0x5a0/0x7f0\n[ 343.266608] ? netlink_attachskb+0x860/0x860\n[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.267820] ? write_comp_data+0x2f/0x90\n[ 343.268367] netlink_sendmsg+0x922/0xe80\n[ 343.268899] ? netlink_unicast+0x7f0/0x7f0\n[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.270099] ? write_comp_data+0x2f/0x90\n[ 343.270644] ? netlink_unicast+0x7f0/0x7f0\n[ 343.271210] sock_sendmsg+0x155/0x190\n[ 343.271721] ____sys_sendmsg+0x75f/0x8f0\n[ 343.272262] ? kernel_sendmsg+0x60/0x60\n[ 343.272788] ? write_comp_data+0x2f/0x90\n[ 343.273332] ? write_comp_data+0x2f/0x90\n[ 343.273869] ___sys_sendmsg+0x10f/0x190\n[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80\n[ 343.274984] ? slab_post_alloc_hook+0x70/0x230\n[ 343.275597] ? futex_wait_setup+0x240/0x240\n[ 343.276175] ? security_file_alloc+0x3e/0x170\n[ 343.276779] ? write_comp_d\n---truncated---"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: netlink: af_netlink: Prevent empty skb by adding a check on len.\n\nAdding a check on len parameter to avoid empty skb. This prevents a\ndivision error in netem_enqueue function which is caused when skb->len=0\nand skb->data_len=0 in the randomized corruption step as shown below.\n\nskb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);\n\nCrash Report:\n[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family\n0 port 6081 - 0\n[ 343.216110] netem: version 1.3\n[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\n[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+\n[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS 1.11.0-2.el7 04/01/2014\n[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]\n[ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff\nff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f\n74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03\n[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246\n[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:\n0000000000000000\n[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:\nffff88800f8eda40\n[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:\nffffffff94fb8445\n[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:\n0000000000000000\n[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:\n0000000000000020\n[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)\nknlGS:0000000000000000\n[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:\n00000000000006e0\n[ 343.250076] Call Trace:\n[ 343.250423] <TASK>\n[ 343.250713] ? memcpy+0x4d/0x60\n[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem]\n[ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem]\n[ 343.253102] ? stack_trace_save+0x87/0xb0\n[ 343.253655] ? filter_irq_stacks+0xb0/0xb0\n[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem]\n[ 343.254837] ? __kasan_check_write+0x14/0x20\n[ 343.255418] ? _raw_spin_lock+0x88/0xd6\n[ 343.255953] dev_qdisc_enqueue+0x50/0x180\n[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090\n[ 343.257083] ? netdev_core_pick_tx+0x300/0x300\n[ 343.257690] ? check_kcov_mode+0x10/0x40\n[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40\n[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30\n[ 343.259529] ? setup_object.isra.71+0x23/0x90\n[ 343.260121] ? new_slab+0x26e/0x4b0\n[ 343.260609] ? kasan_poison+0x3a/0x50\n[ 343.261118] ? kasan_unpoison+0x28/0x50\n[ 343.261637] ? __kasan_slab_alloc+0x71/0x90\n[ 343.262214] ? memcpy+0x4d/0x60\n[ 343.262674] ? write_comp_data+0x2f/0x90\n[ 343.263209] ? __kasan_check_write+0x14/0x20\n[ 343.263802] ? __skb_clone+0x5d6/0x840\n[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.264958] dev_queue_xmit+0x1c/0x20\n[ 343.265470] netlink_deliver_tap+0x652/0x9c0\n[ 343.266067] netlink_unicast+0x5a0/0x7f0\n[ 343.266608] ? netlink_attachskb+0x860/0x860\n[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.267820] ? write_comp_data+0x2f/0x90\n[ 343.268367] netlink_sendmsg+0x922/0xe80\n[ 343.268899] ? netlink_unicast+0x7f0/0x7f0\n[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60\n[ 343.270099] ? write_comp_data+0x2f/0x90\n[ 343.270644] ? netlink_unicast+0x7f0/0x7f0\n[ 343.271210] sock_sendmsg+0x155/0x190\n[ 343.271721] ____sys_sendmsg+0x75f/0x8f0\n[ 343.272262] ? kernel_sendmsg+0x60/0x60\n[ 343.272788] ? write_comp_data+0x2f/0x90\n[ 343.273332] ? write_comp_data+0x2f/0x90\n[ 343.273869] ___sys_sendmsg+0x10f/0x190\n[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80\n[ 343.274984] ? slab_post_alloc_hook+0x70/0x230\n[ 343.275597] ? futex_wait_setup+0x240/0x240\n[ 343.276175] ? security_file_alloc+0x3e/0x170\n[ 343.276779] ? write_comp_d\n---truncated---"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netlink: af_netlink: Evite el skb vac\u00edo agregando una marca en len. Agregar una verificaci\u00f3n en el par\u00e1metro len para evitar skb vac\u00edo. Esto evita un error de divisi\u00f3n en la funci\u00f3n netem_enqueue que se produce cuando skb->len=0 y skb->data_len=0 en el paso de corrupci\u00f3n aleatoria como se muestra a continuaci\u00f3n. skb->datos[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8); Informe de fallo: [343.170349] netdevsim netdevsim0 netdevsim3: establecer [1, 0] tipo 2 familia 0 puerto 6081 - 0 [343.216110] netem: versi\u00f3n 1.3 [343.235841] error de divisi\u00f3n: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 80] CPU : 3 PID: 4288 Comm: reproductor No contaminado 5.16.0-rc1+ [ 343.237569] Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 [ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem] [ 343.239499] C\u00f3digo: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff ff 8b 8d 50 ff ff 8b 85 58 ff ff 4 8 8b bd 70 y sigs. ff ff 31 d2 2b 4f 74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03 [ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 46 [343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX: 0000000000000000 [ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI: ffff88800f8eda40 [ 343.244474] RBP: ff88800bcd7458 R08: 0000000000000000 R09: ffffffff94fb8445 [ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12: 0000000000000000 [ 343. 246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15 : 0000000000000020 [ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000) knlGS:0000000000000000 [ 343.248350] CS: 0010 DS: 000 ES: 0000 CR0: 0000000080050033 [ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4: 00000000000006e0 [ 343.250076] Seguimiento de llamadas: [ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60 [343.251162]? netem_init+0xa0/0xa0 [sch_netem] [ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem] [ 343.253102] ? stack_trace_save+0x87/0xb0 [343.253655]? filter_irq_stacks+0xb0/0xb0 [343.254220]? netem_init+0xa0/0xa0 [sch_netem] [ 343.254837] ? __kasan_check_write+0x14/0x20 [343.255418]? _raw_spin_lock+0x88/0xd6 [ 343.255953] dev_qdisc_enqueue+0x50/0x180 [ 343.256508] __dev_queue_xmit+0x1a7e/0x3090 [ 343.257083] ? netdev_core_pick_tx+0x300/0x300 [343.257690]? check_kcov_mode+0x10/0x40 [343.258219]? _raw_spin_unlock_irqrestore+0x29/0x40 [343.258899]? __kasan_init_slab_obj+0x24/0x30 [343.259529] ? setup_object.isra.71+0x23/0x90 [343.260121]? nueva_losa+0x26e/0x4b0 [ 343.260609] ? kasan_poison+0x3a/0x50 [ 343.261118] ? kasan_unpoison+0x28/0x50 [343.261637]? __kasan_slab_alloc+0x71/0x90 [343.262214]? memcpy+0x4d/0x60 [343.262674]? write_comp_data+0x2f/0x90 [343.263209]? __kasan_check_write+0x14/0x20 [343.263802]? __skb_clone+0x5d6/0x840 [343.264329]? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.264958] dev_queue_xmit+0x1c/0x20 [ 343.265470] netlink_deliver_tap+0x652/0x9c0 [ 343.266067] netlink_unicast+0x5a0/0x7f0 [ 343. 266608] ? netlink_attachskb+0x860/0x860 [343.267183]? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.267820] ? write_comp_data+0x2f/0x90 [343.268367] netlink_sendmsg+0x922/0xe80 [343.268899]? netlink_unicast+0x7f0/0x7f0 [343.269472]? __sanitizer_cov_trace_pc+0x21/0x60 [343.270099] ? write_comp_data+0x2f/0x90 [343.270644]? netlink_unicast+0x7f0/0x7f0 [343.271210] sock_sendmsg+0x155/0x190 [343.271721] ____sys_sendmsg+0x75f/0x8f0 [343.272262] ? kernel_sendmsg+0x60/0x60 [343.272788]? write_comp_data+0x2f/0x90 [343.273332]? write_comp_data+0x2f/0x90 [ 343.273869] ___sys_sendmsg+0x10f/0x190 [ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80 [343.274984]? slab_post_alloc_hook+0x70/0x230 [343.275597]? futex_wait_setup+0x240/0x240 [343.276175]? security_file_alloc+0x3e/0x170 [343.276779]? write_comp_d ---truncado---"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47607",
|
"id": "CVE-2021-47607",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.263",
|
"published": "2024-06-19T15:15:55.263",
|
||||||
"lastModified": "2024-06-19T15:15:55.263",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg\n\nThe implementation of BPF_CMPXCHG on a high level has the following parameters:\n\n .-[old-val] .-[new-val]\n BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG)\n `-[mem-loc] `-[old-val]\n\nGiven a BPF insn can only have two registers (dst, src), the R0 is fixed and\nused as an auxilliary register for input (old value) as well as output (returning\nold value from memory location). While the verifier performs a number of safety\nchecks, it misses to reject unprivileged programs where R0 contains a pointer as\nold value.\n\nThrough brute-forcing it takes about ~16sec on my machine to leak a kernel pointer\nwith BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the\nguessed address into the map slot as a scalar, and using the map value pointer as\nR0 while SRC_REG has a canary value to detect a matching address.\n\nFix it by checking R0 for pointers, and reject if that's the case for unprivileged\nprograms."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg\n\nThe implementation of BPF_CMPXCHG on a high level has the following parameters:\n\n .-[old-val] .-[new-val]\n BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG)\n `-[mem-loc] `-[old-val]\n\nGiven a BPF insn can only have two registers (dst, src), the R0 is fixed and\nused as an auxilliary register for input (old value) as well as output (returning\nold value from memory location). While the verifier performs a number of safety\nchecks, it misses to reject unprivileged programs where R0 contains a pointer as\nold value.\n\nThrough brute-forcing it takes about ~16sec on my machine to leak a kernel pointer\nwith BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the\nguessed address into the map slot as a scalar, and using the map value pointer as\nR0 while SRC_REG has a canary value to detect a matching address.\n\nFix it by checking R0 for pointers, and reject if that's the case for unprivileged\nprograms."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la fuga de direcci\u00f3n del kernel en el registro auxiliar r0 de atomic cmpxchg. La implementaci\u00f3n de BPF_CMPXCHG en un nivel alto tiene los siguientes par\u00e1metros: .-[old-val] .-[new-val ] BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG) `-[mem-loc] `-[old-val] Dado un BPF insn solo puede tener dos registros (dst, src), el R0 es fijo y se utiliza como registro auxiliar para la entrada (valor anterior), as\u00ed como para la salida (devolver el valor anterior desde la ubicaci\u00f3n de la memoria). Si bien el verificador realiza una serie de comprobaciones de seguridad, no rechaza los programas sin privilegios donde R0 contiene un puntero como valor antiguo. A trav\u00e9s de la fuerza bruta, en mi m\u00e1quina se necesitan aproximadamente 16 segundos para filtrar un puntero del kernel con BPF_CMPXCHG. B\u00e1sicamente, PoC busca direcciones del kernel almacenando la direcci\u00f3n adivinada en la ranura del mapa como un escalar y usando el puntero del valor del mapa como R0, mientras que SRC_REG tiene un valor canario para detectar una direcci\u00f3n coincidente. Solucionelo comprobando R0 en busca de punteros y rech\u00e1celo si ese es el caso de los programas sin privilegios."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47608",
|
"id": "CVE-2021-47608",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.360",
|
"published": "2024-06-19T15:15:55.360",
|
||||||
"lastModified": "2024-06-19T15:15:55.360",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kernel address leakage in atomic fetch\n\nThe change in commit 37086bfdc737 (\"bpf: Propagate stack bounds to registers\nin atomics w/ BPF_FETCH\") around check_mem_access() handling is buggy since\nthis would allow for unprivileged users to leak kernel pointers. For example,\nan atomic fetch/and with -1 on a stack destination which holds a spilled\npointer will migrate the spilled register type into a scalar, which can then\nbe exported out of the program (since scalar != pointer) by dumping it into\na map value.\n\nThe original implementation of XADD was preventing this situation by using\na double call to check_mem_access() one with BPF_READ and a subsequent one\nwith BPF_WRITE, in both cases passing -1 as a placeholder value instead of\nregister as per XADD semantics since it didn't contain a value fetch. The\nBPF_READ also included a check in check_stack_read_fixed_off() which rejects\nthe program if the stack slot is of __is_pointer_value() if dst_regno < 0.\nThe latter is to distinguish whether we're dealing with a regular stack spill/\nfill or some arithmetical operation which is disallowed on non-scalars, see\nalso 6e7e63cbb023 (\"bpf: Forbid XADD on spilled pointers for unprivileged\nusers\") for more context on check_mem_access() and its handling of placeholder\nvalue -1.\n\nOne minimally intrusive option to fix the leak is for the BPF_FETCH case to\ninitially check the BPF_READ case via check_mem_access() with -1 as register,\nfollowed by the actual load case with non-negative load_reg to propagate\nstack bounds to registers."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kernel address leakage in atomic fetch\n\nThe change in commit 37086bfdc737 (\"bpf: Propagate stack bounds to registers\nin atomics w/ BPF_FETCH\") around check_mem_access() handling is buggy since\nthis would allow for unprivileged users to leak kernel pointers. For example,\nan atomic fetch/and with -1 on a stack destination which holds a spilled\npointer will migrate the spilled register type into a scalar, which can then\nbe exported out of the program (since scalar != pointer) by dumping it into\na map value.\n\nThe original implementation of XADD was preventing this situation by using\na double call to check_mem_access() one with BPF_READ and a subsequent one\nwith BPF_WRITE, in both cases passing -1 as a placeholder value instead of\nregister as per XADD semantics since it didn't contain a value fetch. The\nBPF_READ also included a check in check_stack_read_fixed_off() which rejects\nthe program if the stack slot is of __is_pointer_value() if dst_regno < 0.\nThe latter is to distinguish whether we're dealing with a regular stack spill/\nfill or some arithmetical operation which is disallowed on non-scalars, see\nalso 6e7e63cbb023 (\"bpf: Forbid XADD on spilled pointers for unprivileged\nusers\") for more context on check_mem_access() and its handling of placeholder\nvalue -1.\n\nOne minimally intrusive option to fix the leak is for the BPF_FETCH case to\ninitially check the BPF_READ case via check_mem_access() with -1 as register,\nfollowed by the actual load case with non-negative load_reg to propagate\nstack bounds to registers."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: bpf: corrige la fuga de la direcci\u00f3n del kernel en la recuperaci\u00f3n at\u00f3mica. El cambio en el commit 37086bfdc737 (\"bpf: propaga los l\u00edmites de la pila a los registros en at\u00f3micos con BPF_FETCH\") alrededor del manejo de check_mem_access() tiene errores ya que esto permitir\u00eda a usuarios sin privilegios filtrar punteros del kernel. Por ejemplo, una recuperaci\u00f3n at\u00f3mica/y con -1 en un destino de pila que contiene un puntero derramado migrar\u00e1 el tipo de registro derramado a un escalar, que luego se puede exportar fuera del programa (ya que escalar! = puntero) volc\u00e1ndolo en un valor de mapa. La implementaci\u00f3n original de XADD evitaba esta situaci\u00f3n mediante el uso de una llamada doble a check_mem_access(), una con BPF_READ y otra posterior con BPF_WRITE, en ambos casos pasando -1 como valor de marcador de posici\u00f3n en lugar de registrarse seg\u00fan la sem\u00e1ntica de XADD, ya que no lo hac\u00eda contener una recuperaci\u00f3n de valor. BPF_READ tambi\u00e9n incluy\u00f3 una verificaci\u00f3n en check_stack_read_fixed_off() que rechaza el programa si la ranura de la pila es de __is_pointer_value() si dst_regno < 0. Esto \u00faltimo es para distinguir si estamos tratando con un derrame/llenado de pila regular o alguna operaci\u00f3n aritm\u00e9tica que no est\u00e1 permitido en valores no escalares, consulte tambi\u00e9n 6e7e63cbb023 (\"bpf: Prohibir XADD en punteros dispersos para usuarios sin privilegios\") para obtener m\u00e1s contexto sobre check_mem_access() y su manejo del valor del marcador de posici\u00f3n -1. Una opci\u00f3n m\u00ednimamente intrusiva para solucionar la fuga es que el caso BPF_FETCH verifique inicialmente el caso BPF_READ mediante check_mem_access() con -1 como registro, seguido del caso de carga real con load_reg no negativo para propagar los l\u00edmites de la pila a los registros."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47609",
|
"id": "CVE-2021-47609",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.457",
|
"published": "2024-06-19T15:15:55.457",
|
||||||
"lastModified": "2024-06-19T15:15:55.457",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scpi: Fix string overflow in SCPI genpd driver\n\nWithout the bound checks for scpi_pd->name, it could result in the buffer\noverflow when copying the SCPI device name from the corresponding device\ntree node as the name string is set at maximum size of 30.\n\nLet us fix it by using devm_kasprintf so that the string buffer is\nallocated dynamically."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scpi: Fix string overflow in SCPI genpd driver\n\nWithout the bound checks for scpi_pd->name, it could result in the buffer\noverflow when copying the SCPI device name from the corresponding device\ntree node as the name string is set at maximum size of 30.\n\nLet us fix it by using devm_kasprintf so that the string buffer is\nallocated dynamically."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scpi: corrige el desbordamiento de cadena en el controlador SCPI genpd. Sin las comprobaciones vinculadas para scpi_pd->name, podr\u00eda provocar un desbordamiento del b\u00fafer al copiar el nombre del dispositivo SCPI del dispositivo correspondiente. El nodo del \u00e1rbol como cadena de nombre se establece en un tama\u00f1o m\u00e1ximo de 30. Arreglemoslo usando devm_kasprintf para que el b\u00fafer de cadena se asigne din\u00e1micamente."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47610",
|
"id": "CVE-2021-47610",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.557",
|
"published": "2024-06-19T15:15:55.557",
|
||||||
"lastModified": "2024-06-19T15:15:55.557",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Fix null ptr access msm_ioctl_gem_submit()\n\nFix the below null pointer dereference in msm_ioctl_gem_submit():\n\n 26545.260705: Call trace:\n 26545.263223: kref_put+0x1c/0x60\n 26545.266452: msm_ioctl_gem_submit+0x254/0x744\n 26545.270937: drm_ioctl_kernel+0xa8/0x124\n 26545.274976: drm_ioctl+0x21c/0x33c\n 26545.278478: drm_compat_ioctl+0xdc/0xf0\n 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100\n 26545.287169: el0_svc_common+0xf8/0x250\n 26545.291025: do_el0_svc_compat+0x28/0x54\n 26545.295066: el0_svc_compat+0x10/0x1c\n 26545.298838: el0_sync_compat_handler+0xa8/0xcc\n 26545.303403: el0_sync_compat+0x188/0x1c0\n 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008)\n 26545.318799: Kernel panic - not syncing: Oops: Fatal exception"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Fix null ptr access msm_ioctl_gem_submit()\n\nFix the below null pointer dereference in msm_ioctl_gem_submit():\n\n 26545.260705: Call trace:\n 26545.263223: kref_put+0x1c/0x60\n 26545.266452: msm_ioctl_gem_submit+0x254/0x744\n 26545.270937: drm_ioctl_kernel+0xa8/0x124\n 26545.274976: drm_ioctl+0x21c/0x33c\n 26545.278478: drm_compat_ioctl+0xdc/0xf0\n 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100\n 26545.287169: el0_svc_common+0xf8/0x250\n 26545.291025: do_el0_svc_compat+0x28/0x54\n 26545.295066: el0_svc_compat+0x10/0x1c\n 26545.298838: el0_sync_compat_handler+0xa8/0xcc\n 26545.303403: el0_sync_compat+0x188/0x1c0\n 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008)\n 26545.318799: Kernel panic - not syncing: Oops: Fatal exception"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: corrige el acceso ptr nulo msm_ioctl_gem_submit() Corrige la siguiente desreferencia del puntero nulo en msm_ioctl_gem_submit(): 26545.260705: Rastreo de llamadas: 26545.263223: kref_put+0x1c/0x60 26545.266452 msm: _ioctl_gem_submit+ 0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 : __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: 0 /0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: C\u00f3digo: d503201f d503201f 52800028 4b0803e8 680008) 26545.318799: P\u00e1nico del kernel: no se sincroniza: Ups: excepci\u00f3n fatal"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47611",
|
"id": "CVE-2021-47611",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.650",
|
"published": "2024-06-19T15:15:55.650",
|
||||||
"lastModified": "2024-06-19T15:15:55.650",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: validate extended element ID is present\n\nBefore attempting to parse an extended element, verify that\nthe extended element ID is present."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: validate extended element ID is present\n\nBefore attempting to parse an extended element, verify that\nthe extended element ID is present."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mac80211: validar que el ID del elemento extendido est\u00e9 presente Antes de intentar analizar un elemento extendido, verifique que el ID del elemento extendido est\u00e9 presente."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47612",
|
"id": "CVE-2021-47612",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.750",
|
"published": "2024-06-19T15:15:55.750",
|
||||||
"lastModified": "2024-06-19T15:15:55.750",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fix segfault in nfc_genl_dump_devices_done\n\nWhen kmalloc in nfc_genl_dump_devices() fails then\nnfc_genl_dump_devices_done() segfaults as below\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:klist_iter_exit+0x26/0x80\nCall Trace:\n<TASK>\nclass_dev_iter_exit+0x15/0x20\nnfc_genl_dump_devices_done+0x3b/0x50\ngenl_lock_done+0x84/0xd0\nnetlink_sock_destruct+0x8f/0x270\n__sk_destruct+0x64/0x3b0\nsk_destruct+0xa8/0xd0\n__sk_free+0x2e8/0x3d0\nsk_free+0x51/0x90\nnetlink_sock_destruct_work+0x1c/0x20\nprocess_one_work+0x411/0x710\nworker_thread+0x6fd/0xa80"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fix segfault in nfc_genl_dump_devices_done\n\nWhen kmalloc in nfc_genl_dump_devices() fails then\nnfc_genl_dump_devices_done() segfaults as below\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:klist_iter_exit+0x26/0x80\nCall Trace:\n<TASK>\nclass_dev_iter_exit+0x15/0x20\nnfc_genl_dump_devices_done+0x3b/0x50\ngenl_lock_done+0x84/0xd0\nnetlink_sock_destruct+0x8f/0x270\n__sk_destruct+0x64/0x3b0\nsk_destruct+0xa8/0xd0\n__sk_free+0x2e8/0x3d0\nsk_free+0x51/0x90\nnetlink_sock_destruct_work+0x1c/0x20\nprocess_one_work+0x411/0x710\nworker_thread+0x6fd/0xa80"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: corrige el error de segmentaci\u00f3n en nfc_genl_dump_devices_done Cuando falla kmalloc en nfc_genl_dump_devices(), entonces el error de segmentaci\u00f3n de nfc_genl_dump_devices_done() se muestra a continuaci\u00f3n KASAN: null-ptr-deref en el rango [0x0000000000000008-0x00 0000000000000f] CPU: 0 PID : 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/ 2014 Cola de trabajo: eventos netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Seguimiento de llamadas: class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 estructura+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 Process_one_work+0x411/0x710 trabajador_thread+0x6fd/0xa80"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47613",
|
"id": "CVE-2021-47613",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.850",
|
"published": "2024-06-19T15:15:55.850",
|
||||||
"lastModified": "2024-06-19T15:15:55.850",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: virtio: fix completion handling\n\nThe driver currently assumes that the notify callback is only received\nwhen the device is done with all the queued buffers.\n\nHowever, this is not true, since the notify callback could be called\nwithout any of the queued buffers being completed (for example, with\nvirtio-pci and shared interrupts) or with only some of the buffers being\ncompleted (since the driver makes them available to the device in\nmultiple separate virtqueue_add_sgs() calls).\n\nThis can lead to incorrect data on the I2C bus or memory corruption in\nthe guest if the device operates on buffers which are have been freed by\nthe driver. (The WARN_ON in the driver is also triggered.)\n\n BUG kmalloc-128 (Tainted: G W ): Poison overwritten\n First byte 0x0 instead of 0x6b\n Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28\n \tmemdup_user+0x2e/0xbd\n \ti2cdev_ioctl_rdwr+0x9d/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28\n \tkfree+0x1bd/0x1cc\n \ti2cdev_ioctl_rdwr+0x1bb/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n\nFix this by calling virtio_get_buf() from the notify handler like other\nvirtio drivers and by actually waiting for all the buffers to be\ncompleted."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: virtio: fix completion handling\n\nThe driver currently assumes that the notify callback is only received\nwhen the device is done with all the queued buffers.\n\nHowever, this is not true, since the notify callback could be called\nwithout any of the queued buffers being completed (for example, with\nvirtio-pci and shared interrupts) or with only some of the buffers being\ncompleted (since the driver makes them available to the device in\nmultiple separate virtqueue_add_sgs() calls).\n\nThis can lead to incorrect data on the I2C bus or memory corruption in\nthe guest if the device operates on buffers which are have been freed by\nthe driver. (The WARN_ON in the driver is also triggered.)\n\n BUG kmalloc-128 (Tainted: G W ): Poison overwritten\n First byte 0x0 instead of 0x6b\n Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28\n \tmemdup_user+0x2e/0xbd\n \ti2cdev_ioctl_rdwr+0x9d/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28\n \tkfree+0x1bd/0x1cc\n \ti2cdev_ioctl_rdwr+0x1bb/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n\nFix this by calling virtio_get_buf() from the notify handler like other\nvirtio drivers and by actually waiting for all the buffers to be\ncompleted."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: i2c: virtio: manejo de finalizaci\u00f3n de reparaci\u00f3n El controlador actualmente supone que la devoluci\u00f3n de llamada de notificaci\u00f3n solo se recibe cuando el dispositivo termina con todos los b\u00faferes en cola. Sin embargo, esto no es cierto, ya que la devoluci\u00f3n de llamada de notificaci\u00f3n podr\u00eda llamarse sin que se complete ninguno de los b\u00faferes en cola (por ejemplo, con virtio-pci e interrupciones compartidas) o con solo algunos de los b\u00faferes completados (ya que el controlador los pone a disposici\u00f3n). al dispositivo en m\u00faltiples llamadas virtqueue_add_sgs() separadas). Esto puede provocar datos incorrectos en el bus I2C o da\u00f1os en la memoria del hu\u00e9sped si el dispositivo funciona con b\u00faferes que han sido liberados por el controlador. (El WARN_ON en el controlador tambi\u00e9n se activa). ERROR kmalloc-128 (Contaminado: GW): Veneno sobrescrito Primer byte 0x0 en lugar de 0x6b Asignado en i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28 memdup_user+0x2e/0xbd i2cdev_ioctl_rdwr+0x9d/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Liberado en i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28 0x1cc i2cdev_ioctl_rdwr+0x1bb/0x1de i2cdev_ioctl+0x247/ 0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Solucione este problema llamando a virtio_get_buf() desde el controlador de notificaci\u00f3n como otros controladores virtio y esperando a que se completen todos los b\u00faferes."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47614",
|
"id": "CVE-2021-47614",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:55.943",
|
"published": "2024-06-19T15:15:55.943",
|
||||||
"lastModified": "2024-06-19T15:15:55.943",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix a user-after-free in add_pble_prm\n\nWhen irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE\ninfo list.\n\nAdd the chunk entry to the PBLE info list only after successful setting of\nthe SD in irdma_hmc_sd_one."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix a user-after-free in add_pble_prm\n\nWhen irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE\ninfo list.\n\nAdd the chunk entry to the PBLE info list only after successful setting of\nthe SD in irdma_hmc_sd_one."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: RDMA/irdma: corrige un user-after-free en add_pble_prm Cuando falla irdma_hmc_sd_one, el 'fragmento' se libera mientras todav\u00eda est\u00e1 en la lista de informaci\u00f3n de PBLE. Agregue la entrada del fragmento a la lista de informaci\u00f3n de PBLE solo despu\u00e9s de configurar correctamente la SD en irdma_hmc_sd_one."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47615",
|
"id": "CVE-2021-47615",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:56.030",
|
"published": "2024-06-19T15:15:56.030",
|
||||||
"lastModified": "2024-06-19T15:15:56.030",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix releasing unallocated memory in dereg MR flow\n\nFor the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though\nit is a user MR. This causes function mlx5_free_priv_descs() to think that\nit is a kernel MR, leading to wrongly accessing mr->descs that will get\nwrong values in the union which leads to attempt to release resources that\nwere not allocated in the first place.\n\nFor example:\n DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]\n WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0\n RIP: 0010:check_unmap+0x54f/0x8b0\n Call Trace:\n debug_dma_unmap_page+0x57/0x60\n mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]\n mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]\n ib_dereg_mr_user+0x60/0x140 [ib_core]\n uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]\n uobj_destroy+0x3f/0x80 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]\n ? uverbs_finalize_object+0x50/0x50 [ib_uverbs]\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquired+0x12/0x380\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquire+0xc4/0x2e0\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n ? lock_release+0x28a/0x400\n ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n __x64_sys_ioctl+0x7f/0xb0\n do_syscall_64+0x38/0x90\n\nFix it by reorganizing the dereg flow and mlx5_ib_mr structure:\n - Move the ib_umem field into the user MRs structure in the union as it's\n applicable only there.\n - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only\n in case there isn't udata, which indicates that this isn't a user MR."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix releasing unallocated memory in dereg MR flow\n\nFor the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though\nit is a user MR. This causes function mlx5_free_priv_descs() to think that\nit is a kernel MR, leading to wrongly accessing mr->descs that will get\nwrong values in the union which leads to attempt to release resources that\nwere not allocated in the first place.\n\nFor example:\n DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]\n WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0\n RIP: 0010:check_unmap+0x54f/0x8b0\n Call Trace:\n debug_dma_unmap_page+0x57/0x60\n mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]\n mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]\n ib_dereg_mr_user+0x60/0x140 [ib_core]\n uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]\n uobj_destroy+0x3f/0x80 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]\n ? uverbs_finalize_object+0x50/0x50 [ib_uverbs]\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquired+0x12/0x380\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquire+0xc4/0x2e0\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n ? lock_release+0x28a/0x400\n ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n __x64_sys_ioctl+0x7f/0xb0\n do_syscall_64+0x38/0x90\n\nFix it by reorganizing the dereg flow and mlx5_ib_mr structure:\n - Move the ib_umem field into the user MRs structure in the union as it's\n applicable only there.\n - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only\n in case there isn't udata, which indicates that this isn't a user MR."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: RDMA/mlx5: Se corrigi\u00f3 la liberaci\u00f3n de memoria no asignada en el flujo de MR dereg. Para el caso de IB_MR_TYPE_DM, mr no tiene un umem, aunque sea un usuario MR. Esto hace que la funci\u00f3n mlx5_free_priv_descs() piense que es un MR del kernel, lo que lleva a un acceso incorrecto a mr->descs que obtendr\u00e1 valores incorrectos en la uni\u00f3n, lo que lleva a intentar liberar recursos que no fueron asignados en primer lugar. Por ejemplo: DMA-API: mlx5_core 0000:08:00.1: el controlador de dispositivo intenta liberar la memoria DMA que no ha asignado [direcci\u00f3n del dispositivo=0x0000000000000000] [tama\u00f1o=0 bytes] ADVERTENCIA: CPU: 8 PID: 1021 en kernel/dma/ debug.c:961 check_unmap+0x54f/0x8b0 RIP: 0010:check_unmap+0x54f/0x8b0 Seguimiento de llamadas: debug_dma_unmap_page+0x57/0x60 mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] [mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core ] uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80 [ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ? uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0? lock_adquirido+0x12/0x380? lock_acquire+0xc4/0x2e0? lock_acquire+0xc4/0x2e0? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] ? lock_release+0x28a/0x400 ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] __x64_sys_ioctl+0x7f/0xb0 do_syscall_64+0x38/0x90 Soluci\u00f3nelo reorganizando el flujo de dereg y la estructura mlx5_ib_mr: - Mueva el campo ib_umem a la estructura MRs del usuario en la uni\u00f3n, ya que solo se aplica all\u00ed. - La funci\u00f3n mlx5_ib_dereg_mr() ahora llamar\u00e1 a mlx5_free_priv_descs() solo en caso de que no haya udata, lo que indica que no se trata de un usuario MR."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47616",
|
"id": "CVE-2021-47616",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-19T15:15:56.130",
|
"published": "2024-06-19T15:15:56.130",
|
||||||
"lastModified": "2024-06-19T15:15:56.130",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: Fix use-after-free in rxe_queue_cleanup\n\nOn error handling path in rxe_qp_from_init() qp->sq.queue is freed and\nthen rxe_create_qp() will drop last reference to this object. qp clean up\nfunction will try to free this queue one time and it causes UAF bug.\n\nFix it by zeroing queue pointer after freeing queue in rxe_qp_from_init()."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: Fix use-after-free in rxe_queue_cleanup\n\nOn error handling path in rxe_qp_from_init() qp->sq.queue is freed and\nthen rxe_create_qp() will drop last reference to this object. qp clean up\nfunction will try to free this queue one time and it causes UAF bug.\n\nFix it by zeroing queue pointer after freeing queue in rxe_qp_from_init()."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: RDMA: corrige el use-after-free en rxe_queue_cleanup En la ruta de manejo de errores en rxe_qp_from_init() qp->sq.queue se libera y luego rxe_create_qp() eliminar\u00e1 la \u00faltima referencia a este objeto. La funci\u00f3n de limpieza qp intentar\u00e1 liberar esta cola una vez y provocar\u00e1 un error UAF. Solucionarlo poniendo a cero el puntero de la cola despu\u00e9s de liberar la cola en rxe_qp_from_init()."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47617",
|
"id": "CVE-2021-47617",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.317",
|
"published": "2024-06-20T11:15:54.317",
|
||||||
"lastModified": "2024-06-20T11:15:54.317",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Fix infinite loop in IRQ handler upon power fault\n\nThe Power Fault Detected bit in the Slot Status register differs from\nall other hotplug events in that it is sticky: It can only be cleared\nafter turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:\n\n If a power controller detects a main power fault on the hot-plug slot,\n it must automatically set its internal main power fault latch [...].\n The main power fault latch is cleared when software turns off power to\n the hot-plug slot.\n\nThe stickiness used to cause interrupt storms and infinite loops which\nwere fixed in 2009 by commits 5651c48cfafe (\"PCI pciehp: fix power fault\ninterrupt storm problem\") and 99f0169c17f3 (\"PCI: pciehp: enable\nsoftware notification on empty slots\").\n\nUnfortunately in 2020 the infinite loop issue was inadvertently\nreintroduced by commit 8edf5332c393 (\"PCI: pciehp: Fix MSI interrupt\nrace\"): The hardirq handler pciehp_isr() clears the PFD bit until\npciehp's power_fault_detected flag is set. That happens in the IRQ\nthread pciehp_ist(), which never learns of the event because the hardirq\nhandler is stuck in an infinite loop. Fix by setting the\npower_fault_detected flag already in the hardirq handler."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Fix infinite loop in IRQ handler upon power fault\n\nThe Power Fault Detected bit in the Slot Status register differs from\nall other hotplug events in that it is sticky: It can only be cleared\nafter turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:\n\n If a power controller detects a main power fault on the hot-plug slot,\n it must automatically set its internal main power fault latch [...].\n The main power fault latch is cleared when software turns off power to\n the hot-plug slot.\n\nThe stickiness used to cause interrupt storms and infinite loops which\nwere fixed in 2009 by commits 5651c48cfafe (\"PCI pciehp: fix power fault\ninterrupt storm problem\") and 99f0169c17f3 (\"PCI: pciehp: enable\nsoftware notification on empty slots\").\n\nUnfortunately in 2020 the infinite loop issue was inadvertently\nreintroduced by commit 8edf5332c393 (\"PCI: pciehp: Fix MSI interrupt\nrace\"): The hardirq handler pciehp_isr() clears the PFD bit until\npciehp's power_fault_detected flag is set. That happens in the IRQ\nthread pciehp_ist(), which never learns of the event because the hardirq\nhandler is stuck in an infinite loop. Fix by setting the\npower_fault_detected flag already in the hardirq handler."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pciehp: soluciona el bucle infinito en el controlador IRQ ante un fallo de alimentaci\u00f3n. El bit de fallo de alimentaci\u00f3n detectado en el registro de estado de la ranura se diferencia de todos los dem\u00e1s eventos de conexi\u00f3n en caliente en que es fijo: solo puede borrarse despu\u00e9s de apagar la alimentaci\u00f3n de la ranura. Por PCIe r5.0, seg. 6.7.1.8: Si un controlador de energ\u00eda detecta una falla de energ\u00eda principal en la ranura de conexi\u00f3n en caliente, debe configurar autom\u00e1ticamente su pestillo interno de falla de energ\u00eda principal [...]. El bloqueo de fallo de alimentaci\u00f3n principal se borra cuando el software corta la alimentaci\u00f3n a la ranura de conexi\u00f3n en caliente. La rigidez sol\u00eda causar tormentas de interrupci\u00f3n y bucles infinitos que se solucionaron en 2009 mediante los commits 5651c48cfafe (\"PCI pciehp: solucionar el problema de la tormenta de interrupci\u00f3n por falla de energ\u00eda\") y 99f0169c17f3 (\"PCI: pciehp: habilitar la notificaci\u00f3n de software en ranuras vac\u00edas\"). Desafortunadamente, en 2020, el problema del bucle infinito se reintrodujo inadvertidamente mediante el commit 8edf5332c393 (\"PCI: pciehp: arreglar carrera de interrupci\u00f3n MSI\"): el controlador hardirq pciehp_isr() borra el bit PFD hasta que se establece el indicador power_fault_detected de pciehp. Eso sucede en el hilo IRQ pciehp_ist(), que nunca se entera del evento porque el controlador hardirq est\u00e1 atrapado en un bucle infinito. Para solucionarlo, configure el indicador power_fault_detected que ya est\u00e1 en el controlador hardirq."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47618",
|
"id": "CVE-2021-47618",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.477",
|
"published": "2024-06-20T11:15:54.477",
|
||||||
"lastModified": "2024-06-20T11:15:54.477",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9170/1: fix panic when kasan and kprobe are enabled\n\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\n\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\n\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n<cap_capable>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108 ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144] ;\nebfc7bf8\tbl\tc03aa4b4 <__asan_load4>\ne595706c\tldr\tr7, [r5, #108] ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 <emulate_ldr>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60 ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 <__asan_load4>\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc <emulate_ldr+0x38>\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 <__asan_load4>\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 <__asan_load4>\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 <__asan_load4>\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 <emulate_ldr+0xac>\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64 ; 0x40\n......\n\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c\nr10: 00000000 r9 : c30897f4 r8 : ecd63cd4\nr7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98\nr3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008\nFlags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user\nControl: 32c5387d Table: 2d546400 DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9170/1: fix panic when kasan and kprobe are enabled\n\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\n\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\n\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n<cap_capable>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108 ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144] ;\nebfc7bf8\tbl\tc03aa4b4 <__asan_load4>\ne595706c\tldr\tr7, [r5, #108] ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 <emulate_ldr>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60 ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 <__asan_load4>\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc <emulate_ldr+0x38>\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 <__asan_load4>\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 <__asan_load4>\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 <__asan_load4>\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 <emulate_ldr+0xac>\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64 ; 0x40\n......\n\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c\nr10: 00000000 r9 : c30897f4 r8 : ecd63cd4\nr7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98\nr3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008\nFlags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user\nControl: 32c5387d Table: 2d546400 DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9170/1: soluciona el p\u00e1nico cuando kasan y kprobe est\u00e1n habilitados arm32 usa software para simular la instrucci\u00f3n reemplazada por kprobe. Algunas instrucciones pueden simularse mediante la construcci\u00f3n de funciones de ensamblaje. por lo tanto, antes de ejecutar la simulaci\u00f3n de instrucciones, es necesario construir un entorno de ejecuci\u00f3n de funciones de ensamblaje en lenguaje C mediante registros vinculantes. despu\u00e9s de habilitar kasan, la relaci\u00f3n de enlace de registros se destruir\u00e1, lo que provocar\u00e1 errores de simulaci\u00f3n de instrucciones y provocar\u00e1 p\u00e1nico en el kernel. La funci\u00f3n de emulaci\u00f3n de instrucciones de kprobe se distribuye en tres archivos: acciones-common.c acciones-arm.c acciones-thumb.c, por lo tanto, desactive KASAN al compilar estos archivos. por ejemplo, use kprobe insert en cap_capable+20 despu\u00e9s de habilitar kasan, el c\u00f3digo ensamblador de cap_capable es el siguiente: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c agregue r0, r0, #108; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [ordenador personal, #144]; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108]; 0x6c e2859014 add r9, r5, #20 ...... El c\u00f3digo ensamblador emulate_ldr despu\u00e9s de habilitar kasan es el siguiente: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c agregue r8, r2, #60; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load 4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f y sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, 4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 agregar r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 14 bne c06f1430 e1a06000 mov r6, r0 e2840040 agregar r0, r4, #64; 0x40 ...... cuando se ejecuta emulate_ldr para simular la instrucci\u00f3n ldr, se produce p\u00e1nico y el registro es el siguiente: No se puede manejar la desreferencia del puntero NULL del kernel en la direcci\u00f3n virtual 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, * pmd=00000000 Error interno: Ups: 206 [#1] La PC SMP ARM est\u00e1 en cap_capable+0x14/0xb0 LR est\u00e1 en emulate_ldr+0x50/0xc0 psr: 600d0293 sp: ecd63af8 ip: 00000004 fp: c0a7c30c r10: r9: c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Banderas: nZCv IRQ desactivadas FIQ activadas Modo SVC_3 2 Usuario de segmento ISA ARM Control: 32c5387d Tabla: 2d546400 DAC: 55555555 Proceso bash (pid: 1643, l\u00edmite de pila = 0xecd60190) (cap_capable) de (kprobe_handler+0x218/0x340) (kprobe_handler) de (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) de (do_undefinstr+0x13c/0x364) (do_undefinstr) de (__ und_svc_finish+ 0x0/0x30) (__und_svc_finish) de (cap_capable+0x18/0xb0) (cap_capable) de (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) de (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) de (copy_process .constprop.5+0x16b4/ 0x25c8) (copy_process.constprop.5) de (_do_fork+0xe8/0x55c) (_do_fork) de (SyS_clone+0x1c/0x24) (SyS_clone) de (__sys_trace_return+0x0/0x10) C\u00f3digo: 0050a0e1 6c0080e2 0260a0e1 (f801f0e7)"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47619",
|
"id": "CVE-2021-47619",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.560",
|
"published": "2024-06-20T11:15:54.560",
|
||||||
"lastModified": "2024-06-20T11:15:54.560",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix queues reservation for XDP\n\nWhen XDP was configured on a system with large number of CPUs\nand X722 NIC there was a call trace with NULL pointer dereference.\n\ni40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12\ni40e 0000:87:00.0: setup of MAIN VSI failed\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nRIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]\nCall Trace:\n? i40e_reconfig_rss_queues+0x130/0x130 [i40e]\ndev_xdp_install+0x61/0xe0\ndev_xdp_attach+0x18a/0x4c0\ndev_change_xdp_fd+0x1e6/0x220\ndo_setlink+0x616/0x1030\n? ahci_port_stop+0x80/0x80\n? ata_qc_issue+0x107/0x1e0\n? lock_timer_base+0x61/0x80\n? __mod_timer+0x202/0x380\nrtnl_setlink+0xe5/0x170\n? bpf_lsm_binder_transaction+0x10/0x10\n? security_capable+0x36/0x50\nrtnetlink_rcv_msg+0x121/0x350\n? rtnl_calcit.isra.0+0x100/0x100\nnetlink_rcv_skb+0x50/0xf0\nnetlink_unicast+0x1d3/0x2a0\nnetlink_sendmsg+0x22a/0x440\nsock_sendmsg+0x5e/0x60\n__sys_sendto+0xf0/0x160\n? __sys_getsockname+0x7e/0xc0\n? _copy_from_user+0x3c/0x80\n? __sys_setsockopt+0xc8/0x1a0\n__x64_sys_sendto+0x20/0x30\ndo_syscall_64+0x33/0x40\nentry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f83fa7a39e0\n\nThis was caused by PF queue pile fragmentation due to\nflow director VSI queue being placed right after main VSI.\nBecause of this main VSI was not able to resize its\nqueue allocation for XDP resulting in no queues allocated\nfor main VSI when XDP was turned on.\n\nFix this by always allocating last queue in PF queue pile\nfor a flow director VSI."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix queues reservation for XDP\n\nWhen XDP was configured on a system with large number of CPUs\nand X722 NIC there was a call trace with NULL pointer dereference.\n\ni40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12\ni40e 0000:87:00.0: setup of MAIN VSI failed\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nRIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]\nCall Trace:\n? i40e_reconfig_rss_queues+0x130/0x130 [i40e]\ndev_xdp_install+0x61/0xe0\ndev_xdp_attach+0x18a/0x4c0\ndev_change_xdp_fd+0x1e6/0x220\ndo_setlink+0x616/0x1030\n? ahci_port_stop+0x80/0x80\n? ata_qc_issue+0x107/0x1e0\n? lock_timer_base+0x61/0x80\n? __mod_timer+0x202/0x380\nrtnl_setlink+0xe5/0x170\n? bpf_lsm_binder_transaction+0x10/0x10\n? security_capable+0x36/0x50\nrtnetlink_rcv_msg+0x121/0x350\n? rtnl_calcit.isra.0+0x100/0x100\nnetlink_rcv_skb+0x50/0xf0\nnetlink_unicast+0x1d3/0x2a0\nnetlink_sendmsg+0x22a/0x440\nsock_sendmsg+0x5e/0x60\n__sys_sendto+0xf0/0x160\n? __sys_getsockname+0x7e/0xc0\n? _copy_from_user+0x3c/0x80\n? __sys_setsockopt+0xc8/0x1a0\n__x64_sys_sendto+0x20/0x30\ndo_syscall_64+0x33/0x40\nentry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f83fa7a39e0\n\nThis was caused by PF queue pile fragmentation due to\nflow director VSI queue being placed right after main VSI.\nBecause of this main VSI was not able to resize its\nqueue allocation for XDP resulting in no queues allocated\nfor main VSI when XDP was turned on.\n\nFix this by always allocating last queue in PF queue pile\nfor a flow director VSI."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Arreglar la reserva de colas para XDP Cuando se configur\u00f3 XDP en un sistema con una gran cantidad de CPU y NIC X722, hubo un seguimiento de llamada con desreferencia de puntero NULL. i40e 0000:87:00.0: no se pudo obtener el seguimiento de 256 colas para VSI 0 err -12 i40e 0000:87:00.0: fall\u00f3 la configuraci\u00f3n de VSI PRINCIPAL ERROR: desreferencia del puntero NULL del kernel, direcci\u00f3n: 00000000000000000 RIP: 0010:i40e_xdp+0xea/ 0x1b0 [i40e] Seguimiento de llamadas:? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80? ata_qc_issue+0x107/0x1e0? lock_timer_base+0x61/0x80? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10? capacidad_seguridad+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copia_de_usuario+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 Esto fue causado por la fragmentaci\u00f3n de la pila de cola PF debido al flujo La cola VSI del director se coloca justo despu\u00e9s de la VSI principal. Debido a esto, la VSI principal no pudo cambiar el tama\u00f1o de su asignaci\u00f3n de cola para XDP, lo que provoc\u00f3 que no se asignaran colas para la VSI principal cuando se activ\u00f3 XDP. Solucione este problema asignando siempre la \u00faltima cola en la pila de colas PF para una VSI de director de flujo."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2021-47620",
|
"id": "CVE-2021-47620",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.653",
|
"published": "2024-06-20T11:15:54.653",
|
||||||
"lastModified": "2024-06-20T11:15:54.653",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: refactor malicious adv data check\n\nCheck for out-of-bound read was being performed at the end of while\nnum_reports loop, and would fill journal with false positives. Added\ncheck to beginning of loop processing so that it doesn't get checked\nafter ptr has been advanced."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: refactor malicious adv data check\n\nCheck for out-of-bound read was being performed at the end of while\nnum_reports loop, and would fill journal with false positives. Added\ncheck to beginning of loop processing so that it doesn't get checked\nafter ptr has been advanced."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: Bluetooth: refactorizaci\u00f3n de verificaci\u00f3n de datos publicitarios maliciosos. Se estaba realizando una verificaci\u00f3n de lectura fuera de los l\u00edmites al final del bucle while num_reports y llenar\u00eda el diario con falsos positivos. Se agreg\u00f3 una verificaci\u00f3n al comienzo del procesamiento del bucle para que no se verifique despu\u00e9s de que se haya avanzado ptr."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-23829",
|
"id": "CVE-2022-23829",
|
||||||
"sourceIdentifier": "psirt@amd.com",
|
"sourceIdentifier": "psirt@amd.com",
|
||||||
"published": "2024-06-18T19:15:56.957",
|
"published": "2024-06-18T19:15:56.957",
|
||||||
"lastModified": "2024-06-18T19:15:56.957",
|
"lastModified": "2024-06-20T12:44:01.637",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "A potential weakness in AMD SPI protection features may allow a malicious attacker with Ring0 (kernel mode) access to bypass the native System Management Mode (SMM) ROM protections."
|
"value": "A potential weakness in AMD SPI protection features may allow a malicious attacker with Ring0 (kernel mode) access to bypass the native System Management Mode (SMM) ROM protections."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "Una posible debilidad en las funciones de protecci\u00f3n AMD SPI puede permitir que un atacante malicioso con acceso Ring0 (modo kernel) evite las protecciones ROM nativas del modo de administraci\u00f3n del sistema (SMM)."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {
|
"metrics": {
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-45832",
|
"id": "CVE-2022-45832",
|
||||||
"sourceIdentifier": "audit@patchstack.com",
|
"sourceIdentifier": "audit@patchstack.com",
|
||||||
"published": "2024-06-19T15:15:56.223",
|
"published": "2024-06-19T15:15:56.223",
|
||||||
"lastModified": "2024-06-19T15:15:56.223",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "Missing Authorization vulnerability in Hennessey Digital Attorney.This issue affects Attorney: from n/a through 3."
|
"value": "Missing Authorization vulnerability in Hennessey Digital Attorney.This issue affects Attorney: from n/a through 3."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "Vulnerabilidad de falta de autorizaci\u00f3n en Hennessey Digital Attorney. Este problema afecta a Attorney: desde n/a hasta 3."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {
|
"metrics": {
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48711",
|
"id": "CVE-2022-48711",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.793",
|
"published": "2024-06-20T11:15:54.793",
|
||||||
"lastModified": "2024-06-20T11:15:54.793",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: improve size validations for received domain records\n\nThe function tipc_mon_rcv() allows a node to receive and process\ndomain_record structs from peer nodes to track their views of the\nnetwork topology.\n\nThis patch verifies that the number of members in a received domain\nrecord does not exceed the limit defined by MAX_MON_DOMAIN, something\nthat may otherwise lead to a stack overflow.\n\ntipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where\nwe are reading a 32 bit message data length field into a uint16. To\navert any risk of bit overflow, we add an extra sanity check for this in\nthat function. We cannot see that happen with the current code, but\nfuture designers being unaware of this risk, may introduce it by\nallowing delivery of very large (> 64k) sk buffers from the bearer\nlayer. This potential problem was identified by Eric Dumazet.\n\nThis fixes CVE-2022-0435"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: improve size validations for received domain records\n\nThe function tipc_mon_rcv() allows a node to receive and process\ndomain_record structs from peer nodes to track their views of the\nnetwork topology.\n\nThis patch verifies that the number of members in a received domain\nrecord does not exceed the limit defined by MAX_MON_DOMAIN, something\nthat may otherwise lead to a stack overflow.\n\ntipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where\nwe are reading a 32 bit message data length field into a uint16. To\navert any risk of bit overflow, we add an extra sanity check for this in\nthat function. We cannot see that happen with the current code, but\nfuture designers being unaware of this risk, may introduce it by\nallowing delivery of very large (> 64k) sk buffers from the bearer\nlayer. This potential problem was identified by Eric Dumazet.\n\nThis fixes CVE-2022-0435"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: tipc: mejorar las validaciones de tama\u00f1o para los registros de dominio recibidos. La funci\u00f3n tipc_mon_rcv() permite que un nodo reciba y procese estructuras domain_record de nodos pares para rastrear sus vistas de la topolog\u00eda de la red. Este parche verifica que la cantidad de miembros en un registro de dominio recibido no exceda el l\u00edmite definido por MAX_MON_DOMAIN, algo que de otro modo podr\u00eda provocar un desbordamiento de pila. tipc_mon_rcv() se llama desde la funci\u00f3n tipc_link_proto_rcv(), donde leemos un campo de longitud de datos de mensaje de 32 bits en un uint16. Para evitar cualquier riesgo de desbordamiento de bits, agregamos una verificaci\u00f3n de cordura adicional en esa funci\u00f3n. No podemos ver que eso suceda con el c\u00f3digo actual, pero los futuros dise\u00f1adores, al desconocer este riesgo, pueden introducirlo permitiendo la entrega de b\u00faferes sk muy grandes (> 64k) desde la capa portadora. Este problema potencial fue identificado por Eric Dumazet. Esto corrige CVE-2022-0435"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48712",
|
"id": "CVE-2022-48712",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.880",
|
"published": "2024-06-20T11:15:54.880",
|
||||||
"lastModified": "2024-06-20T11:15:54.880",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix error handling in ext4_fc_record_modified_inode()\n\nCurrent code does not fully takes care of krealloc() error case, which\ncould lead to silent memory corruption or a kernel bug. This patch\nfixes that.\n\nAlso it cleans up some duplicated error handling logic from various\nfunctions in fast_commit.c file."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix error handling in ext4_fc_record_modified_inode()\n\nCurrent code does not fully takes care of krealloc() error case, which\ncould lead to silent memory corruption or a kernel bug. This patch\nfixes that.\n\nAlso it cleans up some duplicated error handling logic from various\nfunctions in fast_commit.c file."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ext4: corrige el manejo de errores en ext4_fc_record_modified_inode() El c\u00f3digo actual no soluciona completamente el caso de error de krealloc(), lo que podr\u00eda provocar una corrupci\u00f3n silenciosa de la memoria o un error del kernel. Este parche soluciona eso. Tambi\u00e9n limpia alguna l\u00f3gica de manejo de errores duplicada de varias funciones en el archivo fast_commit.c."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48713",
|
"id": "CVE-2022-48713",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:54.960",
|
"published": "2024-06-20T11:15:54.960",
|
||||||
"lastModified": "2024-06-20T11:15:54.960",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/pt: Fix crash with stop filters in single-range mode\n\nAdd a check for !buf->single before calling pt_buffer_region_size in a\nplace where a missing check can cause a kernel crash.\n\nFixes a bug introduced by commit 670638477aed (\"perf/x86/intel/pt:\nOpportunistically use single range output mode\"), which added a\nsupport for PT single-range output mode. Since that commit if a PT\nstop filter range is hit while tracing, the kernel will crash because\nof a null pointer dereference in pt_handle_status due to calling\npt_buffer_region_size without a ToPA configured.\n\nThe commit which introduced single-range mode guarded almost all uses of\nthe ToPA buffer variables with checks of the buf->single variable, but\nmissed the case where tracing was stopped by the PT hardware, which\nhappens when execution hits a configured stop filter.\n\nTested that hitting a stop filter while PT recording successfully\nrecords a trace with this patch but crashes without this patch."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/pt: Fix crash with stop filters in single-range mode\n\nAdd a check for !buf->single before calling pt_buffer_region_size in a\nplace where a missing check can cause a kernel crash.\n\nFixes a bug introduced by commit 670638477aed (\"perf/x86/intel/pt:\nOpportunistically use single range output mode\"), which added a\nsupport for PT single-range output mode. Since that commit if a PT\nstop filter range is hit while tracing, the kernel will crash because\nof a null pointer dereference in pt_handle_status due to calling\npt_buffer_region_size without a ToPA configured.\n\nThe commit which introduced single-range mode guarded almost all uses of\nthe ToPA buffer variables with checks of the buf->single variable, but\nmissed the case where tracing was stopped by the PT hardware, which\nhappens when execution hits a configured stop filter.\n\nTested that hitting a stop filter while PT recording successfully\nrecords a trace with this patch but crashes without this patch."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel/pt: soluciona el fallo con filtros de parada en modo de rango \u00fanico. A\u00f1ade una marca para !buf->single antes de llamar a pt_buffer_region_size en un lugar donde una marca faltante puede provocar un fallo del kernel. Corrige un error introducido por el commit 670638477aed (\"perf/x86/intel/pt: utilizar de manera oportunista el modo de salida de rango \u00fanico\"), que agreg\u00f3 soporte para el modo de salida de rango \u00fanico PT. Desde esa confirmaci\u00f3n, si se alcanza un rango de filtro de parada PT durante el seguimiento, el kernel fallar\u00e1 debido a una desreferencia de puntero nulo en pt_handle_status debido a la llamada a pt_buffer_region_size sin un ToPA configurado. La confirmaci\u00f3n que introdujo el modo de rango \u00fanico protegi\u00f3 casi todos los usos de las variables del b\u00fafer ToPA con comprobaciones de la variable buf->single, pero omiti\u00f3 el caso en el que el hardware PT detuvo el seguimiento, lo que ocurre cuando la ejecuci\u00f3n llega a un filtro de parada configurado. Se prob\u00f3 que al presionar un filtro de detenci\u00f3n mientras se graba PT se registra exitosamente un seguimiento con este parche, pero falla sin este parche."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48714",
|
"id": "CVE-2022-48714",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.033",
|
"published": "2024-06-20T11:15:55.033",
|
||||||
"lastModified": "2024-06-20T11:15:55.033",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Use VM_MAP instead of VM_ALLOC for ringbuf\n\nAfter commit 2fd3fb0be1d1 (\"kasan, vmalloc: unpoison VM_ALLOC pages\nafter mapping\"), non-VM_ALLOC mappings will be marked as accessible\nin __get_vm_area_node() when KASAN is enabled. But now the flag for\nringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access\nafter vmap() returns. Because the ringbuf area is created by mapping\nallocated pages, so use VM_MAP instead.\n\nAfter the change, info in /proc/vmallocinfo also changes from\n [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user\nto\n [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Use VM_MAP instead of VM_ALLOC for ringbuf\n\nAfter commit 2fd3fb0be1d1 (\"kasan, vmalloc: unpoison VM_ALLOC pages\nafter mapping\"), non-VM_ALLOC mappings will be marked as accessible\nin __get_vm_area_node() when KASAN is enabled. But now the flag for\nringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access\nafter vmap() returns. Because the ringbuf area is created by mapping\nallocated pages, so use VM_MAP instead.\n\nAfter the change, info in /proc/vmallocinfo also changes from\n [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user\nto\n [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: bpf: use VM_MAP en lugar de VM_ALLOC para ringbuf Despu\u00e9s del commit 2fd3fb0be1d1 (\"kasan, vmalloc: despoisone las p\u00e1ginas VM_ALLOC despu\u00e9s del mapeo\"), los mapeos que no sean VM_ALLOC se marcar\u00e1n como accesibles en __get_vm_area_node( ) cuando KASAN est\u00e1 habilitado. Pero ahora el indicador para el \u00e1rea ringbuf es VM_ALLOC, por lo que KASAN se quejar\u00e1 del acceso fuera de los l\u00edmites despu\u00e9s de que regrese vmap(). Debido a que el \u00e1rea ringbuf se crea asignando p\u00e1ginas asignadas, use VM_MAP en su lugar. Despu\u00e9s del cambio, la informaci\u00f3n en /proc/vmallocinfo tambi\u00e9n cambia de [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmalloc a [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmap"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48715",
|
"id": "CVE-2022-48715",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.110",
|
"published": "2024-06-20T11:15:55.110",
|
||||||
"lastModified": "2024-06-20T11:15:55.110",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: bnx2fc: Make bnx2fc_recv_frame() mp safe\n\nRunning tests with a debug kernel shows that bnx2fc_recv_frame() is\nmodifying the per_cpu lport stats counters in a non-mpsafe way. Just boot\na debug kernel and run the bnx2fc driver with the hardware enabled.\n\n[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_\n[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B\n[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013\n[ 1391.699183] Call Trace:\n[ 1391.699188] dump_stack_lvl+0x57/0x7d\n[ 1391.699198] check_preemption_disabled+0xc8/0xd0\n[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180\n[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]\n[ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]\n[ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]\n[ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]\n[ 1391.699258] kthread+0x364/0x420\n[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50\n[ 1391.699268] ? set_kthread_struct+0x100/0x100\n[ 1391.699273] ret_from_fork+0x22/0x30\n\nRestore the old get_cpu/put_cpu code with some modifications to reduce the\nsize of the critical section."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: bnx2fc: Make bnx2fc_recv_frame() mp safe\n\nRunning tests with a debug kernel shows that bnx2fc_recv_frame() is\nmodifying the per_cpu lport stats counters in a non-mpsafe way. Just boot\na debug kernel and run the bnx2fc driver with the hardware enabled.\n\n[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_\n[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B\n[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013\n[ 1391.699183] Call Trace:\n[ 1391.699188] dump_stack_lvl+0x57/0x7d\n[ 1391.699198] check_preemption_disabled+0xc8/0xd0\n[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180\n[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]\n[ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]\n[ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]\n[ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]\n[ 1391.699258] kthread+0x364/0x420\n[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50\n[ 1391.699268] ? set_kthread_struct+0x100/0x100\n[ 1391.699273] ret_from_fork+0x22/0x30\n\nRestore the old get_cpu/put_cpu code with some modifications to reduce the\nsize of the critical section."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: bnx2fc: Hacer que bnx2fc_recv_frame() mp sea seguro La ejecuci\u00f3n de pruebas con un kernel de depuraci\u00f3n muestra que bnx2fc_recv_frame() est\u00e1 modificando los contadores de estad\u00edsticas de puerto por CPU de una manera no segura para mp. Simplemente inicie un kernel de depuraci\u00f3n y ejecute el controlador bnx2fc con el hardware habilitado. [1391.699147] ERROR: uso de smp_processor_id() en c\u00f3digo interrumpible [00000000]: bnx2fc_ [1391.699160] la persona que llama es bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: cargado Contaminado: GB [ 1391.699180 ] Nombre del hardware: HP ProLiant DL120 G7, BIOS J01 01/07/2013 [ 1391.699183] Seguimiento de llamadas: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.69 9205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [1391.699221]? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [1391.699229]? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50 [1391.699268]? set_kthread_struct+0x100/0x100 [ 1391.699273] ret_from_fork+0x22/0x30 Restaura el antiguo c\u00f3digo get_cpu/put_cpu con algunas modificaciones para reducir el tama\u00f1o de la secci\u00f3n cr\u00edtica."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48716",
|
"id": "CVE-2022-48716",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.207",
|
"published": "2024-06-20T11:15:55.207",
|
||||||
"lastModified": "2024-06-20T11:15:55.207",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: wcd938x: fix incorrect used of portid\n\nMixer controls have the channel id in mixer->reg, which is not same\nas port id. port id should be derived from chan_info array.\nSo fix this. Without this, its possible that we could corrupt\nstruct wcd938x_sdw_priv by accessing port_map array out of range\nwith channel id instead of port id."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: wcd938x: fix incorrect used of portid\n\nMixer controls have the channel id in mixer->reg, which is not same\nas port id. port id should be derived from chan_info array.\nSo fix this. Without this, its possible that we could corrupt\nstruct wcd938x_sdw_priv by accessing port_map array out of range\nwith channel id instead of port id."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ASoC: c\u00f3decs: wcd938x: corrige el uso incorrecto del puerto Los controles del mezclador tienen la identificaci\u00f3n del canal en mezclador->reg, que no es la misma que la identificaci\u00f3n del puerto. La identificaci\u00f3n del puerto debe derivarse de la matriz chan_info. Entonces arregla esto. Sin esto, es posible que podamos da\u00f1ar la estructura wcd938x_sdw_priv accediendo a la matriz port_map fuera del rango con la identificaci\u00f3n del canal en lugar de la identificaci\u00f3n del puerto."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48717",
|
"id": "CVE-2022-48717",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.287",
|
"published": "2024-06-20T11:15:55.287",
|
||||||
"lastModified": "2024-06-20T11:15:55.287",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: max9759: fix underflow in speaker_gain_control_put()\n\nCheck for negative values of \"priv->gain\" to prevent an out of bounds\naccess. The concern is that these might come from the user via:\n -> snd_ctl_elem_write_user()\n -> snd_ctl_elem_write()\n -> kctl->put()"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: max9759: fix underflow in speaker_gain_control_put()\n\nCheck for negative values of \"priv->gain\" to prevent an out of bounds\naccess. The concern is that these might come from the user via:\n -> snd_ctl_elem_write_user()\n -> snd_ctl_elem_write()\n -> kctl->put()"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: max9759: corrige el desbordamiento en altavoz_gain_control_put() Compruebe si hay valores negativos de \"priv->gain\" para evitar un acceso fuera de los l\u00edmites. La preocupaci\u00f3n es que estos puedan provenir del usuario a trav\u00e9s de: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put()"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48718",
|
"id": "CVE-2022-48718",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.373",
|
"published": "2024-06-20T11:15:55.373",
|
||||||
"lastModified": "2024-06-20T11:15:55.373",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: mxsfb: Fix NULL pointer dereference\n\nmxsfb should not ever dereference the NULL pointer which\ndrm_atomic_get_new_bridge_state is allowed to return.\nAssume a fixed format instead."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: mxsfb: Fix NULL pointer dereference\n\nmxsfb should not ever dereference the NULL pointer which\ndrm_atomic_get_new_bridge_state is allowed to return.\nAssume a fixed format instead."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: drm: mxsfb: corrige la desreferencia del puntero NULL. mxsfb nunca deber\u00eda desreferenciar el puntero NULL que drm_atomic_get_new_bridge_state puede devolver. En su lugar, asuma un formato fijo."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48719",
|
"id": "CVE-2022-48719",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.470",
|
"published": "2024-06-20T11:15:55.470",
|
||||||
"lastModified": "2024-06-20T11:15:55.470",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work\n\nsyzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:\n\n kworker/0:16/14617 is trying to acquire lock:\n ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652\n [...]\n but task is already holding lock:\n ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572\n\nThe neighbor entry turned to NUD_FAILED state, where __neigh_event_send()\ntriggered an immediate probe as per commit cd28ca0a3dd1 (\"neigh: reduce\narp latency\") via neigh_probe() given table lock was held.\n\nOne option to fix this situation is to defer the neigh_probe() back to\nthe neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case\nof NTF_MANAGED, this deferral is acceptable given this only happens on\nactual failure state and regular / expected state is NUD_VALID with the\nentry already present.\n\nThe fix adds a parameter to __neigh_event_send() in order to communicate\nwhether immediate probe is allowed or disallowed. Existing call-sites\nof neigh_event_send() default as-is to immediate probe. However, the\nneigh_managed_work() disables it via use of neigh_event_send_probe().\n\n[0] <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]\n check_deadlock kernel/locking/lockdep.c:2999 [inline]\n validate_chain kernel/locking/lockdep.c:3788 [inline]\n __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027\n lock_acquire kernel/locking/lockdep.c:5639 [inline]\n lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604\n __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [inline]\n _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334\n ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652\n ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123\n __ip6_finish_output net/ipv6/ip6_output.c:191 [inline]\n __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170\n ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201\n NF_HOOK_COND include/linux/netfilter.h:296 [inline]\n ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224\n dst_output include/net/dst.h:451 [inline]\n NF_HOOK include/linux/netfilter.h:307 [inline]\n ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508\n ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650\n ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c:742\n neigh_probe+0xc2/0x110 net/core/neighbour.c:1040\n __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201\n neigh_event_send include/net/neighbour.h:470 [inline]\n neigh_managed_work+0x162/0x250 net/core/neighbour.c:1574\n process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307\n worker_thread+0x657/0x1110 kernel/workqueue.c:2454\n kthread+0x2e9/0x3a0 kernel/kthread.c:377\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n </TASK>"
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work\n\nsyzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]:\n\n kworker/0:16/14617 is trying to acquire lock:\n ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652\n [...]\n but task is already holding lock:\n ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572\n\nThe neighbor entry turned to NUD_FAILED state, where __neigh_event_send()\ntriggered an immediate probe as per commit cd28ca0a3dd1 (\"neigh: reduce\narp latency\") via neigh_probe() given table lock was held.\n\nOne option to fix this situation is to defer the neigh_probe() back to\nthe neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case\nof NTF_MANAGED, this deferral is acceptable given this only happens on\nactual failure state and regular / expected state is NUD_VALID with the\nentry already present.\n\nThe fix adds a parameter to __neigh_event_send() in order to communicate\nwhether immediate probe is allowed or disallowed. Existing call-sites\nof neigh_event_send() default as-is to immediate probe. However, the\nneigh_managed_work() disables it via use of neigh_event_send_probe().\n\n[0] <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_deadlock_bug kernel/locking/lockdep.c:2956 [inline]\n check_deadlock kernel/locking/lockdep.c:2999 [inline]\n validate_chain kernel/locking/lockdep.c:3788 [inline]\n __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027\n lock_acquire kernel/locking/lockdep.c:5639 [inline]\n lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604\n __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [inline]\n _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334\n ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652\n ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123\n __ip6_finish_output net/ipv6/ip6_output.c:191 [inline]\n __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170\n ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201\n NF_HOOK_COND include/linux/netfilter.h:296 [inline]\n ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224\n dst_output include/net/dst.h:451 [inline]\n NF_HOOK include/linux/netfilter.h:307 [inline]\n ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508\n ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650\n ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c:742\n neigh_probe+0xc2/0x110 net/core/neighbour.c:1040\n __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201\n neigh_event_send include/net/neighbour.h:470 [inline]\n neigh_managed_work+0x162/0x250 net/core/neighbour.c:1574\n process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307\n worker_thread+0x657/0x1110 kernel/workqueue.c:2454\n kthread+0x2e9/0x3a0 kernel/kthread.c:377\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n </TASK>"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net, neigh: no activar sondas inmediatas en NUD_FAILED desde neigh_managed_work syzkaller pudo activar un punto muerto para las entradas NTF_MANAGED [0]: kworker/0:16/14617 est\u00e1 intentando adquirir bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 [...] pero la tarea ya mantiene el bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 La entrada del vecino pas\u00f3 al estado NUD_FAILED, donde __neigh_event_send() desencaden\u00f3 una Sondeo inmediato seg\u00fan el commit cd28ca0a3dd1 (\"relincho: reducir la latencia de arp\") a trav\u00e9s de neigh_probe() dado que se mantuvo el bloqueo de la tabla. Una opci\u00f3n para solucionar esta situaci\u00f3n es posponer neigh_probe() nuevamente a neigh_timer_handler() de manera similar a como se hac\u00eda antes de cd28ca0a3dd1. Para el caso de NTF_MANAGED, este aplazamiento es aceptable dado que esto solo ocurre en el estado de falla real y el estado normal/esperado es NUD_VALID con la entrada ya presente. La soluci\u00f3n agrega un par\u00e1metro a __neigh_event_send() para comunicar si se permite o no la sonda inmediata. Los sitios de llamadas existentes de neigh_event_send() est\u00e1n predeterminados tal cual para la investigaci\u00f3n inmediata. Sin embargo, neigh_managed_work() lo desactiva mediante el uso de neigh_event_send_probe(). [0] __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2956 [en l\u00ednea] check_deadlock kernel/locking/lockdep.c :2999 [en l\u00ednea] validar_chain kernel/locking/lockdep.c:3788 [en l\u00ednea] __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027 lock_acquire kernel/locking/lockdep.c:5639 [en l\u00ednea] lock_acquire+0x1ab /0x510 kernel/locking/lockdep.c:5604 __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [en l\u00ednea] _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334 ___neigh_create+0x9e1/0x2990 net/core/neighbour.c :652 ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123 __ip6_finish_output net/ipv6/ip6_output.c:191 [en l\u00ednea] __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170 poner+0x32/0x200 neto/ ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [en l\u00ednea] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [en l\u00ednea] NF_HOOK include/ linux/netfilter.h:307 [en l\u00ednea] ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508 ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650 ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c :742 neigh_probe+0xc2/0x110 net/core/neighbour.c:1040 __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201 neigh_event_send include/net/neighbour.h:470 [en l\u00ednea] neigh_managed_work+0x162/0x250 net/ core/neighbour.c:1574 Process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307 trabajador_thread+0x657/0x1110 kernel/workqueue.c:2454 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/ x86/entry/entry_64.S:295 "
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48720",
|
"id": "CVE-2022-48720",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.547",
|
"published": "2024-06-20T11:15:55.547",
|
||||||
"lastModified": "2024-06-20T11:15:55.547",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macsec: Fix offload support for NETDEV_UNREGISTER event\n\nCurrent macsec netdev notify handler handles NETDEV_UNREGISTER event by\nreleasing relevant SW resources only, this causes resources leak in case\nof macsec HW offload, as the underlay driver was not notified to clean\nit's macsec offload resources.\n\nFix by calling the underlay driver to clean it's relevant resources\nby moving offload handling from macsec_dellink() to macsec_common_dellink()\nwhen handling NETDEV_UNREGISTER event."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macsec: Fix offload support for NETDEV_UNREGISTER event\n\nCurrent macsec netdev notify handler handles NETDEV_UNREGISTER event by\nreleasing relevant SW resources only, this causes resources leak in case\nof macsec HW offload, as the underlay driver was not notified to clean\nit's macsec offload resources.\n\nFix by calling the underlay driver to clean it's relevant resources\nby moving offload handling from macsec_dellink() to macsec_common_dellink()\nwhen handling NETDEV_UNREGISTER event."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macsec: se corrigi\u00f3 el soporte de descarga para el evento NETDEV_UNREGISTER. El controlador de notificaci\u00f3n netdev de macsec actual maneja el evento NETDEV_UNREGISTER liberando solo recursos SW relevantes, lo que provoca una p\u00e9rdida de recursos en caso de descarga de HW de macsec, ya que No se notific\u00f3 al controlador subyacente que limpiara sus recursos de descarga de macsec. Para solucionarlo, llame al controlador subyacente para limpiar sus recursos relevantes moviendo el manejo de descarga de macsec_dellink() a macsec_common_dellink() cuando se maneja el evento NETDEV_UNREGISTER."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48721",
|
"id": "CVE-2022-48721",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.620",
|
"published": "2024-06-20T11:15:55.620",
|
||||||
"lastModified": "2024-06-20T11:15:55.620",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Forward wakeup to smc socket waitqueue after fallback\n\nWhen we replace TCP with SMC and a fallback occurs, there may be\nsome socket waitqueue entries remaining in smc socket->wq, such\nas eppoll_entries inserted by userspace applications.\n\nAfter the fallback, data flows over TCP/IP and only clcsocket->wq\nwill be woken up. Applications can't be notified by the entries\nwhich were inserted in smc socket->wq before fallback. So we need\na mechanism to wake up smc socket->wq at the same time if some\nentries remaining in it.\n\nThe current workaround is to transfer the entries from smc socket->wq\nto clcsock->wq during the fallback. But this may cause a crash\nlike this:\n\n general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI\n CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107\n RIP: 0010:__wake_up_common+0x65/0x170\n Call Trace:\n <IRQ>\n __wake_up_common_lock+0x7a/0xc0\n sock_def_readable+0x3c/0x70\n tcp_data_queue+0x4a7/0xc40\n tcp_rcv_established+0x32f/0x660\n ? sk_filter_trim_cap+0xcb/0x2e0\n tcp_v4_do_rcv+0x10b/0x260\n tcp_v4_rcv+0xd2a/0xde0\n ip_protocol_deliver_rcu+0x3b/0x1d0\n ip_local_deliver_finish+0x54/0x60\n ip_local_deliver+0x6a/0x110\n ? tcp_v4_early_demux+0xa2/0x140\n ? tcp_v4_early_demux+0x10d/0x140\n ip_sublist_rcv_finish+0x49/0x60\n ip_sublist_rcv+0x19d/0x230\n ip_list_rcv+0x13e/0x170\n __netif_receive_skb_list_core+0x1c2/0x240\n netif_receive_skb_list_internal+0x1e6/0x320\n napi_complete_done+0x11d/0x190\n mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]\n __napi_poll+0x3c/0x1b0\n net_rx_action+0x27c/0x300\n __do_softirq+0x114/0x2d2\n irq_exit_rcu+0xb4/0xe0\n common_interrupt+0xba/0xe0\n </IRQ>\n <TASK>\n\nThe crash is caused by privately transferring waitqueue entries from\nsmc socket->wq to clcsock->wq. The owners of these entries, such as\nepoll, have no idea that the entries have been transferred to a\ndifferent socket wait queue and still use original waitqueue spinlock\n(smc socket->wq.wait.lock) to make the entries operation exclusive,\nbut it doesn't work. The operations to the entries, such as removing\nfrom the waitqueue (now is clcsock->wq after fallback), may cause a\ncrash when clcsock waitqueue is being iterated over at the moment.\n\nThis patch tries to fix this by no longer transferring wait queue\nentries privately, but introducing own implementations of clcsock's\ncallback functions in fallback situation. The callback functions will\nforward the wakeup to smc socket->wq if clcsock->wq is actually woken\nup and smc socket->wq has remaining entries."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Forward wakeup to smc socket waitqueue after fallback\n\nWhen we replace TCP with SMC and a fallback occurs, there may be\nsome socket waitqueue entries remaining in smc socket->wq, such\nas eppoll_entries inserted by userspace applications.\n\nAfter the fallback, data flows over TCP/IP and only clcsocket->wq\nwill be woken up. Applications can't be notified by the entries\nwhich were inserted in smc socket->wq before fallback. So we need\na mechanism to wake up smc socket->wq at the same time if some\nentries remaining in it.\n\nThe current workaround is to transfer the entries from smc socket->wq\nto clcsock->wq during the fallback. But this may cause a crash\nlike this:\n\n general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI\n CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107\n RIP: 0010:__wake_up_common+0x65/0x170\n Call Trace:\n <IRQ>\n __wake_up_common_lock+0x7a/0xc0\n sock_def_readable+0x3c/0x70\n tcp_data_queue+0x4a7/0xc40\n tcp_rcv_established+0x32f/0x660\n ? sk_filter_trim_cap+0xcb/0x2e0\n tcp_v4_do_rcv+0x10b/0x260\n tcp_v4_rcv+0xd2a/0xde0\n ip_protocol_deliver_rcu+0x3b/0x1d0\n ip_local_deliver_finish+0x54/0x60\n ip_local_deliver+0x6a/0x110\n ? tcp_v4_early_demux+0xa2/0x140\n ? tcp_v4_early_demux+0x10d/0x140\n ip_sublist_rcv_finish+0x49/0x60\n ip_sublist_rcv+0x19d/0x230\n ip_list_rcv+0x13e/0x170\n __netif_receive_skb_list_core+0x1c2/0x240\n netif_receive_skb_list_internal+0x1e6/0x320\n napi_complete_done+0x11d/0x190\n mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]\n __napi_poll+0x3c/0x1b0\n net_rx_action+0x27c/0x300\n __do_softirq+0x114/0x2d2\n irq_exit_rcu+0xb4/0xe0\n common_interrupt+0xba/0xe0\n </IRQ>\n <TASK>\n\nThe crash is caused by privately transferring waitqueue entries from\nsmc socket->wq to clcsock->wq. The owners of these entries, such as\nepoll, have no idea that the entries have been transferred to a\ndifferent socket wait queue and still use original waitqueue spinlock\n(smc socket->wq.wait.lock) to make the entries operation exclusive,\nbut it doesn't work. The operations to the entries, such as removing\nfrom the waitqueue (now is clcsock->wq after fallback), may cause a\ncrash when clcsock waitqueue is being iterated over at the moment.\n\nThis patch tries to fix this by no longer transferring wait queue\nentries privately, but introducing own implementations of clcsock's\ncallback functions in fallback situation. The callback functions will\nforward the wakeup to smc socket->wq if clcsock->wq is actually woken\nup and smc socket->wq has remaining entries."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Reenviar activaci\u00f3n a la cola de espera del socket smc despu\u00e9s del respaldo Cuando reemplazamos TCP con SMC y se produce un respaldo, es posible que queden algunas entradas de la cola de espera del socket en el socket smc->wq. como eppoll_entries insertados por aplicaciones de espacio de usuario. Despu\u00e9s del respaldo, los datos fluyen a trav\u00e9s de TCP/IP y solo se activar\u00e1 clcsocket->wq. Las aplicaciones no pueden ser notificadas por las entradas que se insertaron en smc socket->wq antes del respaldo. Entonces necesitamos un mecanismo para activar smc socket->wq al mismo tiempo si quedan algunas entradas en \u00e9l. La soluci\u00f3n actual es transferir las entradas de smc socket->wq a clcsock->wq durante el respaldo. Pero esto puede causar un fallo como este: fallo de protecci\u00f3n general, probablemente para la direcci\u00f3n no can\u00f3nica 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: cargado Contaminado: GE 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Seguimiento de llamadas: __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_establecido+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 0 ? tcp_v4_early_demux+0xa2/0x140? tcp_v4_early_demux+0x10d/0x140 ip_sublist_rcv_finish+0x49/0x60 ip_sublist_rcv+0x19d/0x230 ip_list_rcv+0x13e/0x170 __netif_receive_skb_list_core+0x1c2/0x240 netif_receive_skb_list_ interno+0x1e6/0x320 napi_complete_done+0x11d/0x190 mlx5e_napi_poll+0x163/0x6b0 [mlx5_core] __napi_poll+0x3c/0x1b0 net_rx_action+ 0x27c/0x300 __do_softirq+0x114/0x2d2 irq_exit_rcu+0xb4/0xe0 common_interrupt+0xba/0xe0 El bloqueo se debe a la transferencia privada de entradas de la cola de espera desde smc socket->wq a clcsock->wq. Los propietarios de estas entradas, como epoll, no tienen idea de que las entradas se han transferido a una cola de espera de socket diferente y a\u00fan usan el spinlock de cola de espera original (smc socket->wq.wait.lock) para que la operaci\u00f3n de entradas sea exclusiva, pero no funciona. Las operaciones realizadas en las entradas, como la eliminaci\u00f3n de la cola de espera (ahora es clcsock->wq despu\u00e9s del respaldo), pueden causar un bloqueo cuando se est\u00e1 iterando sobre la cola de espera de clcsock en este momento. Este parche intenta solucionar este problema al no transferir las entradas de la cola de espera de forma privada, sino al introducir implementaciones propias de las funciones de devoluci\u00f3n de llamada de clcsock en situaciones de reserva. Las funciones de devoluci\u00f3n de llamada reenviar\u00e1n la activaci\u00f3n a smc socket->wq si clcsock->wq realmente se activa y smc socket->wq tiene entradas restantes."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48722",
|
"id": "CVE-2022-48722",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.733",
|
"published": "2024-06-20T11:15:55.733",
|
||||||
"lastModified": "2024-06-20T11:15:55.733",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: ca8210: Stop leaking skb's\n\nUpon error the ieee802154_xmit_complete() helper is not called. Only\nieee802154_wake_queue() is called manually. We then leak the skb\nstructure.\n\nFree the skb structure upon error before returning."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: ca8210: Stop leaking skb's\n\nUpon error the ieee802154_xmit_complete() helper is not called. Only\nieee802154_wake_queue() is called manually. We then leak the skb\nstructure.\n\nFree the skb structure upon error before returning."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: net: ieee802154: ca8210: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). S\u00f3lo se llama manualmente a ieee802154_wake_queue(). Luego filtramos la estructura skb. Libere la estructura skb en caso de error antes de regresar."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
@ -2,12 +2,16 @@
|
|||||||
"id": "CVE-2022-48723",
|
"id": "CVE-2022-48723",
|
||||||
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
"published": "2024-06-20T11:15:55.820",
|
"published": "2024-06-20T11:15:55.820",
|
||||||
"lastModified": "2024-06-20T11:15:55.820",
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
"vulnStatus": "Received",
|
"vulnStatus": "Awaiting Analysis",
|
||||||
"descriptions": [
|
"descriptions": [
|
||||||
{
|
{
|
||||||
"lang": "en",
|
"lang": "en",
|
||||||
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: uniphier: fix reference count leak in uniphier_spi_probe()\n\nThe issue happens in several error paths in uniphier_spi_probe().\nWhen either dma_get_slave_caps() or devm_spi_register_master() returns\nan error code, the function forgets to decrease the refcount of both\n`dma_rx` and `dma_tx` objects, which may lead to refcount leaks.\n\nFix it by decrementing the reference count of specific objects in\nthose error paths."
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: uniphier: fix reference count leak in uniphier_spi_probe()\n\nThe issue happens in several error paths in uniphier_spi_probe().\nWhen either dma_get_slave_caps() or devm_spi_register_master() returns\nan error code, the function forgets to decrease the refcount of both\n`dma_rx` and `dma_tx` objects, which may lead to refcount leaks.\n\nFix it by decrementing the reference count of specific objects in\nthose error paths."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"lang": "es",
|
||||||
|
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: spi: uniphier: corrige la fuga del recuento de referencias en uniphier_spi_probe() El problema ocurre en varias rutas de error en uniphier_spi_probe(). Cuando dma_get_slave_caps() o devm_spi_register_master() devuelven un c\u00f3digo de error, la funci\u00f3n se olvida de disminuir el recuento de los objetos `dma_rx` y `dma_tx`, lo que puede provocar fugas de recuento. Corr\u00edjalo disminuyendo el recuento de referencias de objetos espec\u00edficos en esas rutas de error."
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"metrics": {},
|
"metrics": {},
|
||||||
|
|||||||
44
CVE-2022/CVE-2022-487xx/CVE-2022-48724.json
Normal file
44
CVE-2022/CVE-2022-487xx/CVE-2022-48724.json
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48724",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:10.900",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()\n\nAfter commit e3beca48a45b (\"irqdomain/treewide: Keep firmware node\nunconditionally allocated\"). For tear down scenario, fn is only freed\nafter fail to allocate ir_domain, though it also should be freed in case\ndmar_enable_qi returns error.\n\nBesides free fn, irq_domain and ir_msi_domain need to be removed as well\nif intel_setup_irq_remapping fails to enable queued invalidation.\n\nImprove the rewinding path by add out_free_ir_domain and out_free_fwnode\nlables per Baolu's suggestion."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/336d096b62bdc673e852b6b80d5072d7888ce85d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d29ee2d1",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/99e675d473eb8cf2deac1376a0f840222fc1adcf",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9d9995b0371e4e8c18d4f955479e5d47efe7b2d4",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b62eceb5f8f08815fe3f945fc55bbf997c344ecd",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48725.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48725.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48725",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:10.997",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix refcounting leak in siw_create_qp()\n\nThe atomic_inc() needs to be paired with an atomic_dec() on the error\npath."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2989ba9532babac66e79997ccff73c015b69700c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a75badebfdc0b3823054bedf112edb54d6357c75",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fa3b844a50845c817660146c27c0fc29b08d3116",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48726.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48726.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48726",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.077",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Protect mc during concurrent multicast leaves\n\nPartially revert the commit mentioned in the Fixes line to make sure that\nallocation and erasing multicast struct are locked.\n\n BUG: KASAN: use-after-free in ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline]\n BUG: KASAN: use-after-free in ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579\n Read of size 8 at addr ffff88801bb74b00 by task syz-executor.1/25529\n CPU: 0 PID: 25529 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n Call Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247\n __kasan_report mm/kasan/report.c:433 [inline]\n kasan_report.cold+0x83/0xdf mm/kasan/report.c:450\n ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline]\n ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579\n ucma_destroy_id+0x1e6/0x280 drivers/infiniband/core/ucma.c:614\n ucma_write+0x25c/0x350 drivers/infiniband/core/ucma.c:1732\n vfs_write+0x28e/0xae0 fs/read_write.c:588\n ksys_write+0x1ee/0x250 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nCurrently the xarray search can touch a concurrently freeing mc as the\nxa_for_each() is not surrounded by any lock. Rather than hold the lock for\na full scan hold it only for the effected items, which is usually an empty\nlist."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2923948ffe0835f7114e948b35bcc42bc9b3baa1",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/36e8169ec973359f671f9ec7213547059cae972e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ee2477e8ccd3d978eeac0dc5a981b286d9bb7b0a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48727.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48727.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48727",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.167",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Avoid consuming a stale esr value when SError occur\n\nWhen any exception other than an IRQ occurs, the CPU updates the ESR_EL2\nregister with the exception syndrome. An SError may also become pending,\nand will be synchronised by KVM. KVM notes the exception type, and whether\nan SError was synchronised in exit_code.\n\nWhen an exception other than an IRQ occurs, fixup_guest_exit() updates\nvcpu->arch.fault.esr_el2 from the hardware register. When an SError was\nsynchronised, the vcpu esr value is used to determine if the exception\nwas due to an HVC. If so, ELR_EL2 is moved back one instruction. This\nis so that KVM can process the SError first, and re-execute the HVC if\nthe guest survives the SError.\n\nBut if an IRQ synchronises an SError, the vcpu's esr value is stale.\nIf the previous non-IRQ exception was an HVC, KVM will corrupt ELR_EL2,\ncausing an unrelated guest instruction to be executed twice.\n\nCheck ARM_EXCEPTION_CODE() before messing with ELR_EL2, IRQs don't\nupdate this register so don't need to check."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1c71dbc8a179d99dd9bb7e7fc1888db613cf85de",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/57e2986c3b25092691a6e3d6ee9168caf8978932",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e1e852746997500f1873f60b954da5f02cc2dba3",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48728.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48728.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48728",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.253",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix AIP early init panic\n\nAn early failure in hfi1_ipoib_setup_rn() can lead to the following panic:\n\n BUG: unable to handle kernel NULL pointer dereference at 00000000000001b0\n PGD 0 P4D 0\n Oops: 0002 [#1] SMP NOPTI\n Workqueue: events work_for_cpu_fn\n RIP: 0010:try_to_grab_pending+0x2b/0x140\n Code: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 <f0> 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c\n RSP: 0018:ffffb6b3cf7cfa48 EFLAGS: 00010046\n RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000\n RDX: 0000000000000246 RSI: 0000000000000000 RDI: 00000000000001b0\n RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001\n R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000\n R13: ffffb6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690\n FS: 0000000000000000(0000) GS:ffff8a527f400000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000000001b0 CR3: 00000017e2410003 CR4: 00000000007706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n __cancel_work_timer+0x42/0x190\n ? dev_printk_emit+0x4e/0x70\n iowait_cancel_work+0x15/0x30 [hfi1]\n hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1]\n ? dev_err+0x6c/0x90\n hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1]\n hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1]\n rdma_init_netdev+0x5a/0x80 [ib_core]\n ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1]\n ipoib_intf_init+0x6c/0x350 [ib_ipoib]\n ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib]\n ipoib_add_one+0xbe/0x300 [ib_ipoib]\n add_client_context+0x12c/0x1a0 [ib_core]\n enable_device_and_get+0xdc/0x1d0 [ib_core]\n ib_register_device+0x572/0x6b0 [ib_core]\n rvt_register_device+0x11b/0x220 [rdmavt]\n hfi1_register_ib_device+0x6b4/0x770 [hfi1]\n do_init_one.isra.20+0x3e3/0x680 [hfi1]\n local_pci_probe+0x41/0x90\n work_for_cpu_fn+0x16/0x20\n process_one_work+0x1a7/0x360\n ? create_worker+0x1a0/0x1a0\n worker_thread+0x1cf/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x116/0x130\n ? kthread_flush_work_fn+0x10/0x10\n ret_from_fork+0x1f/0x40\n\nThe panic happens in hfi1_ipoib_txreq_deinit() because there is a NULL\nderef when hfi1_ipoib_netdev_dtor() is called in this error case.\n\nhfi1_ipoib_txreq_init() and hfi1_ipoib_rxq_init() are self unwinding so\nfix by adjusting the error paths accordingly.\n\nOther changes:\n- hfi1_ipoib_free_rdma_netdev() is deleted including the free_netdev()\n since the netdev core code deletes calls free_netdev()\n- The switch to the accelerated entrances is moved to the success path."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1899c3cad265c4583658aed5293d02e8af84276b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4a9bd1e6780fc59f81466ec3489d5ad535a37190",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5f8f55b92edd621f056bdf09e572092849fabd83",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a3dd4d2682f2a796121609e5f3bbeb1243198c53",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
24
CVE-2022/CVE-2022-487xx/CVE-2022-48729.json
Normal file
24
CVE-2022/CVE-2022-487xx/CVE-2022-48729.json
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48729",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.343",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix panic with larger ipoib send_queue_size\n\nWhen the ipoib send_queue_size is increased from the default the following\npanic happens:\n\n RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1]\n Code: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 <c7> 83 18 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0\n RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286\n RAX: 0000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\n RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101\n R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200\n R13: ffffc9000798fba8 R14: 0000000000000000 R15: 0000000000000001\n FS: 00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffc9000aa0f118 CR3: 0000000889c84001 CR4: 00000000001706e0\n Call Trace:\n <TASK>\n hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1]\n hfi1_ipoib_dev_stop+0x18/0x80 [hfi1]\n ipoib_ib_dev_stop+0x1d/0x40 [ib_ipoib]\n ipoib_stop+0x48/0xc0 [ib_ipoib]\n __dev_close_many+0x9e/0x110\n __dev_change_flags+0xd9/0x210\n dev_change_flags+0x21/0x60\n do_setlink+0x31c/0x10f0\n ? __nla_validate_parse+0x12d/0x1a0\n ? __nla_parse+0x21/0x30\n ? inet6_validate_link_af+0x5e/0xf0\n ? cpumask_next+0x1f/0x20\n ? __snmp6_fill_stats64.isra.53+0xbb/0x140\n ? __nla_validate_parse+0x47/0x1a0\n __rtnl_newlink+0x530/0x910\n ? pskb_expand_head+0x73/0x300\n ? __kmalloc_node_track_caller+0x109/0x280\n ? __nla_put+0xc/0x20\n ? cpumask_next_and+0x20/0x30\n ? update_sd_lb_stats.constprop.144+0xd3/0x820\n ? _raw_spin_unlock_irqrestore+0x25/0x37\n ? __wake_up_common_lock+0x87/0xc0\n ? kmem_cache_alloc_trace+0x3d/0x3d0\n rtnl_newlink+0x43/0x60\n\nThe issue happens when the shift that should have been a function of the\ntxq item size mistakenly used the ring size.\n\nFix by using the item size."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1530d84fba1e459ba55f46aa42649b88773210e7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/8c83d39cc730378bbac64d67a551897b203a606e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48730.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48730.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48730",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.430",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: heaps: Fix potential spectre v1 gadget\n\nIt appears like nr could be a Spectre v1 gadget as it's supplied by a\nuser and used as an array index. Prevent the contents\nof kernel memory from being leaked to userspace via speculative\nexecution by using array_index_nospec.\n\n [sumits: added fixes and cc: stable tags]"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/24f8e12d965b24f8aea762589e0e9fe2025c005e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5d40f1bdad3dd1a177f21a90ad4353c1ed40ba3a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/92c4cfaee6872038563c5b6f2e8e613f9d84d47d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cc8f7940d9c2d45f67b3d1a2f2b7a829ca561bed",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
36
CVE-2022/CVE-2022-487xx/CVE-2022-48731.json
Normal file
36
CVE-2022/CVE-2022-487xx/CVE-2022-48731.json
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48731",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.517",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid scanning potential huge holes\n\nWhen using devm_request_free_mem_region() and devm_memremap_pages() to\nadd ZONE_DEVICE memory, if requested free mem region's end pfn were\nhuge(e.g., 0x400000000), the node_end_pfn() will be also huge (see\nmove_pfn_range_to_zone()). Thus it creates a huge hole between\nnode_start_pfn() and node_end_pfn().\n\nWe found on some AMD APUs, amdkfd requested such a free mem region and\ncreated a huge hole. In such a case, following code snippet was just\ndoing busy test_bit() looping on the huge hole.\n\n for (pfn = start_pfn; pfn < end_pfn; pfn++) {\n\tstruct page *page = pfn_to_online_page(pfn);\n\t\tif (!page)\n\t\t\tcontinue;\n\t...\n }\n\nSo we got a soft lockup:\n\n watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221]\n CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1\n RIP: 0010:pfn_to_online_page+0x5/0xd0\n Call Trace:\n ? kmemleak_scan+0x16a/0x440\n kmemleak_write+0x306/0x3a0\n ? common_file_perm+0x72/0x170\n full_proxy_write+0x5c/0x90\n vfs_write+0xb9/0x260\n ksys_write+0x67/0xe0\n __x64_sys_write+0x1a/0x20\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nI did some tests with the patch.\n\n(1) amdgpu module unloaded\n\nbefore the patch:\n\n real 0m0.976s\n user 0m0.000s\n sys 0m0.968s\n\nafter the patch:\n\n real 0m0.981s\n user 0m0.000s\n sys 0m0.973s\n\n(2) amdgpu module loaded\n\nbefore the patch:\n\n real 0m35.365s\n user 0m0.000s\n sys 0m35.354s\n\nafter the patch:\n\n real 0m1.049s\n user 0m0.000s\n sys 0m1.042s"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48732.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48732.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48732",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.607",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix off by one in BIOS boundary checking\n\nBounds checking when parsing init scripts embedded in the BIOS reject\naccess to the last byte. This causes driver initialization to fail on\nApple eMac's with GeForce 2 MX GPUs, leaving the system with no working\nconsole.\n\nThis is probably only seen on OpenFirmware machines like PowerPC Macs\nbecause the BIOS image provided by OF is only the used parts of the ROM,\nnot a power-of-two blocks read from PCI directly so PCs always have\nempty bytes at the end that are never accessed."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/909d3ec1bf9f0ec534bfc081b77c0836fea7b0e2",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/acc887ba88333f5fec49631f12d8cc7ebd95781c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b2a21669ee98aafc41c6d42ef15af4dab9e6e882",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/d4b746e60fd8eaa8016e144223abe91158edcdad",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/d877e814a62b7de9069aeff8bc1d979dfc996e06",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e7c36fa8a1e63b08312162179c78a0c7795ea369",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48733.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48733.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48733",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.700",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free after failure to create a snapshot\n\nAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure and\nthen attach it to the transaction's list of pending snapshots. After that\nwe call btrfs_commit_transaction(), and if that returns an error we jump\nto 'fail' label, where we kfree() the pending snapshot structure. This can\nresult in a later use-after-free of the pending snapshot:\n\n1) We allocated the pending snapshot and added it to the transaction's\n list of pending snapshots;\n\n2) We call btrfs_commit_transaction(), and it fails either at the first\n call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().\n In both cases, we don't abort the transaction and we release our\n transaction handle. We jump to the 'fail' label and free the pending\n snapshot structure. We return with the pending snapshot still in the\n transaction's list;\n\n3) Another task commits the transaction. This time there's no error at\n all, and then during the transaction commit it accesses a pointer\n to the pending snapshot structure that the snapshot creation task\n has already freed, resulting in a user-after-free.\n\nThis issue could actually be detected by smatch, which produced the\nfollowing warning:\n\n fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list\n\nSo fix this by not having the snapshot creation ioctl directly add the\npending snapshot to the transaction's list. Instead add the pending\nsnapshot to the transaction handle, and then at btrfs_commit_transaction()\nwe add the snapshot to the list only when we can guarantee that any error\nreturned after that point will result in a transaction abort, in which\ncase the ioctl code can safely free the pending snapshot and no one can\naccess it anymore."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/28b21c558a3753171097193b6f6602a94169093a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9372fa1d73da5f1673921e365d0cd2c27ec7adc2",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a7b717fa15165d3d9245614680bebc48a52ac05d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
36
CVE-2022/CVE-2022-487xx/CVE-2022-48734.json
Normal file
36
CVE-2022/CVE-2022-487xx/CVE-2022-48734.json
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48734",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.797",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between quota disable and qgroup rescan worker\n\nQuota disable ioctl starts a transaction before waiting for the qgroup\nrescan worker completes. However, this wait can be infinite and results\nin deadlock because of circular dependency among the quota disable\nioctl, the qgroup rescan worker and the other task with transaction such\nas block group relocation task.\n\nThe deadlock happens with the steps following:\n\n1) Task A calls ioctl to disable quota. It starts a transaction and\n waits for qgroup rescan worker completes.\n2) Task B such as block group relocation task starts a transaction and\n joins to the transaction that task A started. Then task B commits to\n the transaction. In this commit, task B waits for a commit by task A.\n3) Task C as the qgroup rescan worker starts its job and starts a\n transaction. In this transaction start, task C waits for completion\n of the transaction that task A started and task B committed.\n\nThis deadlock was found with fstests test case btrfs/115 and a zoned\nnull_blk device. The test case enables and disables quota, and the\nblock group reclaim was triggered during the quota disable by chance.\nThe deadlock was also observed by running quota enable and disable in\nparallel with 'btrfs balance' command on regular null_blk devices.\n\nAn example report of the deadlock:\n\n [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds.\n [372.479944] Not tainted 5.16.0-rc8 #7\n [372.485067] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000\n [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs]\n [372.510782] Call Trace:\n [372.514092] <TASK>\n [372.521684] __schedule+0xb56/0x4850\n [372.530104] ? io_schedule_timeout+0x190/0x190\n [372.538842] ? lockdep_hardirqs_on+0x7e/0x100\n [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60\n [372.555591] schedule+0xe0/0x270\n [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs]\n [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs]\n [372.578875] ? free_unref_page+0x3f2/0x650\n [372.585484] ? finish_wait+0x270/0x270\n [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs]\n [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs]\n [372.607157] ? lock_release+0x3a9/0x6d0\n [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs]\n [372.620960] ? do_raw_spin_lock+0x11e/0x250\n [372.627137] ? rwlock_bug.part.0+0x90/0x90\n [372.633215] ? lock_is_held_type+0xe4/0x140\n [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs]\n [372.646268] process_one_work+0x7e9/0x1320\n [372.652321] ? lock_release+0x6d0/0x6d0\n [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230\n [372.664513] ? rwlock_bug.part.0+0x90/0x90\n [372.670529] worker_thread+0x59e/0xf90\n [372.676172] ? process_one_work+0x1320/0x1320\n [372.682440] kthread+0x3b9/0x490\n [372.687550] ? _raw_spin_unlock_irq+0x24/0x50\n [372.693811] ? set_kthread_struct+0x100/0x100\n [372.700052] ret_from_fork+0x22/0x30\n [372.705517] </TASK>\n [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds.\n [372.729827] Not tainted 5.16.0-rc8 #7\n [372.745907] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000\n [372.787776] Call Trace:\n [372.801652] <TASK>\n [372.812961] __schedule+0xb56/0x4850\n [372.830011] ? io_schedule_timeout+0x190/0x190\n [372.852547] ? lockdep_hardirqs_on+0x7e/0x100\n [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60\n [372.886792] schedule+0xe0/0x270\n [372.901685] wait_current_trans+0x22c/0x310 [btrfs]\n [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs]\n [372.938923] ? finish_wait+0x270/0x270\n [372.959085] ? join_transaction+0xc7\n---truncated---"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48735.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48735.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48735",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.890",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: Fix UAF of leds class devs at unbinding\n\nThe LED class devices that are created by HD-audio codec drivers are\nregistered via devm_led_classdev_register() and associated with the\nHD-audio codec device. Unfortunately, it turned out that the devres\nrelease doesn't work for this case; namely, since the codec resource\nrelease happens before the devm call chain, it triggers a NULL\ndereference or a UAF for a stale set_brightness_delay callback.\n\nFor fixing the bug, this patch changes the LED class device register\nand unregister in a manual manner without devres, keeping the\ninstances in hda_gen_spec."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/0e629052f013eeb61494d4df2f1f647c2a9aef47",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/549f8ffc7b2f7561bea7f90930b6c5104318e87b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/813e9f3e06d22e29872d4fd51b54992d89cf66c8",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a7de1002135cf94367748ffc695a29812d7633b5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48736.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48736.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48736",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:11.973",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx()\n\nWe don't currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/17e16a66b4f9a310713d8599e6e1ca4a0c9fd28c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4cf28e9ae6e2e11a044be1bcbcfa1b0d8675fe4d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/54abca038e287d3746dd40016514670a7f654c5c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/6877f87579ed830f9ff6d478539074f035d04bfb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/7659f25a80e6affb784b690df8994b79b4212fd4",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b0a7836ecf1345814a7d8ef748fb797c520dad18",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e09cf398e8c6db69c620b6d8073abc4377a07af5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fd9a23319f16e7031f0d8c98eed6e093c2927229",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48737.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48737.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48737",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.060",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()\n\nWe don't currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/038f8b7caa74d29e020949a43ca368c93f6b29b9",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4977491e4b3aad8567f57e2a9992d251410c1db3",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4f1e50d6a9cf9c1b8c859d449b5031cacfa8404e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9a12fcbf3c622f9bf6b110a873d62b0cba93972e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9e5c40b5706d8aae2cf70bd7e01f0b4575a642d0",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c33402b056de61104b6146dedbe138ca8d7ec62b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e8e07c5e25a29e2a6f119fd947f55d7a55eb8a13",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ef6cd9eeb38062a145802b7b56be7ae1090e165e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48738.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48738.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48738",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.150",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw()\n\nWe don't currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/40f598698129b5ceaf31012f9501b775c7b6e57d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/586ef863c94354a7e00e5ae5ef01443d1dc99bc7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/65a61b1f56f5386486757930069fbdce94af08bf",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/68fd718724284788fc5f379e0b7cac541429ece7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/817f7c9335ec01e0f5e8caffc4f1dcd5e458a4c0",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9e8895f1b3d4433f6d78aa6578e9db61ca6e6830",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a9394f21fba027147bf275b083c77955864c366a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/bb72d2dda85564c66d909108ea6903937a41679d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48739.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48739.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48739",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.243",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: hdmi-codec: Fix OOB memory accesses\n\nCorrect size of iec_status array by changing it to the size of status\narray of the struct snd_aes_iec958. This fixes out-of-bounds slab\nread accesses made by memcpy() of the hdmi-codec driver. This problem\nis reported by KASAN."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/06feec6005c9d9500cd286ec440aabf8b2ddd94d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1552e66be325a21d7eff49f46013fb402165a0ac",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48740.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48740.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48740",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.330",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nselinux: fix double free of cond_list on error paths\n\nOn error path from cond_read_list() and duplicate_policydb_cond_list()\nthe cond_list_destroy() gets called a second time in caller functions,\nresulting in NULL pointer deref. Fix this by resetting the\ncond_list_len to 0 in cond_list_destroy(), making subsequent calls a\nnoop.\n\nAlso consistently reset the cond_list pointer to NULL after freeing.\n\n[PM: fix line lengths in the description]"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/186edf7e368c40d06cf727a1ad14698ea67b74ad",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48741.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48741.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48741",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.430",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix NULL pointer dereference in copy up warning\n\nThis patch is fixing a NULL pointer dereference to get a recently\nintroduced warning message working."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4ee7e4a6c9b298da44029ed9ec8ed23ae49cc209",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9c7f8a35c5a83740c0e3ea540b6ad145c50d79aa",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e6b678c1a3673de6a5d2f4e22bb725a086a0701a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48742.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48742.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48742",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.517",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()\n\nWhile looking at one unrelated syzbot bug, I found the replay logic\nin __rtnl_newlink() to potentially trigger use-after-free.\n\nIt is better to clear master_dev and m_ops inside the loop,\nin case we have to replay it."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401b23f210",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c6f6f2444bdbe0079e41914a35081530d0409963",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
48
CVE-2022/CVE-2022-487xx/CVE-2022-48743.json
Normal file
48
CVE-2022/CVE-2022-487xx/CVE-2022-48743.json
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48743",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.610",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: amd-xgbe: Fix skb data length underflow\n\nThere will be BUG_ON() triggered in include/linux/skbuff.h leading to\nintermittent kernel panic, when the skb length underflow is detected.\n\nFix this by dropping the packet if such length underflows are seen\nbecause of inconsistencies in the hardware descriptors."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4d3fcfe8464838b3920bc2b939d888e0b792934e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5aac9108a180fc06e28d4e7fb00247ce603b72ee",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486db89576",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/db6fd92316a254be2097556f01bccecf560e53ce",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e8f73f620fee5f52653ed2da360121e4446575c5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
24
CVE-2022/CVE-2022-487xx/CVE-2022-48744.json
Normal file
24
CVE-2022/CVE-2022-487xx/CVE-2022-48744.json
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48744",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.700",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid field-overflowing memcpy()\n\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\n\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\n\nWe were doing:\n\n\t#define ETH_HLEN 14\n\t#define VLAN_HLEN 4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n struct mlx5_wqe_eth_seg *eseg = &wqe->eth;\n struct mlx5_wqe_data_seg *dseg = wqe->data;\n\t...\n\tmemcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);\n\ntarget is wqe->eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\n\nstruct mlx5e_tx_wqe {\n struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */\n struct mlx5_wqe_eth_seg eth; /* 16 16 */\n struct mlx5_wqe_data_seg data[]; /* 32 0 */\n\n /* size: 32, cachelines: 1, members: 3 */\n /* last cacheline: 32 bytes */\n};\n\nstruct mlx5_wqe_eth_seg {\n u8 swp_outer_l4_offset; /* 0 1 */\n u8 swp_outer_l3_offset; /* 1 1 */\n u8 swp_inner_l4_offset; /* 2 1 */\n u8 swp_inner_l3_offset; /* 3 1 */\n u8 cs_flags; /* 4 1 */\n u8 swp_flags; /* 5 1 */\n __be16 mss; /* 6 2 */\n __be32 flow_table_metadata; /* 8 4 */\n union {\n struct {\n __be16 sz; /* 12 2 */\n u8 start[2]; /* 14 2 */\n } inline_hdr; /* 12 4 */\n struct {\n __be16 type; /* 12 2 */\n __be16 vlan_tci; /* 14 2 */\n } insert; /* 12 4 */\n __be32 trailer; /* 12 4 */\n }; /* 12 4 */\n\n /* size: 16, cachelines: 1, members: 9 */\n /* last cacheline: 16 bytes */\n};\n\nstruct mlx5_wqe_data_seg {\n __be32 byte_count; /* 0 4 */\n __be32 lkey; /* 4 4 */\n __be64 addr; /* 8 8 */\n\n /* size: 16, cachelines: 1, members: 3 */\n /* last cacheline: 16 bytes */\n};\n\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\n\n\"pahole\" shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \"objdump -d\" shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations)."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48745.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48745.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48745",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.783",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Use del_timer_sync in fw reset flow of halting poll\n\nSubstitute del_timer() with del_timer_sync() in fw reset polling\ndeactivation flow, in order to prevent a race condition which occurs\nwhen del_timer() is called and timer is deactivated while another\nprocess is handling the timer interrupt. A situation that led to\nthe following call trace:\n\tRIP: 0010:run_timer_softirq+0x137/0x420\n\t<IRQ>\n\trecalibrate_cpu_khz+0x10/0x10\n\tktime_get+0x3e/0xa0\n\t? sched_clock_cpu+0xb/0xc0\n\t__do_softirq+0xf5/0x2ea\n\tirq_exit_rcu+0xc1/0xf0\n\tsysvec_apic_timer_interrupt+0x9e/0xc0\n\tasm_sysvec_apic_timer_interrupt+0x12/0x20\n\t</IRQ>"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2a038dd1d942f8fbc495c58fa592ff24af05f1c2",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3c5193a87b0fea090aa3f769d020337662d87b5e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/502c37b033fab7cde3e95a570af4f073306be45e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/f895ebeb44d09d02674cfdd0cfc2bf687603918c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48746.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48746.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48746",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.870",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix handling of wrong devices during bond netevent\n\nCurrent implementation of bond netevent handler only check if\nthe handled netdev is VF representor and it missing a check if\nthe VF representor is on the same phys device of the bond handling\nthe netevent.\n\nFix by adding the missing check and optimizing the check if\nthe netdev is VF representor so it will not access uninitialized\nprivate data and crashes.\n\nBUG: kernel NULL pointer dereference, address: 000000000000036c\nPGD 0 P4D 0\nOops: 0000 [#1] SMP NOPTI\nWorkqueue: eth3bond0 bond_mii_monitor [bonding]\nRIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core]\nRSP: 0018:ffff88812d69fd60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000\nRDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880\nRBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008\nR10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10\nR13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core]\n mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core]\n mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core]\n raw_notifier_call_chain+0x41/0x60\n call_netdevice_notifiers_info+0x34/0x80\n netdev_lower_state_changed+0x4e/0xa0\n bond_mii_monitor+0x56b/0x640 [bonding]\n process_one_work+0x1b9/0x390\n worker_thread+0x4d/0x3d0\n ? rescuer_thread+0x350/0x350\n kthread+0x124/0x150\n ? set_kthread_struct+0x40/0x40\n ret_from_fork+0x1f/0x30"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4fad499d7fece448e7230d5e5b92f6d8a073e0bb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/a01ee1b8165f4161459b5ec4e728bc7130fe8cd4",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ec41332e02bd0acf1f24206867bb6a02f5877a62",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fe70126da6063c29ca161cdec7ad1dae9af836b3",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
36
CVE-2022/CVE-2022-487xx/CVE-2022-48747.json
Normal file
36
CVE-2022/CVE-2022-487xx/CVE-2022-48747.json
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48747",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:12.960",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix wrong offset in bio_truncate()\n\nbio_truncate() clears the buffer outside of last block of bdev, however\ncurrent bio_truncate() is using the wrong offset of page. So it can\nreturn the uninitialized data.\n\nThis happened when both of truncated/corrupted FS and userspace (via\nbdev) are trying to read the last of bdev."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48748.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48748.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48748",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.047",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: vlan: fix memory leak in __allowed_ingress\n\nWhen using per-vlan state, if vlan snooping and stats are disabled,\nuntagged or priority-tagged ingress frame will go to check pvid state.\nIf the port state is forwarding and the pvid state is not\nlearning/forwarding, untagged or priority-tagged frame will be dropped\nbut skb memory is not freed.\nShould free skb when __allowed_ingress returns false."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/14be8d448fca6fe7b2a413831eedd55aef6c6511",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/446ff1fc37c74093e81db40811a07b5a19f1d797",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c5e216e880fa6f2cd9d4a6541269377657163098",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fd20d9738395cf8e27d0a17eba34169699fccdff",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48749.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48749.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48749",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.143",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc\n\nThe function performs a check on the \"ctx\" input parameter, however, it\nis used before the check.\n\nInitialize the \"base\" variable after the sanity check to avoid a\npossible NULL pointer dereference.\n\nAddresses-Coverity-ID: 1493866 (\"Null pointer dereference\")"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/170b22234d5495f5e0844246e23f004639ee89ba",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1ebc18836d5df09061657f8c548e594cbb519476",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/8f069f6dde518dfebe86e848508c07e497bd9298",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/93a6e920d8ccb4df846c03b6e72f7e08843d294c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
24
CVE-2022/CVE-2022-487xx/CVE-2022-48750.json
Normal file
24
CVE-2022/CVE-2022-487xx/CVE-2022-48750.json
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48750",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.223",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (nct6775) Fix crash in clear_caseopen\n\nPawe? Marciniak reports the following crash, observed when clearing\nthe chassis intrusion alarm.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000028\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 3 PID: 4815 Comm: bash Tainted: G S 5.16.2-200.fc35.x86_64 #1\nHardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.60A 05/03/2018\nRIP: 0010:clear_caseopen+0x5a/0x120 [nct6775]\nCode: 68 70 e8 e9 32 b1 e3 85 c0 0f 85 d2 00 00 00 48 83 7c 24 ...\nRSP: 0018:ffffabcb02803dd8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000\nRDX: ffff8e8808192880 RSI: 0000000000000000 RDI: ffff8e87c7509a68\nRBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000a\nR10: 000000000000000a R11: f000000000000000 R12: 000000000000001f\nR13: ffff8e87c7509828 R14: ffff8e87c7509a68 R15: ffff8e88494527a0\nFS: 00007f4db9151740(0000) GS:ffff8e8ebfec0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000166b66001 CR4: 00000000001706e0\nCall Trace:\n <TASK>\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x10b/0x180\n vfs_write+0x209/0x2a0\n ksys_write+0x4f/0xc0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe problem is that the device passed to clear_caseopen() is the hwmon\ndevice, not the platform device, and the platform data is not set in the\nhwmon device. Store the pointer to sio_data in struct nct6775_data and\nget if from there if needed."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/79da533d3cc717ccc05ddbd3190da8a72bc2408b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cfb7d12f2e4a4d694f49e9b4ebb352f7b67cdfbb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
28
CVE-2022/CVE-2022-487xx/CVE-2022-48751.json
Normal file
28
CVE-2022/CVE-2022-487xx/CVE-2022-48751.json
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48751",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.310",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Transitional solution for clcsock race issue\n\nWe encountered a crash in smc_setsockopt() and it is caused by\naccessing smc->clcsock after clcsock was released.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000020\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 PTI\n CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53\n RIP: 0010:smc_setsockopt+0x59/0x280 [smc]\n Call Trace:\n <TASK>\n __sys_setsockopt+0xfc/0x190\n __x64_sys_setsockopt+0x20/0x30\n do_syscall_64+0x34/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f16ba83918e\n </TASK>\n\nThis patch tries to fix it by holding clcsock_release_lock and\nchecking whether clcsock has already been released before access.\n\nIn case that a crash of the same reason happens in smc_getsockopt()\nor smc_switch_to_fallback(), this patch also checkes smc->clcsock\nin them too. And the caller of smc_switch_to_fallback() will identify\nwhether fallback succeeds according to the return value."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/38f0bdd548fd2ef5d481b88d8a2bfef968452e34",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/4284225cd8001e134f5cf533a7cd244bbb654d0f",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48752.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48752.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48752",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.397",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending\n\nRunning selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel\ntriggered below warning:\n\n[ 172.851380] ------------[ cut here ]------------\n[ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280\n[ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse\n[ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2\n[ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180\n[ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5-03218-g798527287598)\n[ 172.851465] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48004884 XER: 20040000\n[ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1\n[ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004\n[ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000\n[ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68\n[ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000\n[ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0\n[ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003\n[ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600\n[ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8\n[ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280\n[ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280\n[ 172.851565] Call Trace:\n[ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)\n[ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60\n[ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660\n[ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0\n[ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140\n[ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40\n[ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380\n[ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268\n\nThe warning indicates that MSR_EE being set(interrupt enabled) when\nthere was an overflown PMC detected. This could happen in\npower_pmu_disable since it runs under interrupt soft disable\ncondition ( local_irq_save ) and not with interrupts hard disabled.\ncommit 2c9ac51b850d (\"powerpc/perf: Fix PMU callbacks to clear\npending PMI before resetting an overflown PMC\") intended to clear\nPMI pending bit in Paca when disabling the PMU. It could happen\nthat PMC gets overflown while code is in power_pmu_disable\ncallback function. Hence add a check to see if PMI pending bit\nis set in Paca before clearing it via clear_pmi_pending."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/28aaed966e76807a71de79dd40a8eee9042374dd",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/55402a4618721f350a9ab660bb42717d8aa18e7c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fa4ad064a6bd49208221df5e62adf27b426d1720",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fb6433b48a178d4672cb26632454ee0b21056eaa",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
24
CVE-2022/CVE-2022-487xx/CVE-2022-48753.json
Normal file
24
CVE-2022/CVE-2022-487xx/CVE-2022-48753.json
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48753",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.480",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix memory leak in disk_register_independent_access_ranges\n\nkobject_init_and_add() takes reference even when it fails.\nAccording to the doc of kobject_init_and_add()\n\n If this function returns an error, kobject_put() must be called to\n properly clean up the memory associated with the object.\n\nFix this issue by adding kobject_put().\nCallback function blk_ia_ranges_sysfs_release() in kobject_put()\ncan handle the pointer \"iars\" properly."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/83114df32ae779df57e0af99a8ba6c3968b2ba3d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/fe4214a07e0b53d2af711f57519e33739c5df23f",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
40
CVE-2022/CVE-2022-487xx/CVE-2022-48754.json
Normal file
40
CVE-2022/CVE-2022-487xx/CVE-2022-48754.json
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48754",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.563",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nphylib: fix potential use-after-free\n\nCommit bafbdd527d56 (\"phylib: Add device reset GPIO support\") added call\nto phy_device_reset(phydev) after the put_device() call in phy_detach().\n\nThe comment before the put_device() call says that the phydev might go\naway with put_device().\n\nFix potential use-after-free by calling phy_device_reset() before\nput_device()."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/67d271760b037ce0806d687ee6057edc8afd4205",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/aefaccd19379d6c4620269a162bfb88ff687f289",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/bd024e36f68174b1793906c39ca16cee0c9295c2",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cb2fab10fc5e7a3aa1bb0a68a3abdcf3e37852af",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/cbda1b16687580d5beee38273f6241ae3725960c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/f39027cbada43b33566c312e6be3db654ca3ad17",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48755.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48755.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48755",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.653",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06\n\nJohan reported the below crash with test_bpf on ppc64 e5500:\n\n test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1\n Oops: Exception in kernel mode, sig: 4 [#1]\n BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500\n Modules linked in: test_bpf(+)\n CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1\n NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18\n REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty)\n MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0\n <...>\n NIP [8000000000061c3c] 0x8000000000061c3c\n LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]\n Call Trace:\n .__run_one+0x60/0x17c [test_bpf] (unreliable)\n .test_bpf_init+0x6a8/0xdc8 [test_bpf]\n .do_one_initcall+0x6c/0x28c\n .do_init_module+0x68/0x28c\n .load_module+0x2460/0x2abc\n .__do_sys_init_module+0x120/0x18c\n .system_call_exception+0x110/0x1b8\n system_call_common+0xf0/0x210\n --- interrupt: c00 at 0x101d0acc\n <...>\n ---[ end trace 47b2bf19090bb3d0 ]---\n\n Illegal instruction\n\nThe illegal instruction turned out to be 'ldbrx' emitted for\nBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of\nthe same and implement an alternative approach for older processors."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/129c71829d7f46423d95c19e8d87ce956d4c6e1c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3bfbc00587dc883eaed383558ae512a351c2cd09",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3f5f766d5f7f95a69a630da3544a1a0cee1cdddf",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/aaccfeeee1630b155e8ff0d6c449d3de1ef86e73",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
44
CVE-2022/CVE-2022-487xx/CVE-2022-48756.json
Normal file
44
CVE-2022/CVE-2022-487xx/CVE-2022-48756.json
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48756",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.740",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dsi: invalid parameter check in msm_dsi_phy_enable\n\nThe function performs a check on the \"phy\" input parameter, however, it\nis used before the check.\n\nInitialize the \"dev\" variable after the sanity check to avoid a possible\nNULL pointer dereference.\n\nAddresses-Coverity-ID: 1493860 (\"Null pointer dereference\")"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2b7e7df1eacd280e561ede3e977853606871c951",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103bcd775c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
52
CVE-2022/CVE-2022-487xx/CVE-2022-48757.json
Normal file
52
CVE-2022/CVE-2022-487xx/CVE-2022-48757.json
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48757",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.823",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix information leakage in /proc/net/ptype\n\nIn one net namespace, after creating a packet socket without binding\nit to a device, users in other net namespaces can observe the new\n`packet_type` added by this packet socket by reading `/proc/net/ptype`\nfile. This is minor information leakage as packet socket is\nnamespace aware.\n\nAdd a net pointer in `packet_type` to keep the net namespace of\nof corresponding packet socket. In `ptype_seq_show`, this net pointer\nmust be checked when it is not NULL."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/47934e06b65637c88a762d9c98329ae6e3238888",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/839ec7039513a4f84bfbaff953a9393471176bee",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/8f88c78d24f6f346919007cd459fd7e51a8c7779",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b67ad6170c0ea87391bb253f35d1f78857736e54",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/be1ca30331c7923c6f376610c1bd6059be9b1908",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c38023032a598ec6263e008d62c7f02def72d5c7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/db044d97460ea792110eb8b971e82569ded536c6",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e372ecd455b6ebc7720f52bf4b5f5d44d02f2092",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e43669c77cb3a742b7d84ecdc7c68c4167a7709b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
52
CVE-2022/CVE-2022-487xx/CVE-2022-48758.json
Normal file
52
CVE-2022/CVE-2022-487xx/CVE-2022-48758.json
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48758",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:13.927",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()\n\nThe bnx2fc_destroy() functions are removing the interface before calling\ndestroy_work. This results multiple WARNings from sysfs_remove_group() as\nthe controller rport device attributes are removed too early.\n\nReplace the fcoe_port's destroy_work queue. It's not needed.\n\nThe problem is easily reproducible with the following steps.\n\nExample:\n\n $ dmesg -w &\n $ systemctl enable --now fcoe\n $ fipvlan -s -c ens2f1\n $ fcoeadm -d ens2f1.802\n [ 583.464488] host2: libfc: Link down on port (7500a1)\n [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!!\n [ 583.490468] ------------[ cut here ]------------\n [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'\n [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80\n [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...\n [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1\n [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013\n [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]\n [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80\n [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...\n [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282\n [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000\n [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0\n [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00\n [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400\n [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004\n [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000\n [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0\n [ 584.454888] Call Trace:\n [ 584.466108] device_del+0xb2/0x3e0\n [ 584.481701] device_unregister+0x13/0x60\n [ 584.501306] bsg_unregister_queue+0x5b/0x80\n [ 584.522029] bsg_remove_queue+0x1c/0x40\n [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]\n [ 584.573823] process_one_work+0x1e3/0x3b0\n [ 584.592396] worker_thread+0x50/0x3b0\n [ 584.609256] ? rescuer_thread+0x370/0x370\n [ 584.628877] kthread+0x149/0x170\n [ 584.643673] ? set_kthread_struct+0x40/0x40\n [ 584.662909] ret_from_fork+0x22/0x30\n [ 584.680002] ---[ end trace 53575ecefa942ece ]---"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/00849de10f798a9538242824a51b1756e7110754",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/262550f29c750f7876b6ed1244281e72b64ebffb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/2a12fe8248a38437b95b942bbe85aced72e6e2eb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/847f9ea4c5186fdb7b84297e3eeed9e340e83fce",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/ace7b6ef41251c5fe47f629a9a922382fb7b0a6b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b11e34f7bab21df36f02a5e54fb69e858c09a65d",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/bf2bd892a0cb14dd2d21f2c658f4b747813be311",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c93a290c862ccfa404e42d7420565730d67cbff9",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/de6336b17a1376db1c0f7a528cce8783db0881c0",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
44
CVE-2022/CVE-2022-487xx/CVE-2022-48759.json
Normal file
44
CVE-2022/CVE-2022-487xx/CVE-2022-48759.json
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48759",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:14.023",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev\n\nstruct rpmsg_ctrldev contains a struct cdev. The current code frees\nthe rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the\ncdev is a managed object, therefore its release is not predictable\nand the rpmsg_ctrldev could be freed before the cdev is entirely\nreleased, as in the backtrace below.\n\n[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c\n[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0\n[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v\n[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26\n[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)\n[ 93.730055] Workqueue: events kobject_delayed_cleanup\n[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)\n[ 93.740216] pc : debug_print_object+0x13c/0x1b0\n[ 93.744890] lr : debug_print_object+0x13c/0x1b0\n[ 93.749555] sp : ffffffacf5bc7940\n[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000\n[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000\n[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000\n[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0\n[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0\n[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0\n[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000\n[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c\n[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000\n[ 93.802244] x11: 0000000000000001 x10: 0000000000000000\n[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900\n[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000\n[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000\n[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001\n[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061\n[ 93.835104] Call trace:\n[ 93.837644] debug_print_object+0x13c/0x1b0\n[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0\n[ 93.846987] debug_check_no_obj_freed+0x18/0x20\n[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4\n[ 93.856346] kfree+0xfc/0x2f4\n[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8\n[ 93.864445] device_release+0x84/0x168\n[ 93.868310] kobject_cleanup+0x12c/0x298\n[ 93.872356] kobject_delayed_cleanup+0x10/0x18\n[ 93.876948] process_one_work+0x578/0x92c\n[ 93.881086] worker_thread+0x804/0xcf8\n[ 93.884963] kthread+0x2a8/0x314\n[ 93.888303] ret_from_fork+0x10/0x18\n\nThe cdev_device_add/del() API was created to address this issue (see\ncommit '233ed09d7fda (\"chardev: add helper function to register char\ndevs with a struct device\")'), use it instead of cdev add/del()."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/1dbb206730f3e5ce90014ad569ddf8167ec4124a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/70cb4295ec806b663665e1d2ed15caab6159880e",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/74d85e9fbc7022a4011102c7474a9c7aeb704a35",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/85aba11a8ea92a8eef2de95ebbe063086fd62d9c",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b7fb2dad571d1e21173c06cef0bced77b323990a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/d6cdc6ae542845d4d0ac8b6d99362bde7042a3c7",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/da27b834c1e0222e149e06caddf7718478086d1b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
52
CVE-2022/CVE-2022-487xx/CVE-2022-48760.json
Normal file
52
CVE-2022/CVE-2022-487xx/CVE-2022-48760.json
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48760",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:14.110",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\n\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\nthe URB; that works just fine. Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\n\nThe reason is memory-access ordering on SMP systems. In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\n\nCPU 0\t\t\t\t\tCPU 1\n----------------------------\t\t---------------------------------\nusb_kill_urb():\t\t\t\t__usb_hcd_giveback_urb():\n ...\t\t\t\t\t ...\n atomic_inc(&urb->reject);\t\t atomic_dec(&urb->use_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(&urb->use_count) == 0);\n\t\t\t\t\t if (atomic_read(&urb->reject))\n\t\t\t\t\t\twake_up(&usb_kill_urb_queue);\n\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb->reject, then read urb->use_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb->use_count, then read urb->reject.\n\nThis pattern is referred to in memory-model circles as SB (for \"Store\nBuffering\"), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes. The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\n\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\n\nThe problem is fixed by adding suitable memory barriers. To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\nthemselves don't provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\n\nThis patch adds the necessary memory barriers."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
32
CVE-2022/CVE-2022-487xx/CVE-2022-48761.json
Normal file
32
CVE-2022/CVE-2022-487xx/CVE-2022-48761.json
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48761",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:14.203",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci-plat: fix crash when suspend if remote wake enable\n\nCrashed at i.mx8qm platform when suspend if enable remote wakeup\n\nInternal error: synchronous external abort: 96000210 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12\nHardware name: Freescale i.MX8QM MEK (DT)\nWorkqueue: events_unbound async_run_entry_fn\npstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8\nlr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8\nsp : ffff80001394bbf0\nx29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578\nx26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001\nx20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0\nx8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453\nx5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c\nx2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620\nCall trace:\n xhci_disable_hub_port_wake.isra.62+0x60/0xf8\n xhci_suspend+0x58/0x510\n xhci_plat_suspend+0x50/0x78\n platform_pm_suspend+0x2c/0x78\n dpm_run_callback.isra.25+0x50/0xe8\n __device_suspend+0x108/0x3c0\n\nThe basic flow:\n\t1. run time suspend call xhci_suspend, xhci parent devices gate the clock.\n 2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend\n 3. xhci_suspend call xhci_disable_hub_port_wake, which access register,\n\t but clock already gated by run time suspend.\n\nThis problem was hidden by power domain driver, which call run time resume before it.\n\nBut the below commit remove it and make this issue happen.\n\tcommit c1df456d0f06e (\"PM: domains: Don't runtime resume devices at genpd_prepare()\")\n\nThis patch call run time resume before suspend to make sure clock is on\nbefore access register.\n\nTesteb-by: Abel Vesa <abel.vesa@nxp.com>"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/20c51a4c52208f98e27308c456a1951778f41fa5",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/8b05ad29acb972850ad795fa850e814b2e758b83",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/9df478463d9feb90dae24f183383961cf123a0ec",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/d5755832a1e47f5d8773f0776e211ecd4e02da72",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
24
CVE-2022/CVE-2022-487xx/CVE-2022-48762.json
Normal file
24
CVE-2022/CVE-2022-487xx/CVE-2022-48762.json
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
{
|
||||||
|
"id": "CVE-2022-48762",
|
||||||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||||||
|
"published": "2024-06-20T12:15:14.287",
|
||||||
|
"lastModified": "2024-06-20T12:43:25.663",
|
||||||
|
"vulnStatus": "Awaiting Analysis",
|
||||||
|
"descriptions": [
|
||||||
|
{
|
||||||
|
"lang": "en",
|
||||||
|
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: extable: fix load_unaligned_zeropad() reg indices\n\nIn ex_handler_load_unaligned_zeropad() we erroneously extract the data and\naddr register indices from ex->type rather than ex->data. As ex->type will\ncontain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):\n * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is\n extracted from bits [9:5]. Thus, we may attempt to dereference an\n arbitrary address as X0 may hold an arbitrary value.\n * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is\n extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary\n behaviour within load_unaligned_zeropad() and its caller.\n\nFix this by extracting both values from ex->data as originally intended.\n\nOn an MTE-enabled QEMU image we are hitting the following crash:\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Call trace:\n fixup_exception+0xc4/0x108\n __do_kernel_fault+0x3c/0x268\n do_tag_check_fault+0x3c/0x104\n do_mem_abort+0x44/0xf4\n el1_abort+0x40/0x64\n el1h_64_sync_handler+0x60/0xa0\n el1h_64_sync+0x7c/0x80\n link_path_walk+0x150/0x344\n path_openat+0xa0/0x7dc\n do_filp_open+0xb8/0x168\n do_sys_openat2+0x88/0x17c\n __arm64_sys_openat+0x74/0xa0\n invoke_syscall+0x48/0x148\n el0_svc_common+0xb8/0xf8\n do_el0_svc+0x28/0x88\n el0_svc+0x24/0x84\n el0t_64_sync_handler+0x88/0xec\n el0t_64_sync+0x1b4/0x1b8\n Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"metrics": {},
|
||||||
|
"references": [
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239a",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"url": "https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb",
|
||||||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user