Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()<br /> <br /> The convert_chmap_v3() has a loop with its increment size of<br /> cs_desc-&gt;wLength, but we forgot to validate cs_desc-&gt;wLength itself,<br /> which may lead to potential endless loop by a malformed descriptor.<br /> <br /> Add a proper size check to abort the loop for plugging the hole.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()<br /> <br /> Two bugs exist in the vCPU initialisation path:<br /> <br /> 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup<br /> path jumps to &amp;#39;unlock&amp;#39; without calling unpin_host_vcpu() or<br /> unpin_host_sve_state(), permanently leaking pin references on the<br /> host vCPU and SVE state pages.<br /> <br /> Extract a register_hyp_vcpu() helper that performs the checks and<br /> the store. When register_hyp_vcpu() returns an error, call<br /> unpin_host_vcpu() and unpin_host_sve_state() inline before falling<br /> through to the existing &amp;#39;unlock&amp;#39; label.<br /> <br /> 2. register_hyp_vcpu() publishes the new vCPU pointer into<br /> &amp;#39;hyp_vm-&gt;vcpus[]&amp;#39; with a bare store, allowing a concurrent caller<br /> of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU<br /> object.<br /> <br /> Ensure the store uses smp_store_release() and the load uses<br /> smp_load_acquire(). While &amp;#39;vm_table_lock&amp;#39; currently serialises the<br /> store and the load, these barriers ensure the reader sees the fully<br /> initialised &amp;#39;hyp_vcpu&amp;#39; object even if there were a lockless path or<br /> if the lock&amp;#39;s own ordering guarantees were insufficient for nested<br /> object initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core-qspi: control built-in cs manually<br /> <br /> The coreQSPI IP supports only a single chip select, which is<br /> automagically operated by the hardware - set low when the transmit<br /> buffer first gets written to and set high when the number of bytes<br /> written to the TOTALBYTES field of the FRAMES register have been sent on<br /> the bus. Additional devices must use GPIOs for their chip selects.<br /> It was reported to me that if there are two devices attached to this<br /> QSPI controller that the in-built chip select is set low while linux<br /> tries to access the device attached to the GPIO.<br /> <br /> This went undetected as the boards that connected multiple devices to<br /> the SPI controller all exclusively used GPIOs for chip selects, not<br /> relying on the built-in chip select at all. It turns out that this was<br /> because the built-in chip select, when controlled automagically, is set<br /> low when active and high when inactive, thereby ruling out its use for<br /> active-high devices or devices that need to transmit with the chip<br /> select disabled.<br /> <br /> Modify the driver so that it controls chip select directly, retaining<br /> the behaviour for mem_ops of setting the chip select active for the<br /> entire duration of the transfer in the exec_op callback. For regular<br /> transfers, implement the set_cs callback for the core to use.<br /> <br /> As part of this, the existing setup callback, mchp_coreqspi_setup_op(),<br /> is removed. Modifying the CLKIDLE field is not safe to do during<br /> operation when there are multiple devices, so this code is removed<br /> entirely. Setting the MASTER and ENABLE fields is something that can be<br /> done once at probe, it doesn&amp;#39;t need to be re-run for each device.<br /> Instead the new setup callback sets the built-in chip select to its<br /> inactive state for active-low devices, as the reset value of the chip<br /> select in software controlled mode is low.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usblp: fix heap leak in IEEE 1284 device ID via short response<br /> <br /> usblp_ctrl_msg() collapses the usb_control_msg() return value to<br /> 0/-errno, discarding the actual number of bytes transferred. A broken<br /> printer can complete the GET_DEVICE_ID control transfer short and the<br /> driver has no way to know.<br /> <br /> usblp_cache_device_id_string() reads the 2-byte big-endian length prefix<br /> from the response and trusts it (clamped only to the buffer bounds).<br /> The buffer is kmalloc(1024) at probe time. A device that sends exactly<br /> two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves<br /> device_id_string[2..1022] holding stale kmalloc heap.<br /> <br /> That stale data is then exposed:<br /> - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated<br /> at the first NUL in the stale heap), and<br /> - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full<br /> claimed length regardless of NULs, up to 1021 bytes of uninitialized<br /> heap, with the leak size chosen by the device.<br /> <br /> Fix this up by just zapping the buffer with zeros before each request<br /> sent to the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 8021q: delete cleared egress QoS mappings<br /> <br /> vlan_dev_set_egress_priority() currently keeps cleared egress<br /> priority mappings in the hash as tombstones. Repeated set/clear cycles<br /> with distinct skb priorities therefore accumulate mapping nodes until<br /> device teardown and leak memory.<br /> <br /> Delete mappings when vlan_prio is cleared instead of keeping tombstones.<br /> Now that the egress mapping lists are RCU protected, the node can be<br /> unlinked safely and freed after a grace period.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana: Validate rx_hash_key_len<br /> <br /> Sashiko points out that rx_hash_key_len comes from a uAPI structure and is<br /> blindly passed to memcpy, allowing the userspace to trash kernel<br /> memory. Bounds check it so the memcpy cannot overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()<br /> <br /> target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a<br /> 256-byte stack buffer, then will memcpy() cur_len bytes from that<br /> buffer. snprintf() returns the length the output would have had, which<br /> can exceed the buffer size when the fabric WWN is long because iSCSI IQN<br /> names can be up to 223 bytes. The check at the memcpy() site only<br /> guards the destination page write, not the source read, so memcpy() will<br /> read past the stack buffer and copy adjacent stack contents to the sysfs<br /> reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()<br /> will be triggered.<br /> <br /> Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length<br /> check to avoid buffer overflow") added the same bound to the<br /> target_lu_gp_members_show() but the tg_pt_gp variant was missed so<br /> resolve that here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fanotify: fix false positive on permission events<br /> <br /> fsnotify_get_mark_safe() may return false for a mark on an unrelated group,<br /> which results in bypassing the permission check.<br /> <br /> Fix by skipping over detached marks that are not in the current group.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: drop stray &amp;#39;static&amp;#39; from fast-RX rx_result<br /> <br /> ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but<br /> its per-invocation rx_result is declared static. Concurrent callers then<br /> share one instance and can overwrite each other&amp;#39;s result between<br /> ieee80211_rx_mesh_data() and the switch on res.<br /> <br /> That can make a packet that was queued or consumed by<br /> ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make<br /> a packet that should continue return as queued.<br /> <br /> Make res an automatic variable so each invocation keeps its own result.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix a potential clc buffer length underflow<br /> <br /> The buf_len is used to limit the iterations for retrieving the country<br /> power setting and may underflow under certain conditions due to changes<br /> in the power table in CLC.<br /> <br /> This underflow leads to an almost infinite loop or an invalid power<br /> setting resulting in driver initialization failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: use kzalloc to zero-initialize security descriptor buffer<br /> <br /> Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces<br /> to le16") split struct smb_acl&amp;#39;s __le32 num_aces field into __le16<br /> num_aces and __le16 reserved. The reserved field corresponds to Sbz2<br /> in the MS-DTYP ACL wire format, which must be zero [1].<br /> <br /> When building an ACL descriptor in build_sec_desc(), we are using a<br /> kmalloc()&amp;#39;ed descriptor buffer and writing the fields explicitly using<br /> le16() writes now. This never writes to the 2 byte reserved field,<br /> leaving it as uninitialized heap data.<br /> <br /> When the reserved field happens to contain non-zero slab garbage,<br /> Samba rejects the security descriptor with "ndr_pull_security_descriptor<br /> failed: Range Error", causing chmod to fail with EINVAL.<br /> <br /> Change kmalloc() to kzalloc() to ensure the entire buffer is<br /> zero-initialized.<br /> <br /> <br /> [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: validate WMT event SKB length before struct access<br /> <br /> btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to<br /> struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc<br /> (9 bytes) without first checking that the SKB contains enough data.<br /> A short firmware response causes out-of-bounds reads from SKB tailroom.<br /> <br /> Use skb_pull_data() to validate and advance past the base WMT event<br /> header. For the FUNC_CTRL case, pull the additional status field bytes<br /> before accessing them.