Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ncsi: fix skb leak in error paths<br /> <br /> Early return paths in NCSI RX and AEN handlers fail to release<br /> the received skb, resulting in a memory leak.<br /> <br /> Specifically, ncsi_aen_handler() returns on invalid AEN packets<br /> without consuming the skb. Similarly, ncsi_rcv_rsp() exits early<br /> when failing to resolve the NCSI device, response handler, or<br /> request, leaving the skb unfreed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nexthop: fix percpu use-after-free in remove_nh_grp_entry<br /> <br /> When removing a nexthop from a group, remove_nh_grp_entry() publishes<br /> the new group via rcu_assign_pointer() then immediately frees the<br /> removed entry&amp;#39;s percpu stats with free_percpu(). However, the<br /> synchronize_net() grace period in the caller remove_nexthop_from_groups()<br /> runs after the free. RCU readers that entered before the publish still<br /> see the old group and can dereference the freed stats via<br /> nh_grp_entry_stats_inc() -&gt; get_cpu_ptr(nhge-&gt;stats), causing a<br /> use-after-free on percpu memory.<br /> <br /> Fix by deferring the free_percpu() until after synchronize_net() in the<br /> caller. Removed entries are chained via nh_list onto a local deferred<br /> free list. After the grace period completes and all RCU readers have<br /> finished, the percpu stats are safely freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: fix device leak on probe failure<br /> <br /> Driver core holds a reference to the USB interface and its parent USB<br /> device while the interface is bound to a driver and there is no need to<br /> take additional references unless the structures are needed after<br /> disconnect.<br /> <br /> This driver takes a reference to the USB device during probe but does<br /> not to release it on probe failures.<br /> <br /> Drop the redundant device reference to fix the leak, reduce cargo<br /> culting, make it easier to spot drivers where an extra reference is<br /> needed, and reduce the risk of further memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free by using call_rcu() for oplock_info<br /> <br /> ksmbd currently frees oplock_info immediately using kfree(), even<br /> though it is accessed under RCU read-side critical sections in places<br /> like opinfo_get() and proc_show_files().<br /> <br /> Since there is no RCU grace period delay between nullifying the pointer<br /> and freeing the memory, a reader can still access oplock_info<br /> structure after it has been freed. This can leads to a use-after-free<br /> especially in opinfo_get() where atomic_inc_not_zero() is called on<br /> already freed memory.<br /> <br /> Fix this by switching to deferred freeing using call_rcu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Don&amp;#39;t log keys in SMB3 signing and encryption key generation<br /> <br /> When KSMBD_DEBUG_AUTH logging is enabled, generate_smb3signingkey() and<br /> generate_smb3encryptionkey() log the session, signing, encryption, and<br /> decryption key bytes. Remove the logs to avoid exposing credentials.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: fix use-after-free in smb2_open()<br /> <br /> The opinfo pointer obtained via rcu_dereference(fp-&gt;f_opinfo) is<br /> dereferenced after rcu_read_unlock(), creating a use-after-free<br /> window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix in-place encryption corruption in SMB2_write()<br /> <br /> SMB2_write() places write payload in iov[1..n] as part of rq_iov.<br /> smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message()<br /> encrypts iov[1] in-place, replacing the original plaintext with<br /> ciphertext. On a replayable error, the retry sends the same iov[1]<br /> which now contains ciphertext instead of the original data,<br /> resulting in corruption.<br /> <br /> The corruption is most likely to be observed when connections are<br /> unstable, as reconnects trigger write retries that re-send the<br /> already-encrypted data.<br /> <br /> This affects SFU mknod, MF symlinks, etc. On kernels before<br /> 6.10 (prior to the netfs conversion), sync writes also used<br /> this path and were similarly affected. The async write path<br /> wasn&amp;#39;t unaffected as it uses rq_iter which gets deep-copied.<br /> <br /> Fix by moving the write payload into rq_iter via iov_iter_kvec(),<br /> so smb3_init_transform_rq() deep-copies it before encryption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/apic: Disable x2apic on resume if the kernel expects so<br /> <br /> When resuming from s2ram, firmware may re-enable x2apic mode, which may have<br /> been disabled by the kernel during boot either because it doesn&amp;#39;t support IRQ<br /> remapping or for other reasons. This causes the kernel to continue using the<br /> xapic interface, while the hardware is in x2apic mode, which causes hangs.<br /> This happens on defconfig + bare metal + s2ram.<br /> <br /> Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be<br /> disabled, i.e. when x2apic_mode = 0.<br /> <br /> The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the<br /> pre-sleep configuration or initial boot configuration for each CPU, including<br /> MSR state:<br /> <br /> When executing from the power-on reset vector as a result of waking from an<br /> S2 or S3 sleep state, the platform firmware performs only the hardware<br /> initialization required to restore the system to either the state the<br /> platform was in prior to the initial operating system boot, or to the<br /> pre-sleep configuration state. In multiprocessor systems, non-boot<br /> processors should be placed in the same state as prior to the initial<br /> operating system boot.<br /> <br /> (further ahead)<br /> <br /> If this is an S2 or S3 wake, then the platform runtime firmware restores<br /> minimum context of the system before jumping to the waking vector. This<br /> includes:<br /> <br /> CPU configuration. Platform runtime firmware restores the pre-sleep<br /> configuration or initial boot configuration of each CPU (MSR, MTRR,<br /> firmware update, SMBase, and so on). Interrupts must be disabled (for<br /> IA-32 processors, disabled by CLI instruction).<br /> <br /> (and other things)<br /> <br /> So at least as per the spec, re-enablement of x2apic by the firmware is<br /> allowed if "x2apic on" is a part of the initial boot configuration.<br /> <br /> [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix NULL pointer dereference in ublk_ctrl_set_size()<br /> <br /> ublk_ctrl_set_size() unconditionally dereferences ub-&gt;ub_disk via<br /> set_capacity_and_notify() without checking if it is NULL.<br /> <br /> ub-&gt;ub_disk is NULL before UBLK_CMD_START_DEV completes (it is only<br /> assigned in ublk_ctrl_start_dev()) and after UBLK_CMD_STOP_DEV runs<br /> (ublk_detach_disk() sets it to NULL). Since the UBLK_CMD_UPDATE_SIZE<br /> handler performs no state validation, a user can trigger a NULL pointer<br /> dereference by sending UPDATE_SIZE to a device that has been added but<br /> not yet started, or one that has been stopped.<br /> <br /> Fix this by checking ub-&gt;ub_disk under ub-&gt;mutex before dereferencing<br /> it, and returning -ENODEV if the disk is not available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix undersized l_iclog_roundoff values<br /> <br /> If the superblock doesn&amp;#39;t list a log stripe unit, we set the incore log<br /> roundoff value to 512. This leads to corrupt logs and unmountable<br /> filesystems in generic/617 on a disk with 4k physical sectors...<br /> <br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.<br /> XFS (sda1): failed to locate log tail<br /> XFS (sda1): log mount/recovery failed: error -74<br /> XFS (sda1): log mount failed<br /> XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c<br /> XFS (sda1): Ending clean mount<br /> <br /> ...on the current xfsprogs for-next which has a broken mkfs. xfs_info<br /> shows this...<br /> <br /> meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks<br /> = sectsz=4096 attr=2, projid32bit=1<br /> = crc=1 finobt=1, sparse=1, rmapbt=1<br /> = reflink=1 bigtime=1 inobtcount=1 nrext64=1<br /> = exchange=1 metadir=1<br /> data = bsize=4096 blocks=2579968, imaxpct=25<br /> = sunit=0 swidth=0 blks<br /> naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1<br /> log =internal log bsize=4096 blocks=16384, version=2<br /> = sectsz=4096 sunit=0 blks, lazy-count=1<br /> realtime =none extsz=4096 blocks=0, rtextents=0<br /> = rgcount=0 rgsize=268435456 extents<br /> = zoned=0 start=0 reserved=0<br /> <br /> ...observe that the log section has sectsz=4096 sunit=0, which means<br /> that the roundoff factor is 512, not 4096 as you&amp;#39;d expect. We should<br /> fix mkfs not to generate broken filesystems, but anyone can fuzz the<br /> ondisk superblock so we should be more cautious. I think the inadequate<br /> logic predates commit a6a65fef5ef8d0, but that&amp;#39;s clearly going to<br /> require a different backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: check if target buffer list is still legacy on recycle<br /> <br /> There&amp;#39;s a gap between when the buffer was grabbed and when it<br /> potentially gets recycled, where if the list is empty, someone could&amp;#39;ve<br /> upgraded it to a ring provided type. This can happen if the request<br /> is forced via io-wq. The legacy recycling is missing checking if the<br /> buffer_list still exists, and if it&amp;#39;s of the correct type. Add those<br /> checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix a few more NULL pointer dereference in device cleanup<br /> <br /> I found a few more paths that cleanup fails due to a NULL version pointer<br /> on unsupported hardware.<br /> <br /> Add NULL checks as applicable.<br /> <br /> (cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)