Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback<br /> <br /> NETIF_F_IPV6_CSUM only advertises support for checksum offload of<br /> packets without IPv6 extension headers. Packets with extension<br /> headers must fall back onto software checksumming. Since TSO<br /> depends on checksum offload, those must revert to GSO.<br /> <br /> The below commit introduces that fallback. It always checks<br /> network header length. For tunneled packets, the inner header length<br /> must be checked instead. Extend the check accordingly.<br /> <br /> A special case is tunneled packets without inner IP protocol. Such as<br /> RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by<br /> transport header either, so also must revert to the software GSO path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: file: Use kzalloc_flex for aio_cmd<br /> <br /> The target_core_file doesn&amp;#39;t initialize the aio_cmd-&gt;iocb for the<br /> ki_write_stream. When a write command fd_execute_rw_aio() is executed,<br /> we may get a bogus ki_write_stream value, causing unintended write<br /> failure status when checking iocb-&gt;ki_write_stream &gt; max_write_streams<br /> in the block device.<br /> <br /> Let&amp;#39;s just use kzalloc_flex when allocating the aio_cmd and let<br /> ki_write_stream=0 to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: fix use-after-free in add_adev() error path<br /> <br /> If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls<br /> auxiliary_device_uninit(adev).<br /> <br /> The auxiliary device has its release callback set to adev_release(),<br /> which frees the containing struct mana_adev. Since adev is embedded in<br /> struct mana_adev, the subsequent fall-through to init_fail and access<br /> to adev-&gt;id may result in a use-after-free.<br /> <br /> Fix this by saving the allocated auxiliary device id in a local<br /> variable before calling auxiliary_device_add(), and use that saved id<br /> in the cleanup path after auxiliary_device_uninit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq<br /> <br /> The wacom_intuos_bt_irq() function processes Bluetooth HID reports<br /> without sufficient bounds checking. A maliciously crafted short report<br /> can trigger an out-of-bounds read when copying data into the wacom<br /> structure.<br /> <br /> Specifically, report 0x03 requires at least 22 bytes to safely read<br /> the processed data and battery status, while report 0x04 (which<br /> falls through to 0x03) requires 32 bytes.<br /> <br /> Add explicit length checks for these report IDs and log a warning if<br /> a short report is received.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check tdls flag in ieee80211_tdls_oper<br /> <br /> When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the<br /> station exists but not whether it is actually a TDLS station. This<br /> allows the operation to proceed for non-TDLS stations, causing<br /> unintended side effects like modifying channel context and HT<br /> protection before failing.<br /> <br /> Add a check for sta-&gt;sta.tdls early in the ENABLE_LINK case, before<br /> any side effects occur, to ensure the operation is only allowed for<br /> actual TDLS peers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: lec: fix use-after-free in sock_def_readable()<br /> <br /> A race condition exists between lec_atm_close() setting priv-&gt;lecd<br /> to NULL and concurrent access to priv-&gt;lecd in send_to_lecd(),<br /> lec_handle_bridge(), and lec_atm_send(). When the socket is freed<br /> via RCU while another thread is still using it, a use-after-free<br /> occurs in sock_def_readable() when accessing the socket&amp;#39;s wait queue.<br /> <br /> The root cause is that lec_atm_close() clears priv-&gt;lecd without<br /> any synchronization, while callers dereference priv-&gt;lecd without<br /> any protection against concurrent teardown.<br /> <br /> Fix this by converting priv-&gt;lecd to an RCU-protected pointer:<br /> - Mark priv-&gt;lecd as __rcu in lec.h<br /> - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach()<br /> for safe pointer assignment<br /> - Use rcu_access_pointer() for NULL checks that do not dereference<br /> the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and<br /> lecd_attach()<br /> - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(),<br /> lec_handle_bridge() and lec_atm_send() to safely access lecd<br /> - Use rcu_assign_pointer() followed by synchronize_rcu() in<br /> lec_atm_close() to ensure all readers have completed before<br /> proceeding. This is safe since lec_atm_close() is called from<br /> vcc_release() which holds lock_sock(), a sleeping lock.<br /> - Remove the manual sk_receive_queue drain from lec_atm_close()<br /> since vcc_destroy_socket() already drains it after lec_atm_close()<br /> returns.<br /> <br /> v2: Switch from spinlock + sock_hold/put approach to RCU to properly<br /> fix the race. The v1 spinlock approach had two issues pointed out<br /> by Eric Dumazet:<br /> 1. priv-&gt;lecd was still accessed directly after releasing the<br /> lock instead of using a local copy.<br /> 2. The spinlock did not prevent packets being queued after<br /> lec_atm_close() drains sk_receive_queue since timer and<br /> workqueue paths bypass netif_stop_queue().<br /> <br /> Note: Syzbot patch testing was attempted but the test VM terminated<br /> unexpectedly with "Connection to localhost closed by remote host",<br /> likely due to a QEMU AHCI emulation issue unrelated to this fix.<br /> Compile testing with "make W=1 net/atm/lec.o" passes cleanly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: close crash window in attr dabtree inactivation<br /> <br /> When inactivating an inode with node-format extended attributes,<br /> xfs_attr3_node_inactive() invalidates all child leaf/node blocks via<br /> xfs_trans_binval(), but intentionally does not remove the corresponding<br /> entries from their parent node blocks. The implicit assumption is that<br /> xfs_attr_inactive() will truncate the entire attr fork to zero extents<br /> afterwards, so log recovery will never reach the root node and follow<br /> those stale pointers.<br /> <br /> However, if a log shutdown occurs after the leaf/node block cancellations<br /> commit but before the attr bmap truncation commits, this assumption<br /> breaks. Recovery replays the attr bmap intact (the inode still has<br /> attr fork extents), but suppresses replay of all cancelled leaf/node<br /> blocks, maybe leaving them as stale data on disk. On the next mount,<br /> xlog_recover_process_iunlinks() retries inactivation and attempts to<br /> read the root node via the attr bmap. If the root node was not replayed,<br /> reading the unreplayed root block triggers a metadata verification<br /> failure immediately; if it was replayed, following its child pointers<br /> to unreplayed child blocks triggers the same failure:<br /> <br /> XFS (pmem0): Metadata corruption detected at<br /> xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78<br /> XFS (pmem0): Unmount and run xfs_repair<br /> XFS (pmem0): First 128 bytes of corrupted metadata buffer:<br /> 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117<br /> <br /> Fix this in two places:<br /> <br /> In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a<br /> child block, immediately remove the entry that references it from the<br /> parent node in the same transaction. This eliminates the window where<br /> the parent holds a pointer to a cancelled block. Once all children are<br /> removed, the now-empty root node is converted to a leaf block within the<br /> same transaction. This node-to-leaf conversion is necessary for crash<br /> safety. If the system shutdown after the empty node is written to the<br /> log but before the second-phase bmap truncation commits, log recovery<br /> will attempt to verify the root block on disk. xfs_da3_node_verify()<br /> does not permit a node block with count == 0; such a block will fail<br /> verification and trigger a metadata corruption shutdown. on the other<br /> hand, leaf blocks are allowed to have this transient state.<br /> <br /> In xfs_attr_inactive(), split the attr fork truncation into two explicit<br /> phases. First, truncate all extents beyond the root block (the child<br /> extents whose parent references have already been removed above).<br /> Second, invalidate the root block and truncate the attr bmap to zero in<br /> a single transaction. The two operations in the second phase must be<br /> atomic: as long as the attr bmap has any non-zero length, recovery can<br /> follow it to the root block, so the root block invalidation must commit<br /> together with the bmap-to-zero truncation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcm_loop: Drain commands in target_reset handler<br /> <br /> tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS<br /> without draining any in-flight commands. The SCSI EH documentation<br /> (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver<br /> has made lower layers "forget about timed out scmds" and is ready for new<br /> commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,<br /> mpi3mr) enforces this by draining or completing outstanding commands before<br /> returning SUCCESS.<br /> <br /> Because tcm_loop_target_reset() doesn&amp;#39;t drain, the SCSI EH reuses in-flight<br /> scsi_cmnd structures for recovery commands (e.g. TUR) while the target core<br /> still has async completion work queued for the old se_cmd. The memset in<br /> queuecommand zeroes se_lun and lun_ref_active, causing<br /> transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN<br /> reference prevents transport_clear_lun_ref() from completing, hanging<br /> configfs LUN unlink forever in D-state:<br /> <br /> INFO: task rm:264 blocked for more than 122 seconds.<br /> rm D 0 264 258 0x00004000<br /> Call Trace:<br /> __schedule+0x3d0/0x8e0<br /> schedule+0x36/0xf0<br /> transport_clear_lun_ref+0x78/0x90 [target_core_mod]<br /> core_tpg_remove_lun+0x28/0xb0 [target_core_mod]<br /> target_fabric_port_unlink+0x50/0x60 [target_core_mod]<br /> configfs_unlink+0x156/0x1f0 [configfs]<br /> vfs_unlink+0x109/0x290<br /> do_unlinkat+0x1d5/0x2d0<br /> <br /> Fix this by making tcm_loop_target_reset() actually drain commands:<br /> <br /> 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that<br /> the target core knows about (those not yet CMD_T_COMPLETE).<br /> <br /> 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and<br /> flush_work() on each se_cmd — this drains any deferred completion work<br /> for commands that already had CMD_T_COMPLETE set before the TMR (which<br /> the TMR skips via __target_check_io_state()). This is the same pattern<br /> used by mpi3mr, scsi_debug, and libsas to drain outstanding commands<br /> during reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure<br /> <br /> Presently, if the force feedback initialisation fails when probing the<br /> Logitech G920 Driving Force Racing Wheel for Xbox One, an error number<br /> will be returned and propagated before the userspace infrastructure<br /> (sysfs and /dev/input) has been torn down. If userspace ignores the<br /> errors and continues to use its references to these dangling entities, a<br /> UAF will promptly follow.<br /> <br /> We have 2 options; continue to return the error, but ensure that all of<br /> the infrastructure is torn down accordingly or continue to treat this<br /> condition as a warning by emitting the message but returning success.<br /> It is thought that the original author&amp;#39;s intention was to emit the<br /> warning but keep the device functional, less the force feedback feature,<br /> so let&amp;#39;s go with that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Mitigate potential OOB by removing bogus memset()<br /> <br /> The memset() in hid_report_raw_event() has the good intention of<br /> clearing out bogus data by zeroing the area from the end of the incoming<br /> data string to the assumed end of the buffer. However, as we have<br /> previously seen, doing so can easily result in OOB reads and writes in<br /> the subsequent thread of execution.<br /> <br /> The current suggestion from one of the HID maintainers is to remove the<br /> memset() and simply return if the incoming event buffer size is not<br /> large enough to fill the associated report.<br /> <br /> Suggested-by Benjamin Tissoires <br /> <br /> [bentiss: changed the return value]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: Check to ensure report responses match the request<br /> <br /> It is possible for a malicious (or clumsy) device to respond to a<br /> specific report&amp;#39;s feature request using a completely different report<br /> ID. This can cause confusion in the HID core resulting in nasty<br /> side-effects such as OOB writes.<br /> <br /> Add a check to ensure that the report ID in the response, matches the<br /> one that was requested. If it doesn&amp;#39;t, omit reporting the raw event and<br /> return early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch<br /> <br /> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but<br /> never copies the packet data from the XDP buffer into it. The skb is<br /> passed up the stack containing uninitialized heap memory instead of<br /> the actual received packet, leaking kernel heap contents to userspace.<br /> <br /> Copy the received packet data from the XDP buffer into the skb using<br /> skb_copy_to_linear_data().<br /> <br /> Additionally, remove the skb_mark_for_recycle() call since the skb is<br /> backed by the NAPI page frag allocator, not page_pool. Marking a<br /> non-page_pool skb for recycle causes the free path to return pages to<br /> a page_pool that does not own them, corrupting page_pool state.<br /> <br /> The non-ZC path (emac_rx_packet) does not have these issues because it<br /> uses napi_build_skb() to wrap the existing page_pool page directly,<br /> requiring no copy, and correctly marks for recycle since the page comes<br /> from page_pool_dev_alloc_pages().