Vulnérabilités de linux-raspi · Page n° 195

drm/fb-helper: Only consider active CRTCs for vblank sync

In the Linux kernel, the following vulnerability has been resolved: drm/fb-helper: Only consider active CRTCs for vblank sync Only synchronize fbdev output to the vblank of an active CRTC. Go over the list of CRTCs and pick the first that matches. Fixes warnings as the one shown below [ 77.201354] WARNING: drivers/gpu/drm/drm_vblank.c:1320 at drm_crtc_wait_one_vblank+0x194/0x1cc [drm], CPU#1: kworker/1:7/1867 [ 77.201354] omapdrm omapdrm.0: [drm] vblank wait timed out on crtc 0 This currently happens if the fbdev output is not on CRTC 0. Atomic and non-atomic drivers require distinct code paths. As for other fbdev operations, impleme

octeontx2-af: fix VF bringup affecting PF promiscuous state

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix VF bringup affecting PF promiscuous state Mbox handling of nix_set_rx_mode for a VF with promiscuous and all_multi flags set to false causes deletion of the PF's promiscuous and allmulti MCAM rules. This occurs because the APIs that enable/disable these rules operate only on the PF, even when the mbox request is made via a VF interface. Guard both rvu_npc_enable_allmulti_entry() and rvu_npc_enable_promisc_entry() disable paths with an is_vf() check so that a VF bringing up or tearing down its interface cannot inadvertently clear the PF's MCAM rules.

smb: client: fix overflow in passthrough ioctl bounds check

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io

mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()

In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_port_lag_join() When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join() returns an error without releasing the lag reference obtained by the earlier mlxsw_sp_lag_get(). All other error paths in the function jump to the cleanup label that ends with mlxsw_sp_lag_put(), so this is a single missed release. Fix the leak by replacing the bare 'return err' with a goto to the existing error cleanup label, which will drop the reference safely.

mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()

In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired

vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter

In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.

VDUSE: avoid leaking information to userspace

In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.

ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put In sof_ipc4_bytes_put(), the copy size is derived from the old data->size in the buffer rather than the incoming new data's size field from ucontrol. If the new data has a different size, the copy uses the wrong length: it may truncate valid data or copy stale bytes. Fix by validating and using the incoming data's sof_abi_hdr.size from ucontrol before copying.

ASoC: SOF: ipc4-control: Validate notification payload size

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-control: Validate notification payload size Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling.

ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc In sof_ipc3_control_update(), the expected_size calculation uses firmware-provided cdata->num_elems in arithmetic that could overflow on 32-bit platforms, wrapping to a small value. This would allow the cdata->rhdr.hdr.size comparison to pass with mismatched sizes, potentially leading to out-of-bounds access in snd_sof_update_control. Use check_mul_overflow() and check_add_overflow() to detect and reject overflowed size calculations.

ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get In sof_ipc3_bytes_put(), the size used for the memcpy is derived from the old data->size already in the buffer, not the incoming new data's size field. If the new data has a different size, the copy length is wrong: it may truncate valid data or copy stale bytes. Similarly, sof_ipc3_bytes_get() checks data->size against max_size without accounting for the sizeof(struct sof_ipc_ctrl_data) offset of the flex array within the allocation. Fix bytes_put to validate and use the incoming data's sof_abi_hdr.size from

ASoC: SOF: topology: validate vendor array size before parsing

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: validate vendor array size before parsing sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has typ

tipc: restrict socket queue dumps in enqueue tracepoints

In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 m

• Mettez à jour vers 7.0.0-1020.20

net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any siz

net: atm: reject out-of-range traffic classes in QoS validation

In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is acc

net: ife: require ETH_HLEN to be pullable in ife_decode()

In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before

• Mettez à jour vers 7.0.0-1020.20

KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault() Add missing radix_tree_preload() in _gaccess_shadow_fault() to guarantee forward progress. The core of _gaccess_shadow_fault() has been split into ___gaccess_shadow_fault() in order to simplify locking.

KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(), which does not zero the returned pages: values = vmalloc(args->count); In the non-peek (migration) path, dat_get_cmma() reports a byte count spanning from the first to the last dirty page, but __dat_get_cmma_pte() writes values[gfn - start] only for pages whose CMMA dirty bit is set. The walk uses DAT_WALK_IGN_HOLES, so clean and unmapped pages that lie between two dirty pages within the reported span are visited but never store their byte. Those gaps

KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix GISC refcount leak on AIF enable failure kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path.

KVM: arm64: vgic: Check the interrupt is still ours before migrating it

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the

• Mettez à jour vers 7.0.0-1020.20