Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core-qspi: don&amp;#39;t attempt to transmit during emulated read-only dual/quad operations<br /> <br /> The core will deal with reads by creating clock cycles itself, there&amp;#39;s<br /> no need to generate clock cycles by transmitting garbage data at the<br /> driver level. Further, transmitting garbage data just bricks the transfer<br /> since QSPI doesn&amp;#39;t have a dedicated master-out line like MOSI in regular<br /> SPI. I&amp;#39;m not entirely sure if the transfer is bricked because of the<br /> garbage data being transmitted on the bus or because the core loses<br /> track of whether it is supposed to be sending or receiving data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: ah: account for ESN high bits in async callbacks<br /> <br /> AH allocates its temporary auth/ICV layout differently when ESN is enabled:<br /> the async ahash setup appends a 4-byte seqhi slot before the ICV or<br /> auth_data area, but the async completion callbacks still reconstruct the<br /> temporary layout as if seqhi were absent.<br /> <br /> With an async AH implementation selected, that makes AH copy or compare<br /> the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH<br /> with ESN and forced async hmac(sha1), ping fails with 100% packet loss,<br /> and the callback logs show the pre-fix drift:<br /> <br /> ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24<br /> ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36<br /> <br /> Reconstruct the callback-side layout the same way the setup path built it<br /> by skipping the ESN seqhi slot before locating the saved auth_data or ICV.<br /> Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV<br /> computation, so the async callbacks must account for the seqhi slot.<br /> <br /> Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows<br /> the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24<br /> expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o<br /> build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the<br /> change has not been tested against a real async hardware AH engine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix out-of-bounds read in symlink_data()<br /> <br /> Since smb2_check_message() returns success without length validation for<br /> the symlink error response, in symlink_data() it is possible for<br /> iov-&gt;iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer<br /> only contains the base SMB2 header (64 bytes), accessing<br /> err-&gt;ErrorContextCount (at offset 66) or err-&gt;ByteCount later in<br /> symlink_data() will cause an out-of-bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()<br /> <br /> Sashiko noticed an out-of-bounds read [1].<br /> <br /> In spi_nor_params_show(), the snor_f_names array is passed to<br /> spi_nor_print_flags() using sizeof(snor_f_names).<br /> <br /> Since snor_f_names is an array of pointers, sizeof() returns the total<br /> number of bytes occupied by the pointers<br /> (element_count * sizeof(void *))<br /> rather than the element count itself. On 64-bit systems, this makes the<br /> passed length 8x larger than intended.<br /> <br /> Inside spi_nor_print_flags(), the &amp;#39;names_len&amp;#39; argument is used to<br /> bounds-check the &amp;#39;names&amp;#39; array access. An out-of-bounds read occurs<br /> if a flag bit is set that exceeds the array&amp;#39;s actual element count<br /> but is within the inflated byte-size count.<br /> <br /> Correct this by using ARRAY_SIZE() to pass the actual number of<br /> string pointers in the array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Don&amp;#39;t allow pointer operations on unconfigured streams<br /> <br /> When reporting the pointer for a compressed stream we report the current<br /> I/O frame position by dividing the position by the number of channels<br /> multiplied by the number of container bytes. These values default to 0 and<br /> are only configured as part of setting the stream parameters so this allows<br /> a divide by zero to be configured. Validate that they are non zero,<br /> returning an error if not

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task<br /> <br /> Watchdog task might end between send_sig() and kthread_stop() calls, what<br /> results in the use-after-free issue. Fix this by increasing watchdog task<br /> reference count before calling send_sig() and dropping it by switching to<br /> kthread_stop_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace<br /> <br /> The hdr variable is allocated on the stack and only hdr.version and<br /> hdr.flags are initialized explicitly. Because the struct papr_hvpipe_hdr<br /> contains reserved padding bytes (reserved[3] and reserved2[40]), these<br /> could leak the uninitialized bytes to userspace after copy_to_user().<br /> <br /> This patch fixes that by initializing the whole struct to 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock<br /> <br /> damon_sysfs_quot_goal-&gt;path can be read and written by users, via DAMON<br /> sysfs &amp;#39;path&amp;#39; file. It can also be indirectly read, for the parameters<br /> {on,off}line committing to DAMON. The reads for parameters committing are<br /> protected by damon_sysfs_lock to avoid the sysfs files being destroyed<br /> while any of the parameters are being read. But the user-driven direct<br /> reads and writes are not protected by any lock, while the write is<br /> deallocating the path-pointing buffer. As a result, the readers could<br /> read the already freed buffer (user-after-free). Note that the user-reads<br /> don&amp;#39;t race when the same open file is used by the writer, due to kernfs&amp;#39;s<br /> open file locking. Nonetheless, doing the reads and writes with separate<br /> open files would be common. Fix it by protecting both the user-direct<br /> reads and writes with damon_sysfs_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2&amp;#39;s op cache<br /> <br /> Make sure resources are not improperly shared in the op cache and<br /> cause instruction corruption this way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix fsck inconsistency caused by FGGC of node block<br /> <br /> During FGGC node block migration, fsck may incorrectly treat the<br /> migrated node block as fsync-written data.<br /> <br /> The reproduction scenario:<br /> root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync<br /> root@vm:/mnt/f2fs# rm -f 1<br /> root@vm:/mnt/f2fs# sync<br /> root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP<br /> SPO, "fsck --dry-run" find inode has already checkpointed but still<br /> with DENT_BIT_SHIFT set<br /> <br /> The root cause is that GC does not clear the dentry mark and fsync mark<br /> during node block migration, leading fsck to misinterpret them as<br /> user-issued fsync writes.<br /> <br /> In BGGC mode, node block migration is handled by f2fs_sync_node_pages(),<br /> which guarantees the dentry and fsync marks are cleared before writing.<br /> <br /> This patch move the set/clear of the fsync|dentry marks into<br /> __write_node_folio to make the logic clearer, and ensures the<br /> fsync|dentry mark is cleared in FGGC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init()<br /> <br /> mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When<br /> ib_create_srq() fails for s1, the error branch destroys s0 but falls<br /> through and unconditionally assigns the freed s0 and the ERR_PTR s1 to<br /> devr-&gt;s0 and devr-&gt;s1.<br /> <br /> This leads to several problems: the lock-free fast path checks<br /> "if (devr-&gt;s1) return 0;" and treats the ERR_PTR as already initialised;<br /> users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via<br /> to_msrq(devr-&gt;s0)-&gt;msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences<br /> the ERR_PTR and double-frees s0 on teardown.<br /> <br /> Fix by adding the same `goto unlock` in the s1 failure path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: Add limits to event and receive message requests<br /> <br /> The driver would just fetch events and receive messages until the<br /> BMC said it was done. To avoid issues with BMCs that never say they are<br /> done, add a limit of 10 fetches at a time.<br /> <br /> In addition, an si interface has an attn state it can return from the<br /> hardware which is supposed to cause a flag fetch to see if the driver<br /> needs to fetch events or message or a few other things. If the attn<br /> bit gets stuck, it&amp;#39;s a similar problem. So allow messages in between<br /> flag fetches so the driver itself doesn&amp;#39;t get stuck.<br /> <br /> This is a more general fix than the previous fix for the specific bad<br /> BMC, but should fix the more general issue of a BMC that won&amp;#39;t stop<br /> saying it has data.<br /> <br /> This has been there from the beginning of the driver. It&amp;#39;s not a bug<br /> per-se, but it is accounting for bugs in BMCs.