Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix race in syncpt alloc/free<br /> <br /> Fix race condition between host1x_syncpt_alloc()<br /> and host1x_syncpt_put() by using kref_put_mutex()<br /> instead of kref_put() + manual mutex locking.<br /> <br /> This ensures no thread can acquire the<br /> syncpt_mutex after the refcount drops to zero<br /> but before syncpt_release acquires it.<br /> This prevents races where syncpoints could<br /> be allocated while still being cleaned up<br /> from a previous release.<br /> <br /> Remove explicit mutex locking in syncpt_release<br /> as kref_put_mutex() handles this atomically.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: fix bug: unprivileged task can create labels<br /> <br /> If an unprivileged task is allowed to relabel itself<br /> (/smack/relabel-self is not empty),<br /> it can freely create new labels by writing their<br /> names into own /proc/PID/attr/smack/current<br /> <br /> This occurs because do_setattr() imports<br /> the provided label in advance,<br /> before checking "relabel-self" list.<br /> <br /> This change ensures that the "relabel-self" list<br /> is checked before importing the label.

*** Pendiente de traducción *** 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[].

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: init bioset in mddev_init<br /> <br /> IO operations may be needed before md_run(), such as updating metadata<br /> after writing sysfs. Without bioset, this triggers a NULL pointer<br /> dereference as below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> Call Trace:<br /> md_update_sb+0x658/0xe00<br /> new_level_store+0xc5/0x120<br /> md_attr_store+0xc9/0x1e0<br /> sysfs_kf_write+0x6f/0xa0<br /> kernfs_fop_write_iter+0x141/0x2a0<br /> vfs_write+0x1fc/0x5a0<br /> ksys_write+0x79/0x180<br /> __x64_sys_write+0x1d/0x30<br /> x64_sys_call+0x2818/0x2880<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Reproducer<br /> ```<br /> mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]<br /> echo inactive &gt; /sys/block/md0/md/array_state<br /> echo 10 &gt; /sys/block/md0/md/new_level<br /> ```<br /> <br /> mddev_init() can only be called once per mddev, no need to test if bioset<br /> has been initialized anymore.