CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47182 – scsi: core: Fix scsi_mode_sense() buffer length handling
https://notcve.org/view.php?id=CVE-2021-47182
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix scsi_mode_sense() buffer length handling Several problems exist with scsi_mode_sense() buffer length handling: 1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer. Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small. Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes. While at it, also fix the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was. • https://git.kernel.org/stable/c/e15de347faf4a9f494cbd4e9a623d343dc1b5851 https://git.kernel.org/stable/c/17b49bcbf8351d3dbe57204468ac34f033ed60bc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47181 – usb: musb: tusb6010: check return value after calling platform_get_resource()
https://notcve.org/view.php?id=CVE-2021-47181
In the Linux kernel, the following vulnerability has been resolved: usb: musb: tusb6010: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. • https://git.kernel.org/stable/c/1ba7605856e05fa991d4654ac69e5ace66c767b9 https://git.kernel.org/stable/c/b3f43659eb0b9af2e6ef18a8d829374610b19e7a https://git.kernel.org/stable/c/28be095eb612a489705d38c210afaf1103c5f4f8 https://git.kernel.org/stable/c/f87a79c04a33ab4e5be598c7b0867e6ef193d702 https://git.kernel.org/stable/c/3ee15f1af17407be381bcf06a78fa60b471242dd https://git.kernel.org/stable/c/679eee466d0f9ffa60a2b0c6ec19be5128927f04 https://git.kernel.org/stable/c/06cfb4cb2241e704d72e3045cf4d7dfb567fbce0 https://git.kernel.org/stable/c/14651496a3de6807a17c310f63c894ea0 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26816 – x86, relocs: Ignore relocations in .notes section
https://notcve.org/view.php?id=CVE-2024-26816
In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86, relocs: ignorar reubicaciones en la sección .notes Al compilar con CONFIG_XEN_PV=y, los símbolos .text se emiten en la sección .notes para que Xen pueda encontrar el punto de entrada "startup_xen" . Esta información se utiliza antes de iniciar el kernel, por lo que las reubicaciones no son útiles. • https://git.kernel.org/stable/c/5ead97c84fa7d63a6a7a2f4e9f18f452bd109045 https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03 https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088 https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723 https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b4 •
CVSS: -EPSS: 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 •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52340 – kernel: ICMPv6 “Packet Too Big” packets force a DoS of the Linux kernel by forcing 100% CPU
https://notcve.org/view.php?id=CVE-2023-52340
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket. La implementación de IPv6 en el kernel de Linux anterior a 6.3 tiene un umbral net/ipv6/route.c max_size que se puede consumir fácilmente, por ejemplo, provocando una denegación de servicio (errores de red inaccesible) cuando los paquetes IPv6 se envían en un bucle a través de un enchufe crudo. A flaw in the routing table size was found in the ICMPv6 handling of "Packet Too Big". The size of the routing table is regulated by periodic garbage collection. However, with "Packet Too Big Messages" it is possible to exceed the routing table size and garbage collector threshold. • https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277 https://access.redhat.com/security/cve/CVE-2023-52340 https://bugzilla.redhat.com/show_bug.cgi?id=2257979 • CWE-400: Uncontrolled Resource Consumption •