CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26815 – net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check
https://notcve.org/view.php?id=CVE-2024-26815
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check taprio_parse_tc_entry() is not correctly checking TCA_TAPRIO_TC_ENTRY_INDEX attribute: int tc; // Signed value tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]); if (tc >= TC_QOPT_MAX_QUEUE) { NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range"); return -ERANGE; } syzbot reported that it could fed arbitary negative values: UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18 shift exponent -2147418108 is negative CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386 taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline] taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline] taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877 taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134 qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355 tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340 R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: verificación adecuada de TCA_TAPRIO_TC_ENTRY_INDEX taprio_parse_tc_entry() no verifica correctamente el atributo TCA_TAPRIO_TC_ENTRY_INDEX: int tc; // Valor con signo tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]); if (tc >= TC_QOPT_MAX_QUEUE) { NL_SET_ERR_MSG_MOD(extack, "índice de entrada TC fuera de rango"); volver -RANGE; } syzbot informó que podía alimentar valores negativos arbitrarios: UBSAN: desplazamiento fuera de los límites en net/sched/sch_taprio.c:1722:18 exponente de desplazamiento -2147418108 es negativo CPU: 0 PID: 5066 Comm: syz-executor367 No tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [en línea] __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386 taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [ en línea] taprio_parse_tc_entries net /sched/sch_taprio.c:1768 [en línea] taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877 taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134 qdisc_create+0x9d4/0x1190 net/sched/sch_api. c:1355 tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_ker nel net/netlink/ AF_NETLINK.C: 1341 [en línea] netlink_unicast+0x7ea/0x980 net/netlink/AF_netLink.c: 1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c: 1908 sock_sendmsg_nosec net/socket.c: 730 [730] 1 /0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [en línea] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/ 0x240 entrada_SYSCALL_64_after_hwframe +0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Código: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 8 9c8 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:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R 11: 0000000000000246 R12: 00007ffd4de45340 R13: 00007ffd4de45310 R14: 00000000000000001 R15: 00007ffd4de45340 • https://git.kernel.org/stable/c/a54fc09e4cba3004443aa05979f8c678196c8226 https://git.kernel.org/stable/c/bd2474a45df7c11412c2587de3d4e43760531418 https://git.kernel.org/stable/c/6915b1b28fe57e92c78e664366dc61c4f15ff03b https://git.kernel.org/stable/c/860e838fb089d652a446ced52cbdf051285b68e7 https://git.kernel.org/stable/c/9b720bb1a69a9f12a4a5c86b6f89386fe05ed0f2 https://git.kernel.org/stable/c/343041b59b7810f9cdca371f445dd43b35c740b1 https://access.redhat.com/security/cve/CVE-2024-26815 https://bugzilla.redhat.com/show_bug.cgi?id=2274478 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26811 – ksmbd: validate payload size in ipc response
https://notcve.org/view.php?id=CVE-2024-26811
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate payload size in ipc response If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: validar el tamaño del payload en la respuesta de ipc Si instala herramientas ksmbd maliciosas, ksmbd.mountd puede devolver una respuesta de ipc no válida al servidor del kernel de ksmbd. ksmbd debe validar el tamaño del payload de la respuesta ipc de ksmbd.mountd para evitar el desbordamiento de la memoria o los límites. Este parche valida 3 respuestas ipc que tienen payload. • https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300 https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896 https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27437 – vfio/pci: Disable auto-enable of exclusive INTx IRQ
https://notcve.org/view.php?id=CVE-2024-27437
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: deshabilita la habilitación automática de INTx IRQ exclusivo. Actualmente, para dispositivos que requieren enmascaramiento en el irqchip para INTx, es decir. En dispositivos sin soporte DisINTx, la IRQ se habilita en request_irq() y posteriormente se deshabilita según sea necesario para alinearse con el indicador de estado enmascarado. • https://git.kernel.org/stable/c/89e1f7d4c66d85f42c3d52ea3866eb10cadf6153 https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351 https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5 https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438 https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060 https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2 https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26814 – vfio/fsl-mc: Block calling interrupt handler without trigger
https://notcve.org/view.php?id=CVE-2024-26814
In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/fsl-mc: Bloquear el controlador de interrupciones de llamada sin disparador. El puntero de disparo eventfd_ctx del objeto vfio_fsl_mc_irq es inicialmente NULL y puede convertirse en NULL si el usuario establece el disparador eventfd en -1. • https://git.kernel.org/stable/c/cc0ee20bd96971c10eba9a83ecf1c0733078a083 https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417 https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267 https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9 https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26813 – vfio/platform: Create persistent IRQ handlers
https://notcve.org/view.php?id=CVE-2024-26813
In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/plataforma: cree controladores IRQ persistentes. La plataforma vfio SET_IRQS ioctl actualmente permite la activación de bucle invertido de una interrupción antes de que el usuario haya configurado un evento de señalización, lo que permite un puntero NULL. desreferencia. • https://git.kernel.org/stable/c/57f972e2b341dd6a73533f9293ec55d584a5d833 https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5 https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362 https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086 https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415 •