Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak<br /> <br /> btrfs_ioctl_space_info() has a TOCTOU race between two passes over the<br /> block group RAID type lists. The first pass counts entries to determine<br /> the allocation size, then the second pass fills the buffer. The<br /> groups_sem rwlock is released between passes, allowing concurrent block<br /> group removal to reduce the entry count.<br /> <br /> When the second pass fills fewer entries than the first pass counted,<br /> copy_to_user() copies the full alloc_size bytes including trailing<br /> uninitialized kmalloc bytes to userspace.<br /> <br /> Fix by copying only total_spaces entries (the actually-filled count from<br /> the second pass) instead of alloc_size bytes, and switch to kzalloc so<br /> any future copy size mismatch cannot leak heap data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix missing last_unlink_trans update when removing a directory<br /> <br /> When removing a directory we are not updating its last_unlink_trans field,<br /> which can result in incorrect fsync behaviour in case some one fsyncs the<br /> directory after it was removed because it&amp;#39;s holding a file descriptor on<br /> it.<br /> <br /> Example scenario:<br /> <br /> mkdir /mnt/dir1<br /> mkdir /mnt/dir1/dir2<br /> mkdir /mnt/dir3<br /> <br /> sync -f /mnt<br /> <br /> # Do some change to the directory and fsync it.<br /> chmod 700 /mnt/dir1<br /> xfs_io -c fsync /mnt/dir1<br /> <br /> # Move dir2 out of dir1 so that dir1 becomes empty.<br /> mv /mnt/dir1/dir2 /mnt/dir3/<br /> <br /> open fd on /mnt/dir1<br /> call rmdir(2) on path "/mnt/dir1"<br /> fsync fd<br /> <br /> <br /> <br /> When attempting to mount the filesystem, the log replay will fail with<br /> an -EIO error and dmesg/syslog has the following:<br /> <br /> [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650<br /> [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm<br /> [445771.627912] BTRFS info (device dm-0): start tree-log replay<br /> [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5<br /> [445771.629453] memcg:ffff89f400351b00<br /> [445771.629892] aops:btree_aops [btrfs] ino:1<br /> [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8<br /> [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00<br /> [445771.635029] page dumped because: eb page dump<br /> [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir<br /> [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5<br /> [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087<br /> [445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [445771.638097] inode generation 3 transid 9 size 16 nbytes 16384<br /> [445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [445771.638100] rdev 0 sequence 2 flags 0x0<br /> [445771.638102] atime 1775744884.0<br /> [445771.660056] ctime 1775744885.645502983<br /> [445771.660058] mtime 1775744885.645502983<br /> [445771.660060] otime 1775744884.0<br /> [445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [445771.660064] index 0 name_len 2<br /> [445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34<br /> [445771.660068] location key (259 1 0) type 2<br /> [445771.660070] transid 9 data_len 0 name_len 4<br /> [445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34<br /> [445771.660076] location key (257 1 0) type 2<br /> [445771.660077] transid 9 data_len 0 name_len 4<br /> [445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [445771.660079] location key (257 1 0) type 2<br /> [445771.660080] transid 9 data_len 0 name_len 4<br /> [445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34<br /> [445771.660082] location key (259 1 0) type 2<br /> [445771.660083] transid 9 data_len 0 name_len 4<br /> [445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160<br /> [445771.660086] inode generation 9 transid 9 size 8 nbytes 0<br /> [445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0<br /> [445771.660088] rdev 0 sequence 2 flags 0x0<br /> [445771.660089] atime 1775744885.641174097<br /> [445771.660090] ctime 1775744885.645502983<br /> [445771.660091] mtime 1775744885.645502983<br /> [445771.660105] otime 1775744885.641174097<br /> [445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14<br /> [445771.660107] index 2 name_len 4<br /> [445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34<br /> [445771.660109] location key (2<br /> ---truncated---

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 /> 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 /> 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 /> RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()<br /> <br /> Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal<br /> destroy path cleans it up.

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 /> 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 /> 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 /> 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 /> 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.