Page 325 of 2581 results (0.019 seconds)

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK> Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: validar la entrada del usuario para la longitud esperada. Recibí varios informes de syzbot que muestran errores antiguos expuestos por BPF después de la confirmación 20f2505fb436 ("bpf: intente evitar kzalloc en cgroup/{s,g} etsockopt") setsockopt() El argumento @optlen debe tenerse en cuenta antes de copiar datos. ERROR: KASAN: losa fuera de límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] ERROR: KASAN: losa fuera de límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en do_replace net/ipv4/netfilter/ip_tables.c:1111 [en línea] ERROR: KASAN: losa fuera de los límites en do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ ip_tables.c:1627 Lectura del tamaño 96 en la dirección ffff88802cd73da0 mediante la tarea syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 No contaminado 6.9.0-rc2-next-20240403-syzkaller #0 Hardware nombre: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/ kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c :189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] copy_from_sockptr include/linux/sockptr.h:55 [en línea] do_replace net/ipv4/netfilter/ip_tables .c:1111 [en línea] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2 311 __sys_setsockopt +0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 +0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000 00036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 Asignado por la tarea 7238: kasan_save_stack mm/kasan/common. c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [en línea] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/ linux/kasan.h: 211 [en línea] __do_kmalloc_node mm/slub.c: 4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c: 4082 kmalloc_noproof include/linux/slab.h: 664 [inline] __cgraGrempf_filup 47/ 0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 __se_sys _setsockopt net/socket. c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x72/0x7a La dirección con errores pertenece al objeto en ffff88802cd73da0 que pertenece al caché kmalloc-8 de talla 8 el cochecito La dirección se encuentra a 0 bytes dentro de la región asignada de 1 byte [ffff88802cd73da0, ffff88802cd73da1) La dirección con errores pertenece a la página física: página: refcount:1 mapcount:0 mapeo:00000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff8000000 0000(nodo=0 |zone=1|lastcpupid=0xfff) tipo de página: 0xfffffff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6 https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5 https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525 https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018 https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc https://lists.debian.org/debian-lts-announce/2024/06/ •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Prevent lock inversion deadlock in map delete elem syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock); Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context. Detect when map_delete_elem operation is invoked from a context which is _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an error. Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today. • https://git.kernel.org/stable/c/604326b41a6fb9b4a78b6179335decee0365cd8c https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058 https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75 https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5 https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86 https://git.kernel.org/stable/c/913c30f827e17d8cda1da6eeb990f350d36cb69b https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f2 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: prevent kernel-infoleak syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1]. The issue here is that 'struct tc_skbmod' has a four bytes hole. We need to clear the structure before filling fields. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: act_skbmod: prevent kernel-infoleak syzbot encontró que tcf_skbmod_dump() estaba copiando cuatro bytes de la pila del kernel al espacio de usuario [1]. El problema aquí es que 'struct tc_skbmod' tiene un agujero de cuatro bytes. Necesitamos borrar la estructura antes de completar los campos. [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:114 [en línea] ERROR: KMSAN: kernel-infoleak en copy_to_user_iter lib/iov_iter.c:24 [en línea] ERROR: KMSAN: kernel-infoleak en iterate_ubuf include/linux/iov_iter.h:29 [en línea] ERROR: KMSAN: kernel-infoleak en iterate_and_advance2 include/linux/iov_iter.h:245 [en línea] ERROR: KMSAN: kernel-infoleak en iterate_and_advance include/linux/iov_iter. h:271 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [en línea] copy_to_user_iter lib/iov_iter.c:24 [en línea] iterate_ubuf include/linux/iov_iter.h:29 [en línea] iterate_and_advance2 include/linux/iov_iter.h:245 [en línea] iterate_and_advance include/linux/iov_iter.h:271 [en línea] _copy_to_iter+0x366/0x2520 lib/iov_iter.c: 185 copy_to_iter include/linux/uio.h:196 [en línea] simple_copy_to_iter net/core/datagram.c:532 [en línea] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/ datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [en línea] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [en línea] 0 neto/ socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [en línea] __se_sys_recvfrom net/socket.c:2256 [en línea] __x64_sys_recvfrom+0x126/0x1d0 net/ enchufe.c: 2256 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit se almacenó en la memoria en: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:13 17 netlink_unicast+0x9f/ 0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [en línea] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c: 741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [en línea] tcf_add_notify net/sched/act_api.c:2048 [en línea] tcf_action_add net/sched/act_api.c:2071 [en línea] tc_ctl_action+0x146e/0x19d0 net/sched/act_api .c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net / enlace de red /af_netlink.c:1335 [en línea] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 __sock_sendmsg + 0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 __do_sys_ enviar mensaje de red/socket. c:2676 [en línea] __se_sys_sendmsg net/socket.c:2674 [en línea] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 se almacenó en la memoria en: __nla_put lib/nlattr .c:1041 [en línea] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 tcf_action_dump_1+0x85 mi/ 0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [en línea ] tcf_add_notify net/sched/act_api.c: 2042 [inline] tcf_action_add net/sched/act_api.c: 2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c: 2119 rtnetlink_rcv_msg+0x177/0x1900 rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncado--- • https://git.kernel.org/stable/c/86da71b57383d40993cb90baafb3735cffe5d800 https://git.kernel.org/stable/c/f190a4aa03cbd518bd9c62a66e1233984f5fd2ec https://git.kernel.org/stable/c/f356eb2fb567e0931143ac1769ac802d3b3e2077 https://git.kernel.org/stable/c/5e45dc4408857305f4685abfd7a528a1e58b51b5 https://git.kernel.org/stable/c/a097fc199ab5f4b5392c5144034c0d2148b55a14 https://git.kernel.org/stable/c/55d3fe7b2b7bc354e7cbc1f7b8f98a29ccd5a366 https://git.kernel.org/stable/c/729ad2ac2a2cdc9f4a4bdfd40bfd276e6bc33924 https://git.kernel.org/stable/c/7bb2c7103d8c13b06a57bf997b8cdbe93 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/sched: fix lockdep splat in qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() is called with the qdisc lock held, not RTNL. We must use qdisc_lookup_rcu() instead of qdisc_lookup() syzbot reported: WARNING: suspicious RCU usage 6.1.74-syzkaller #0 Not tainted ----------------------------- net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792 stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> [<ffffffff85b85f14>] __dump_stack lib/dump_stack.c:88 [inline] [<ffffffff85b85f14>] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [<ffffffff85b86007>] dump_stack+0x15/0x1e lib/dump_stack.c:113 [<ffffffff81802299>] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [<ffffffff84f0054c>] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305 [<ffffffff84f037c3>] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [<ffffffff84f5b78c>] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [<ffffffff84fbcf63>] qdisc_enqueue include/net/sch_generic.h:833 [inline] [<ffffffff84fbcf63>] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [<ffffffff84eecab9>] dequeue_skb net/sched/sch_generic.c:292 [inline] [<ffffffff84eecab9>] qdisc_restart net/sched/sch_generic.c:397 [inline] [<ffffffff84eecab9>] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [<ffffffff84d7aa96>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [<ffffffff84d85d29>] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [<ffffffff85e002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [<ffffffff81568bca>] invoke_softirq kernel/softirq.c:447 [inline] [<ffffffff81568bca>] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [<ffffffff81568ae9>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [<ffffffff85b89f52>] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107 [<ffffffff85c00ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: corrige lockdep splat en qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() se llama con el bloqueo de qdisc retenido, no con RTNL. Debemos usar qdisc_lookup_rcu() en lugar de qdisc_lookup() syzbot informó: ADVERTENCIA: uso sospechoso de RCU 6.1.74-syzkaller #0 No contaminado ---------------------- ------- ¡net/sched/sch_api.c:305 uso sospechoso de rcu_dereference_protected()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 3 bloqueos mantenidos por udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux /rcupdate.h:306 [en línea] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #0: ffffffff87c729a0 (rcu_read_lock ){....}-{1:2}, en: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&amp;sch-&gt;q.lock){+.-.}-{ 2:2}, en: spin_lock include/linux/spinlock.h:350 [en línea] #1: ffff888171861108 (&amp;sch-&gt;q.lock){+.-.}-{2:2}, en: net_tx_action+0x754 /0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux/rcupdate.h:306 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2} , en: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792 stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Seguimiento de llamadas: [] __dump_stack lib/dump_stack.c:88 [en línea] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [ ] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_a foto.c: 305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [ ] qdisc_enqueue incluye/net/sch_generic .h:833 [en línea] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [en línea] [] qdisc_restart net/sched/sch_generic.c:397 [en línea] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c: 447 [ en línea] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0 x42/0x90 arco/x86/ kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656 • https://git.kernel.org/stable/c/9d9a38b5639fcefacc1e977567fb4b4e4a74d0b3 https://git.kernel.org/stable/c/d636fc5dd692c8f4e00ae6e0359c0eceeb5d9bdb https://git.kernel.org/stable/c/3a4741bb13caf482b877b10ac1bcf7390cad7077 https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460 https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1 https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b https://access.redhat.com/security/cve/CVE-2024-35892 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Fix potential null pointer dereference In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may return NULL as ptp_header due to abnormal packet type or corrupted packet. Fix this bug by adding ptp_header check. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: phy: micrel: corrige una posible desreferencia del puntero null en lan8814_get_sig_rx() y lan8814_get_sig_tx() ptp_parse_header() puede devolver NULL como ptp_header debido a un tipo de paquete anormal o a un paquete dañado. Corrija este error agregando ptp_header check. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/ece19502834d84ece2e056db28257ca2aa6e4d48 https://git.kernel.org/stable/c/10608161696c2768f53426642f78a42bcaaa53e8 https://git.kernel.org/stable/c/95c1016a2d92c4c28a9d1b6d09859c00b19c0ea4 https://git.kernel.org/stable/c/49767b0df276f12e3e7184601e09ee7430e252dc https://git.kernel.org/stable/c/96c155943a703f0655c0c4cab540f67055960e91 •