Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: fix crash due to removal of uninitialised entry<br /> <br /> A crash in conntrack was reported while trying to unlink the conntrack<br /> entry from the hash bucket list:<br /> [exception RIP: __nf_ct_delete_from_lists+172]<br /> [..]<br /> #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]<br /> #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]<br /> #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]<br /> [..]<br /> <br /> The nf_conn struct is marked as allocated from slab but appears to be in<br /> a partially initialised state:<br /> <br /> ct hlist pointer is garbage; looks like the ct hash value<br /> (hence crash).<br /> ct-&gt;status is equal to IPS_CONFIRMED|IPS_DYING, which is expected<br /> ct-&gt;timeout is 30000 (=30s), which is unexpected.<br /> <br /> Everything else looks like normal udp conntrack entry. If we ignore<br /> ct-&gt;status and pretend its 0, the entry matches those that are newly<br /> allocated but not yet inserted into the hash:<br /> - ct hlist pointers are overloaded and store/cache the raw tuple hash<br /> - ct-&gt;timeout matches the relative time expected for a new udp flow<br /> rather than the absolute &amp;#39;jiffies&amp;#39; value.<br /> <br /> If it were not for the presence of IPS_CONFIRMED,<br /> __nf_conntrack_find_get() would have skipped the entry.<br /> <br /> Theory is that we did hit following race:<br /> <br /> cpu x cpu y cpu z<br /> found entry E found entry E<br /> E is expired <br /> nf_ct_delete()<br /> return E to rcu slab<br /> init_conntrack<br /> E is re-inited,<br /> ct-&gt;status set to 0<br /> reply tuplehash hnnode.pprev<br /> stores hash value.<br /> <br /> cpu y found E right before it was deleted on cpu x.<br /> E is now re-inited on cpu z. cpu y was preempted before<br /> checking for expiry and/or confirm bit.<br /> <br /> -&gt;refcnt set to 1<br /> E now owned by skb<br /> -&gt;timeout set to 30000<br /> <br /> If cpu y were to resume now, it would observe E as<br /> expired but would skip E due to missing CONFIRMED bit.<br /> <br /> nf_conntrack_confirm gets called<br /> sets: ct-&gt;status |= CONFIRMED<br /> This is wrong: E is not yet added<br /> to hashtable.<br /> <br /> cpu y resumes, it observes E as expired but CONFIRMED:<br /> <br /> nf_ct_expired()<br /> -&gt; yes (ct-&gt;timeout is 30s)<br /> confirmed bit set.<br /> <br /> cpu y will try to delete E from the hashtable:<br /> nf_ct_delete() -&gt; set DYING bit<br /> __nf_ct_delete_from_lists<br /> <br /> Even this scenario doesn&amp;#39;t guarantee a crash:<br /> cpu z still holds the table bucket lock(s) so y blocks:<br /> <br /> wait for spinlock held by z<br /> <br /> CONFIRMED is set but there is no<br /> guarantee ct will be added to hash:<br /> "chaintoolong" or "clash resolution"<br /> logic both skip the insert step.<br /> reply hnnode.pprev still stores the<br /> hash value.<br /> <br /> unlocks spinlock<br /> return NF_DROP<br /> <br /> <br /> In case CPU z does insert the entry into the hashtable, cpu y will unlink<br /> E again right away but no crash occurs.<br /> <br /> Without &amp;#39;cpu y&amp;#39; race, &amp;#39;garbage&amp;#39; hlist is of no consequence:<br /> ct refcnt remains at 1, eventually skb will be free&amp;#39;d and E gets<br /> destroyed via: nf_conntrack_put -&gt; nf_conntrack_destroy -&gt; nf_ct_destroy.<br /> <br /> To resolve this, move the IPS_CONFIRMED assignment after the table<br /> insertion but before the unlock.<br /> <br /> Pablo points out that the confirm-bit-store could be reordered to happen<br /> before hlist add resp. the timeout fixup, so switch to set_bit and<br /> before_atomic memory barrier to prevent this.<br /> <br /> It doesn&amp;#39;t matter if other CPUs can observe a newly inserted entry right<br /> before the CONFIRMED bit was set:<br /> <br /> Such event cannot be distinguished from above "E is the old incarnation"<br /> case: the entry will be skipped.<br /> <br /> Also change nf_ct_should_gc() to first check the confirmed bit.<br /> <br /> The gc sequence is:<br /> 1. Check if entry has expired, if not skip to next entry<br /> 2. Obtain a reference to the expired entry.<br /> 3. Call nf_ct_should_gc() to double-check step 1.<br /> <br /> nf_ct_should_gc() is thus called only for entries that already failed an<br /> expiry check. After this patch, once the confirmed bit check pas<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()<br /> <br /> syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]<br /> <br /> l2cap_sock_resume_cb() has a similar problem that was fixed by commit<br /> 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").<br /> <br /> Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed<br /> under l2cap_sock_resume_cb(), we can avoid the issue simply by checking<br /> if chan-&gt;data is NULL.<br /> <br /> Let&amp;#39;s not access to the killed socket in l2cap_sock_resume_cb().<br /> <br /> [0]:<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52<br /> <br /> CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Workqueue: hci0 hci_rx_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)<br /> __dump_stack+0x30/0x40 lib/dump_stack.c:94<br /> dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120<br /> print_report+0x58/0x84 mm/kasan/report.c:524<br /> kasan_report+0xb0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189<br /> __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37<br /> instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357<br /> hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]<br /> hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514<br /> hci_event_func net/bluetooth/hci_event.c:7511 [inline]<br /> hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565<br /> hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070<br /> process_one_work+0x7e8/0x155c kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3321 [inline]<br /> worker_thread+0x958/0xed8 kernel/workqueue.c:3402<br /> kthread+0x5fc/0x75c kernel/kthread.c:464<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: net: sierra: check for no status endpoint<br /> <br /> The driver checks for having three endpoints and<br /> having bulk in and out endpoints, but not that<br /> the third endpoint is interrupt input.<br /> Rectify the omission.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix various oops due to inet_sock type confusion.<br /> <br /> syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while<br /> freeing inet_sk(sk)-&gt;inet_opt.<br /> <br /> The address was freed multiple times even though it was read-only memory.<br /> <br /> cipso_v4_sock_setattr() did nothing wrong, and the root cause was type<br /> confusion.<br /> <br /> The cited commit made it possible to create smc_sock as an INET socket.<br /> <br /> The issue is that struct smc_sock does not have struct inet_sock as the<br /> first member but hijacks AF_INET and AF_INET6 sk_family, which confuses<br /> various places.<br /> <br /> In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(),<br /> which is an address of a function in the text segment.<br /> <br /> $ pahole -C inet_sock vmlinux<br /> struct inet_sock {<br /> ...<br /> struct ip_options_rcu * inet_opt; /* 784 8 */<br /> <br /> $ pahole -C smc_sock vmlinux<br /> struct smc_sock {<br /> ...<br /> void (*clcsk_data_ready)(struct sock *); /* 784 8 */<br /> <br /> The same issue for another field was reported before. [2][3]<br /> <br /> At that time, an ugly hack was suggested [4], but it makes both INET<br /> and SMC code error-prone and hard to change.<br /> <br /> Also, yet another variant was fixed by a hacky commit 98d4435efcbf3<br /> ("net/smc: prevent NULL pointer dereference in txopt_get").<br /> <br /> Instead of papering over the root cause by such hacks, we should not<br /> allow non-INET socket to reuse the INET infra.<br /> <br /> Let&amp;#39;s add inet_sock as the first member of smc_sock.<br /> <br /> [0]:<br /> kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73<br /> WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT<br /> Tainted: [W]=WARN<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955<br /> sp : ffff8000a03a7730<br /> x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3<br /> x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00<br /> x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0<br /> x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff<br /> x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c<br /> x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff<br /> x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000<br /> x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360<br /> x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000<br /> Call trace:<br /> kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P)<br /> cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914<br /> netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000<br /> smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581<br /> smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912<br /> security_inode_setsecurity+0x118/0x3c0 security/security.c:2706<br /> __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251<br /> __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295<br /> vfs_setxattr+0x158/0x2ac fs/xattr.c:321<br /> do_setxattr fs/xattr.c:636 [inline]<br /> file_setxattr+0x1b8/0x294 fs/xattr.c:646<br /> path_setxattrat+0x2ac/0x320 fs/xattr.c:711<br /> __do_sys_fsetxattr fs/xattr.c:761 [inline]<br /> __se_sys_fsetxattr fs/xattr.c:758 [inline]<br /> __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879<br /> el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpl: Fix use-after-free in rpl_do_srh_inline().<br /> <br /> Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers<br /> the splat below [0].<br /> <br /> rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after<br /> skb_cow_head(), which is illegal as the header could be freed then.<br /> <br /> Let&amp;#39;s fix it by making oldhdr to a local struct instead of a pointer.<br /> <br /> [0]:<br /> [root@fedora net]# ./lwt_dst_cache_ref_loop.sh<br /> ...<br /> TEST: rpl (input)<br /> [ 57.631529] ==================================================================<br /> BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> Read of size 40 at addr ffff888122bf96d8 by task ping6/1543<br /> <br /> CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)<br /> kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)<br /> kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))<br /> __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))<br /> rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)<br /> lwtunnel_input (net/core/lwtunnel.c:459)<br /> ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))<br /> __netif_receive_skb_one_core (net/core/dev.c:5967)<br /> process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)<br /> __napi_poll.constprop.0 (net/core/dev.c:7452)<br /> net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)<br /> handle_softirqs (kernel/softirq.c:579)<br /> do_softirq (kernel/softirq.c:480 (discriminator 20))<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:407)<br /> __dev_queue_xmit (net/core/dev.c:4740)<br /> ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)<br /> ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)<br /> ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)<br /> ip6_send_skb (net/ipv6/ip6_output.c:1983)<br /> rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)<br /> __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))<br /> __x64_sys_sendto (net/socket.c:2231)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f68cffb2a06<br /> Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08<br /> RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06<br /> RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003<br /> RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4<br /> R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0<br /> <br /> <br /> Allocated by task 1543:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))<br /> __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)<br /> kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)<br /> kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))<br /> __alloc_skb (net/core/skbuff.c:669)<br /> __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))<br /> ip6_<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: Fix race condition on qfq_aggregate<br /> <br /> A race condition can occur when &amp;#39;agg&amp;#39; is modified in qfq_change_agg<br /> (called during qfq_enqueue) while other threads access it<br /> concurrently. For example, qfq_dump_class may trigger a NULL<br /> dereference, and qfq_delete_class may cause a use-after-free.<br /> <br /> This patch addresses the issue by:<br /> <br /> 1. Moved qfq_destroy_class into the critical section.<br /> <br /> 2. Added sch_tree_lock protection to qfq_dump_class and<br /> qfq_dump_class_stats.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix initialization of data for instructions that write to subdevice<br /> <br /> Some Comedi subdevice instruction handlers are known to access<br /> instruction data elements beyond the first `insn-&gt;n` elements in some<br /> cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions<br /> allocate at least `MIN_SAMPLES` (16) data elements to deal with this,<br /> but they do not initialize all of that. For Comedi instruction codes<br /> that write to the subdevice, the first `insn-&gt;n` data elements are<br /> copied from user-space, but the remaining elements are left<br /> uninitialized. That could be a problem if the subdevice instruction<br /> handler reads the uninitialized data. Ensure that the first<br /> `MIN_SAMPLES` elements are initialized before calling these instruction<br /> handlers, filling the uncopied elements with 0. For<br /> `do_insnlist_ioctl()`, the same data buffer elements are used for<br /> handling a list of instructions, so ensure the first `MIN_SAMPLES`<br /> elements are initialized for each instruction that writes to the<br /> subdevice.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix use of uninitialized data in insn_rw_emulate_bits()<br /> <br /> For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"<br /> subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and<br /> `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have<br /> `insn_read` and `insn_write` handler functions, but to have an<br /> `insn_bits` handler function for handling Comedi `INSN_BITS`<br /> instructions. In that case, the subdevice&amp;#39;s `insn_read` and/or<br /> `insn_write` function handler pointers are set to point to the<br /> `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.<br /> <br /> For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the<br /> supplied `data[0]` value is a valid copy from user memory. It will at<br /> least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in<br /> "comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are<br /> allocated. However, if `insn-&gt;n` is 0 (which is allowable for<br /> `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain<br /> uninitialized data, and certainly contains invalid data, possibly from a<br /> different instruction in the array of instructions handled by<br /> `do_insnlist_ioctl()`. This will result in an incorrect value being<br /> written to the digital output channel (or to the digital input/output<br /> channel if configured as an output), and may be reflected in the<br /> internal saved state of the channel.<br /> <br /> Fix it by returning 0 early if `insn-&gt;n` is 0, before reaching the code<br /> that accesses `data[0]`. Previously, the function always returned 1 on<br /> success, but it is supposed to be the number of data samples actually<br /> read or written up to `insn-&gt;n`, which is 0 in this case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large<br /> <br /> The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to<br /> hold the array of `struct comedi_insn`, getting the length from the<br /> `n_insns` member of the `struct comedi_insnlist` supplied by the user.<br /> The allocation will fail with a WARNING and a stack dump if it is too<br /> large.<br /> <br /> Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`<br /> value is unreasonable.<br /> <br /> Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set<br /> this to the same value as `MAX_SAMPLES` (65536), which is the maximum<br /> allowed sum of the values of the member `n` in the array of `struct<br /> comedi_insn`, and sensible comedi instructions will have an `n` of at<br /> least 1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree<br /> <br /> htb_lookup_leaf has a BUG_ON that can trigger with the following:<br /> <br /> tc qdisc del dev lo root<br /> tc qdisc add dev lo root handle 1: htb default 1<br /> tc class add dev lo parent 1: classid 1:1 htb rate 64bit<br /> tc qdisc add dev lo parent 1:1 handle 2: netem<br /> tc qdisc add dev lo parent 2:1 handle 3: blackhole<br /> ping -I lo -c1 -W0.001 127.0.0.1<br /> <br /> The root cause is the following:<br /> <br /> 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on<br /> the selected leaf qdisc<br /> 2. netem_dequeue calls enqueue on the child qdisc<br /> 3. blackhole_enqueue drops the packet and returns a value that is not<br /> just NET_XMIT_SUCCESS<br /> 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and<br /> since qlen is now 0, it calls htb_qlen_notify -&gt; htb_deactivate -&gt;<br /> htb_deactiviate_prios -&gt; htb_remove_class_from_row -&gt; htb_safe_rb_erase<br /> 5. As this is the only class in the selected hprio rbtree,<br /> __rb_change_child in __rb_erase_augmented sets the rb_root pointer to<br /> NULL<br /> 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,<br /> which causes htb_dequeue_tree to call htb_lookup_leaf with the same<br /> hprio rbtree, and fail the BUG_ON<br /> <br /> The function graph for this scenario is shown here:<br /> 0) | htb_enqueue() {<br /> 0) + 13.635 us | netem_enqueue();<br /> 0) 4.719 us | htb_activate_prios();<br /> 0) # 2249.199 us | }<br /> 0) | htb_dequeue() {<br /> 0) 2.355 us | htb_lookup_leaf();<br /> 0) | netem_dequeue() {<br /> 0) + 11.061 us | blackhole_enqueue();<br /> 0) | qdisc_tree_reduce_backlog() {<br /> 0) | qdisc_lookup_rcu() {<br /> 0) 1.873 us | qdisc_match_from_root();<br /> 0) 6.292 us | }<br /> 0) 1.894 us | htb_search();<br /> 0) | htb_qlen_notify() {<br /> 0) 2.655 us | htb_deactivate_prios();<br /> 0) 6.933 us | }<br /> 0) + 25.227 us | }<br /> 0) 1.983 us | blackhole_dequeue();<br /> 0) + 86.553 us | }<br /> 0) # 2932.761 us | qdisc_warn_nonwc();<br /> 0) | htb_lookup_leaf() {<br /> 0) | BUG_ON();<br /> ------------------------------------------<br /> <br /> The full original bug report can be seen here [1].<br /> <br /> We can fix this just by returning NULL instead of the BUG_ON,<br /> as htb_dequeue_tree returns NULL when htb_lookup_leaf returns<br /> NULL.<br /> <br /> [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls<br /> <br /> kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host<br /> for more than one event channel potr (nr_ports &gt; 1).<br /> <br /> After the kmalloc_array(), the error paths need to go through the<br /> "out" label, but the call to kvm_read_guest_virt() does not.<br /> <br /> [Adjusted commit message. - Paolo]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime<br /> <br /> Assuming the "rx-vlan-filter" feature is enabled on a net device, the<br /> 8021q module will automatically add or remove VLAN 0 when the net device<br /> is put administratively up or down, respectively. There are a couple of<br /> problems with the above scheme.<br /> <br /> The first problem is a memory leak that can happen if the "rx-vlan-filter"<br /> feature is disabled while the device is running:<br /> <br /> # ip link add bond1 up type bond mode 0<br /> # ethtool -K bond1 rx-vlan-filter off<br /> # ip link del dev bond1<br /> <br /> When the device is put administratively down the "rx-vlan-filter"<br /> feature is disabled, so the 8021q module will not remove VLAN 0 and the<br /> memory will be leaked [1].<br /> <br /> Another problem that can happen is that the kernel can automatically<br /> delete VLAN 0 when the device is put administratively down despite not<br /> adding it when the device was put administratively up since during that<br /> time the "rx-vlan-filter" feature was disabled. null-ptr-unref or<br /> bug_on[2] will be triggered by unregister_vlan_dev() for refcount<br /> imbalance if toggling filtering during runtime:<br /> <br /> $ ip link add bond0 type bond mode 0<br /> $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q<br /> $ ethtool -K bond0 rx-vlan-filter off<br /> $ ifconfig bond0 up<br /> $ ethtool -K bond0 rx-vlan-filter on<br /> $ ifconfig bond0 down<br /> $ ip link del vlan0<br /> <br /> Root cause is as below:<br /> step1: add vlan0 for real_dev, such as bond, team.<br /> register_vlan_dev<br /> vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1<br /> step2: disable vlan filter feature and enable real_dev<br /> step3: change filter from 0 to 1<br /> vlan_device_event<br /> vlan_filter_push_vids<br /> ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0<br /> step4: real_dev down<br /> vlan_device_event<br /> vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0<br /> vlan_info_rcu_free //free vlan0<br /> step5: delete vlan0<br /> unregister_vlan_dev<br /> BUG_ON(!vlan_info); //vlan_info is null<br /> <br /> Fix both problems by noting in the VLAN info whether VLAN 0 was<br /> automatically added upon NETDEV_UP and based on that decide whether it<br /> should be deleted upon NETDEV_DOWN, regardless of the state of the<br /> "rx-vlan-filter" feature.<br /> <br /> [1]<br /> unreferenced object 0xffff8880068e3100 (size 256):<br /> comm "ip", pid 384, jiffies 4296130254<br /> hex dump (first 32 bytes):<br /> 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 81ce31fa):<br /> __kmalloc_cache_noprof+0x2b5/0x340<br /> vlan_vid_add+0x434/0x940<br /> vlan_device_event.cold+0x75/0xa8<br /> notifier_call_chain+0xca/0x150<br /> __dev_notify_flags+0xe3/0x250<br /> rtnl_configure_link+0x193/0x260<br /> rtnl_newlink_create+0x383/0x8e0<br /> __rtnl_newlink+0x22c/0xa40<br /> rtnl_newlink+0x627/0xb00<br /> rtnetlink_rcv_msg+0x6fb/0xb70<br /> netlink_rcv_skb+0x11f/0x350<br /> netlink_unicast+0x426/0x710<br /> netlink_sendmsg+0x75a/0xc20<br /> __sock_sendmsg+0xc1/0x150<br /> ____sys_sendmsg+0x5aa/0x7b0<br /> ___sys_sendmsg+0xfc/0x180<br /> <br /> [2]<br /> kernel BUG at net/8021q/vlan.c:99!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))<br /> RSP: 0018:ffff88810badf310 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80<br /> R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000<br /> R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e<br /> FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0<br /> Call Trace:<br />