Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: do not propagate page array emplacement errors as batch errors<br /> <br /> When fscrypt is enabled, move_dirty_folio_in_page_array() may fail<br /> because it needs to allocate bounce buffers to store the encrypted<br /> versions of each folio. Each folio beyond the first allocates its bounce<br /> buffer with GFP_NOWAIT. Failures are common (and expected) under this<br /> allocation mode; they should flush (not abort) the batch.<br /> <br /> However, ceph_process_folio_batch() uses the same `rc` variable for its<br /> own return code and for capturing the return codes of its routine calls;<br /> failing to reset `rc` back to 0 results in the error being propagated<br /> out to the main writeback loop, which cannot actually tolerate any<br /> errors here: once `ceph_wbc.pages` is allocated, it must be passed to<br /> ceph_submit_write() to be freed. If it survives until the next iteration<br /> (e.g. due to the goto being followed), ceph_allocate_page_array()&amp;#39;s<br /> BUG_ON() will oops the worker.<br /> <br /> Note that this failure mode is currently masked due to another bug<br /> (addressed next in this series) that prevents multiple encrypted folios<br /> from being selected for the same write.<br /> <br /> For now, just reset `rc` when redirtying the folio to prevent errors in<br /> move_dirty_folio_in_page_array() from propagating. Note that<br /> move_dirty_folio_in_page_array() is careful never to return errors on<br /> the first folio, so there is no need to check for that. After this<br /> change, ceph_process_folio_batch() no longer returns errors; its only<br /> remaining failure indicator is `locked_pages == 0`, which the caller<br /> already handles correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: delete attr leaf freemap entries when empty<br /> <br /> Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size<br /> underflow"), Brian Foster observed that it&amp;#39;s possible for a small<br /> freemap at the end of the end of the xattr entries array to experience<br /> a size underflow when subtracting the space consumed by an expansion of<br /> the entries array. There are only three freemap entries, which means<br /> that it is not a complete index of all free space in the leaf block.<br /> <br /> This code can leave behind a zero-length freemap entry with a nonzero<br /> base. Subsequent setxattr operations can increase the base up to the<br /> point that it overlaps with another freemap entry. This isn&amp;#39;t in and of<br /> itself a problem because the code in _leaf_add that finds free space<br /> ignores any freemap entry with zero size.<br /> <br /> However, there&amp;#39;s another bug in the freemap update code in _leaf_add,<br /> which is that it fails to update a freemap entry that begins midway<br /> through the xattr entry that was just appended to the array. That can<br /> result in the freemap containing two entries with the same base but<br /> different sizes (0 for the "pushed-up" entry, nonzero for the entry<br /> that&amp;#39;s actually tracking free space). A subsequent _leaf_add can then<br /> allocate xattr namevalue entries on top of the entries array, leading to<br /> data loss. But fixing that is for later.<br /> <br /> For now, eliminate the possibility of confusion by zeroing out the base<br /> of any freemap entry that has zero size. Because the freemap is not<br /> intended to be a complete index of free space, a subsequent failure to<br /> find any free space for a new xattr will trigger block compaction, which<br /> regenerates the freemap.<br /> <br /> It looks like this bug has been in the codebase for quite a long time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()<br /> <br /> On the receive path, __ioam6_fill_trace_data() uses trace-&gt;nodelen<br /> to decide how much data to write for each node. It trusts this field<br /> as-is from the incoming packet, with no consistency check against<br /> trace-&gt;type (the 24-bit field that tells which data items are<br /> present). A crafted packet can set nodelen=0 while setting type bits<br /> 0-21, causing the function to write ~100 bytes past the allocated<br /> region (into skb_shared_info), which corrupts adjacent heap memory<br /> and leads to a kernel panic.<br /> <br /> Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to<br /> derive the expected nodelen from the type field, and use it:<br /> <br /> - in ioam6_iptunnel.c (send path, existing validation) to replace<br /> the open-coded computation;<br /> - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose<br /> nodelen is inconsistent with the type field, before any data is<br /> written.<br /> <br /> Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they<br /> are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to<br /> 0xff1ffc00).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-async: Fix error handling on steps after finding a match<br /> <br /> Once an async connection is found to be matching with an fwnode, a<br /> sub-device may be registered (in case it wasn&amp;#39;t already), its bound<br /> operation is called, ancillary links are created, the async connection<br /> is added to the sub-device&amp;#39;s list of connections and removed from the<br /> global waiting connection list. Further on, the sub-device&amp;#39;s possible own<br /> notifier is searched for possible additional matches.<br /> <br /> Fix these specific issues:<br /> <br /> - If v4l2_async_match_notify() failed before the sub-notifier handling,<br /> the async connection was unbound and its entry removed from the<br /> sub-device&amp;#39;s async connection list. The latter part was also done in<br /> v4l2_async_match_notify().<br /> <br /> - The async connection&amp;#39;s sd field was only set after creating ancillary<br /> links in v4l2_async_match_notify(). It was however dereferenced in<br /> v4l2_async_unbind_subdev_one(), which was called on error path of<br /> v4l2_async_match_notify() failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_tcpmss: check remaining length before reading optlen<br /> <br /> Quoting reporter:<br /> In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads<br /> op[i+1] directly without validating the remaining option length.<br /> <br /> If the last byte of the option field is not EOL/NOP (0/1), the code attempts<br /> to index op[i+1]. In the case where i + 1 == optlen, this causes an<br /> out-of-bounds read, accessing memory past the optlen boundary<br /> (either reading beyond the stack buffer _opt or the<br /> following payload).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35<br /> <br /> [Why]<br /> A backport of the change made for DCN401 that addresses an issue where<br /> we turn off the PHY PLL when disabling TMDS output, which causes the<br /> OTG to remain stuck.<br /> <br /> The OTG being stuck can lead to a hang in the DCHVM&amp;#39;s ability to ACK<br /> invalidations when it thinks the HUBP is still on but it&amp;#39;s not receiving<br /> global sync.<br /> <br /> The transition to PLL_ON needs to be atomic as there&amp;#39;s no guarantee<br /> that the thread isn&amp;#39;t pre-empted or is able to complete before the<br /> IOMMU watchdog times out.<br /> <br /> [How]<br /> Backport the implementation from dcn401 back to dcn35.<br /> <br /> There&amp;#39;s a functional difference in when the eDP output is disabled in<br /> dcn401 code so we don&amp;#39;t want to utilize it directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix signededness bug in smb_direct_prepare_negotiation()<br /> <br /> smb_direct_prepare_negotiation() casts an unsigned __u32 value<br /> from sp-&gt;max_recv_size and req-&gt;preferred_send_size to a signed<br /> int before computing min_t(int, ...). A maliciously provided<br /> preferred_send_size of 0x80000000 will return as smaller than<br /> max_recv_size, and then be used to set the maximum allowed<br /> alowed receive size for the next message.<br /> <br /> By sending a second message with a large value (&gt;1420 bytes)<br /> the attacker can then achieve a heap buffer overflow.<br /> <br /> This fix replaces min_t(int, ...) with min_t(u32)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rnbd-srv: Zero the rsp buffer before using it<br /> <br /> Before using the data buffer to send back the response message, zero it<br /> completely. This prevents any stray bytes to be picked up by the client<br /> side when there the message is exchanged between different protocol<br /> versions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ccs: Avoid possible division by zero<br /> <br /> Calculating maximum M for scaler configuration involves dividing by<br /> MIN_X_OUTPUT_SIZE limit register&amp;#39;s value. Albeit the value is presumably<br /> non-zero, the driver was missing the check it in fact was. Fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sysfs: fix chip removal with GPIOs exported over sysfs<br /> <br /> Currently if we export a GPIO over sysfs and unbind the parent GPIO<br /> controller, the exported attribute will remain under /sys/class/gpio<br /> because once we remove the parent device, we can no longer associate the<br /> descriptor with it in gpiod_unexport() and never drop the final<br /> reference.<br /> <br /> Rework the teardown code: provide an unlocked variant of<br /> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken<br /> before unregistering the parent device itself. This is done to prevent<br /> any new exports happening before we unregister the device completely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx25821: Fix a resource leak in cx25821_dev_setup()<br /> <br /> Add release_mem_region() if ioremap() fails to release the memory<br /> region obtained by cx25821_get_resources().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode<br /> <br /> kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls<br /> netif_stop_queue() and netif_wake_queue(). These are TX queue flow<br /> control functions unrelated to RX multicast configuration.<br /> <br /> The premature netif_wake_queue() can re-enable TX while tx_urb is still<br /> in-flight, leading to a double usb_submit_urb() on the same URB:<br /> <br /> kaweth_start_xmit() {<br /> netif_stop_queue();<br /> usb_submit_urb(kaweth-&gt;tx_urb);<br /> }<br /> <br /> kaweth_set_rx_mode() {<br /> netif_stop_queue();<br /> netif_wake_queue(); // wakes TX queue before URB is done<br /> }<br /> <br /> kaweth_start_xmit() {<br /> netif_stop_queue();<br /> usb_submit_urb(kaweth-&gt;tx_urb); // URB submitted while active<br /> }<br /> <br /> This triggers the WARN in usb_submit_urb():<br /> <br /> "URB submitted while active"<br /> <br /> This is a similar class of bug fixed in rtl8150 by<br /> <br /> - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").<br /> <br /> Also kaweth_set_rx_mode() is already functionally broken, the<br /> real set_rx_mode action is performed by kaweth_async_set_rx_mode(),<br /> which in turn is not a no-op only at ndo_open() time.