Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not let BPF test infra emit invalid GSO types to stack<br /> <br /> Yinhao et al. reported that their fuzzer tool was able to trigger a<br /> skb_warn_bad_offload() from netif_skb_features() -&gt; gso_features_check().<br /> When a BPF program - triggered via BPF test infra - pushes the packet<br /> to the loopback device via bpf_clone_redirect() then mentioned offload<br /> warning can be seen. GSO-related features are then rightfully disabled.<br /> <br /> We get into this situation due to convert___skb_to_skb() setting<br /> gso_segs and gso_size but not gso_type. Technically, it makes sense<br /> that this warning triggers since the GSO properties are malformed due<br /> to the gso_type. Potentially, the gso_type could be marked non-trustworthy<br /> through setting it at least to SKB_GSO_DODGY without any other specific<br /> assumptions, but that also feels wrong given we should not go further<br /> into the GSO engine in the first place.<br /> <br /> The checks were added in 121d57af308d ("gso: validate gso_type in GSO<br /> handlers") because there were malicious (syzbot) senders that combine<br /> a protocol with a non-matching gso_type. If we would want to drop such<br /> packets, gso_features_check() currently only returns feature flags via<br /> netif_skb_features(), so one location for potentially dropping such skbs<br /> could be validate_xmit_unreadable_skb(), but then otoh it would be<br /> an additional check in the fast-path for a very corner case. Given<br /> bpf_clone_redirect() is the only place where BPF test infra could emit<br /> such packets, lets reject them right there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Fix NULL event access and potential PEBS record loss<br /> <br /> When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the<br /> perf_event_overflow() could be called to process the last PEBS record.<br /> <br /> While perf_event_overflow() could trigger the interrupt throttle and<br /> stop all events of the group, like what the below call-chain shows.<br /> <br /> perf_event_overflow()<br /> -&gt; __perf_event_overflow()<br /> -&gt;__perf_event_account_interrupt()<br /> -&gt; perf_event_throttle_group()<br /> -&gt; perf_event_throttle()<br /> -&gt; event-&gt;pmu-&gt;stop()<br /> -&gt; x86_pmu_stop()<br /> <br /> The side effect of stopping the events is that all corresponding event<br /> pointers in cpuc-&gt;events[] array are cleared to NULL.<br /> <br /> Assume there are two PEBS events (event a and event b) in a group. When<br /> intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the<br /> last PEBS record of PEBS event a, interrupt throttle is triggered and<br /> all pointers of event a and event b are cleared to NULL. Then<br /> intel_pmu_drain_pebs_icl() tries to process the last PEBS record of<br /> event b and encounters NULL pointer access.<br /> <br /> To avoid this issue, move cpuc-&gt;events[] clearing from x86_pmu_stop()<br /> to x86_pmu_del(). It&amp;#39;s safe since cpuc-&gt;active_mask or<br /> cpuc-&gt;pebs_enabled is always checked before access the event pointer<br /> from cpuc-&gt;events[].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: ETR: Fix ETR buffer use-after-free issue<br /> <br /> When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed<br /> and enabled again, currently sysfs_buf will point to the newly<br /> allocated memory(buf_new) and free the old memory(buf_old). But the<br /> etr_buf that is being used by the ETR remains pointed to buf_old, not<br /> updated to buf_new. In this case, it will result in a memory<br /> use-after-free issue.<br /> <br /> Fix this by checking ETR&amp;#39;s mode before updating and releasing buf_old,<br /> if the mode is CS_MODE_SYSFS, then skip updating and releasing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ns: initialize ns_list_node for initial namespaces<br /> <br /> Make sure that the list is always initialized for initial namespaces.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check in __bpf_get_stackid()<br /> <br /> Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()<br /> when copying stack trace data. The issue occurs when the perf trace<br /> contains more stack entries than the stack map bucket can hold,<br /> leading to an out-of-bounds write in the bucket&amp;#39;s data array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix null deref on srq-&gt;rq.queue after resize failure<br /> <br /> A NULL pointer dereference can occur in rxe_srq_chk_attr() when<br /> ibv_modify_srq() is invoked twice in succession under certain error<br /> conditions. The first call may fail in rxe_queue_resize(), which leads<br /> rxe_srq_from_attr() to set srq-&gt;rq.queue = NULL. The second call then<br /> triggers a crash (null deref) when accessing<br /> srq-&gt;rq.queue-&gt;buf-&gt;index_mask.<br /> <br /> Call Trace:<br /> <br /> rxe_modify_srq+0x170/0x480 [rdma_rxe]<br /> ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]<br /> ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]<br /> ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]<br /> ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]<br /> ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]<br /> ? tryinc_node_nr_active+0xe6/0x150<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]<br /> ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]<br /> ? __pfx___raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx_do_vfs_ioctl+0x10/0x10<br /> ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0<br /> ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10<br /> ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]<br /> ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]<br /> __x64_sys_ioctl+0x138/0x1c0<br /> do_syscall_64+0x82/0x250<br /> ? fdget_pos+0x58/0x4c0<br /> ? ksys_write+0xf3/0x1c0<br /> ? __pfx_ksys_write+0x10/0x10<br /> ? do_syscall_64+0xc8/0x250<br /> ? __pfx_vm_mmap_pgoff+0x10/0x10<br /> ? fget+0x173/0x230<br /> ? fput+0x2a/0x80<br /> ? ksys_mmap_pgoff+0x224/0x4c0<br /> ? do_syscall_64+0xc8/0x250<br /> ? do_user_addr_fault+0x37b/0xfe0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix peer HE MCS assignment<br /> <br /> In ath11k_wmi_send_peer_assoc_cmd(), peer&amp;#39;s transmit MCS is sent to<br /> firmware as receive MCS while peer&amp;#39;s receive MCS sent as transmit MCS,<br /> which goes against firmwire&amp;#39;s definition.<br /> <br /> While connecting to a misbehaved AP that advertises 0xffff (meaning not<br /> supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff<br /> is assigned to he_mcs-&gt;rx_mcs_set field.<br /> <br /> Ext Tag: HE Capabilities<br /> [...]<br /> Supported HE-MCS and NSS Set<br /> [...]<br /> Rx and Tx MCS Maps 160 MHz<br /> [...]<br /> Tx HE-MCS Map 160 MHz: 0xffff<br /> <br /> Swap the assignment to fix this issue.<br /> <br /> As the HE rate control mask is meant to limit our own transmit MCS, it<br /> needs to go via he_mcs-&gt;rx_mcs_set field. With the aforementioned swapping<br /> done, change is needed as well to apply it to the peer&amp;#39;s receive MCS.<br /> <br /> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41<br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id<br /> <br /> Use check_add_overflow() to guard against potential integer overflows<br /> when adding the binary blob lengths and the size of an asymmetric_key_id<br /> structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a<br /> possible buffer overflow when copying data from potentially malicious<br /> X.509 certificate fields that can be arbitrarily large, such as ASN.1<br /> INTEGER serial numbers, issuer names, etc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aead - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in aead algorithms, hence, causes memory corruptions and<br /> crashes as the underlying functions in the algorithm framework have not<br /> been updated to set the reqsize properly from cra_reqsize. [1]<br /> <br /> Add proper set_reqsize calls in the aead init function to properly<br /> initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Initialize allocated memory before use<br /> <br /> KMSAN reports: Multiple uninitialized values detected:<br /> <br /> - KMSAN: uninit-value in ntfs_read_hdr (3)<br /> - KMSAN: uninit-value in bcmp (3)<br /> <br /> Memory is allocated by __getname(), which is a wrapper for<br /> kmem_cache_alloc(). This memory is used before being properly<br /> cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to<br /> properly allocate and clear memory before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: defer config unlock in nbd_genl_connect<br /> <br /> There is one use-after-free warning when running NBD_CMD_CONNECT and<br /> NBD_CLEAR_SOCK:<br /> <br /> nbd_genl_connect<br /> nbd_alloc_and_init_config // config_refs=1<br /> nbd_start_device // config_refs=2<br /> set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3<br /> recv_work done // config_refs=2<br /> NBD_CLEAR_SOCK // config_refs=1<br /> close nbd // config_refs=0<br /> refcount_inc -&gt; uaf<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290<br /> nbd_genl_connect+0x16d0/0x1ab0<br /> genl_family_rcv_msg_doit+0x1f3/0x310<br /> genl_rcv_msg+0x44a/0x790<br /> <br /> The issue can be easily reproduced by adding a small delay before<br /> refcount_inc(&amp;nbd-&gt;config_refs) in nbd_genl_connect():<br /> <br /> mutex_unlock(&amp;nbd-&gt;config_lock);<br /> if (!ret) {<br /> set_bit(NBD_RT_HAS_CONFIG_REF, &amp;config-&gt;runtime_flags);<br /> + printk("before sleep\n");<br /> + mdelay(5 * 1000);<br /> + printk("after sleep\n");<br /> refcount_inc(&amp;nbd-&gt;config_refs);<br /> nbd_connect_reply(info, nbd-&gt;index);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse<br /> <br /> The following warning appears when running syzkaller, and this issue also<br /> exists in the mainline code.<br /> <br /> ------------[ cut here ]------------<br /> list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.<br /> WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130<br /> Modules linked in:<br /> CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__list_add_valid_or_report+0xf7/0x130<br /> RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817<br /> RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001<br /> RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c<br /> R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100<br /> R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48<br /> FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 80000000<br /> Call Trace:<br /> <br /> input_register_handler+0xb3/0x210<br /> mac_hid_start_emulation+0x1c5/0x290<br /> mac_hid_toggle_emumouse+0x20a/0x240<br /> proc_sys_call_handler+0x4c2/0x6e0<br /> new_sync_write+0x1b1/0x2d0<br /> vfs_write+0x709/0x950<br /> ksys_write+0x12a/0x250<br /> do_syscall_64+0x5a/0x110<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The WARNING occurs when two processes concurrently write to the mac-hid<br /> emulation sysctl, causing a race condition in mac_hid_toggle_emumouse().<br /> Both processes read old_val=0, then both try to register the input handler,<br /> leading to a double list_add of the same handler.<br /> <br /> CPU0 CPU1<br /> ------------------------- -------------------------<br /> vfs_write() //write 1 vfs_write() //write 1<br /> proc_sys_write() proc_sys_write()<br /> mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()<br /> old_val = *valp // old_val=0<br /> old_val = *valp // old_val=0<br /> mutex_lock_killable()<br /> proc_dointvec() // *valp=1<br /> mac_hid_start_emulation()<br /> input_register_handler()<br /> mutex_unlock()<br /> mutex_lock_killable()<br /> proc_dointvec()<br /> mac_hid_start_emulation()<br /> input_register_handler() //Trigger Warning<br /> mutex_unlock()<br /> <br /> Fix this by moving the old_val read inside the mutex lock region.