Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget<br /> <br /> In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget<br /> structure (pdev-&gt;gadget) was freed before its endpoints.<br /> The endpoints are linked via the ep_list in the gadget structure.<br /> Freeing the gadget first leaves dangling pointers in the endpoint list.<br /> When the endpoints are subsequently freed, this results in a use-after-free.<br /> <br /> Fix:<br /> By separating the usb_del_gadget_udc() operation into distinct "del" and<br /> "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the<br /> final release of the gadget structure with usb_put_gadget().<br /> <br /> A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure<br /> only after freeing endpoints").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Implement gettimex64 with -EOPNOTSUPP<br /> <br /> gve implemented a ptp_clock for sole use of do_aux_work at this time.<br /> ptp_clock_gettime() and ptp_sys_offset() assume every ptp_clock has<br /> implemented either gettimex64 or gettime64. Stub gettimex64 and return<br /> -EOPNOTSUPP to prevent NULL dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: validate skb length for unknown CC opcode<br /> <br /> In hci_cmd_complete_evt(), if the command complete event has an unknown<br /> opcode, we assume the first byte of the remaining skb-&gt;data contains the<br /> return status. However, parameter data has previously been pulled in<br /> hci_event_func(), which may leave the skb empty. If so, using skb-&gt;data[0]<br /> for the return status uses un-init memory.<br /> <br /> The fix is to check skb-&gt;len before using skb-&gt;data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: videobuf2: forbid remove_bufs when legacy fileio is active<br /> <br /> vb2_ioctl_remove_bufs() call manipulates queue internal buffer list,<br /> potentially overwriting some pointers used by the legacy fileio access<br /> mode. Forbid that ioctl when fileio is active to protect internal queue<br /> state between subsequent read/write calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: ensure no dirty metadata is written back for an fs with errors<br /> <br /> [BUG]<br /> During development of a minor feature (make sure all btrfs_bio::end_io()<br /> is called in task context), I noticed a crash in generic/388, where<br /> metadata writes triggered new works after btrfs_stop_all_workers().<br /> <br /> It turns out that it can even happen without any code modification, just<br /> using RAID5 for metadata and the same workload from generic/388 is going<br /> to trigger the use-after-free.<br /> <br /> [CAUSE]<br /> If btrfs hits an error, the fs is marked as error, no new<br /> transaction is allowed thus metadata is in a frozen state.<br /> <br /> But there are some metadata modifications before that error, and they are<br /> still in the btree inode page cache.<br /> <br /> Since there will be no real transaction commit, all those dirty folios<br /> are just kept as is in the page cache, and they can not be invalidated<br /> by invalidate_inode_pages2() call inside close_ctree(), because they are<br /> dirty.<br /> <br /> And finally after btrfs_stop_all_workers(), we call iput() on btree<br /> inode, which triggers writeback of those dirty metadata.<br /> <br /> And if the fs is using RAID56 metadata, this will trigger RMW and queue<br /> new works into rmw_workers, which is already stopped, causing warning<br /> from queue_work() and use-after-free.<br /> <br /> [FIX]<br /> Add a special handling for write_one_eb(), that if the fs is already in<br /> an error state, immediately mark the bbio as failure, instead of really<br /> submitting them.<br /> <br /> Then during close_ctree(), iput() will just discard all those dirty<br /> tree blocks without really writing them back, thus no more new jobs for<br /> already stopped-and-freed workqueues.<br /> <br /> The extra discard in write_one_eb() also acts as an extra safenet.<br /> E.g. the transaction abort is triggered by some extent/free space<br /> tree corruptions, and since extent/free space tree is already corrupted<br /> some tree blocks may be allocated where they shouldn&amp;#39;t be (overwriting<br /> existing tree blocks). In that case writing them back will further<br /> corrupting the fs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds<br /> <br /> Add bounds checking to prevent writes past framebuffer boundaries when<br /> rendering text near screen edges. Return early if the Y position is off-screen<br /> and clip image height to screen boundary. Break from the rendering loop if the<br /> X position is off-screen. When clipping image width to fit the screen, update<br /> the character count to match the clipped width to prevent buffer size<br /> mismatches.<br /> <br /> Without the character count update, bit_putcs_aligned and bit_putcs_unaligned<br /> receive mismatched parameters where the buffer is allocated for the clipped<br /> width but cnt reflects the original larger count, causing out-of-bounds writes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN<br /> <br /> p9_read_work() doesn&amp;#39;t set Rworksched and doesn&amp;#39;t do schedule_work(m-&gt;rq)<br /> if list_empty(&amp;m-&gt;req_list).<br /> <br /> However, if the pipe is full, we need to read more data and this used to<br /> work prior to commit aaec5a95d59615 ("pipe_read: don&amp;#39;t wake up the writer<br /> if the pipe is still full").<br /> <br /> p9_read_work() does p9_fd_read() -&gt; ... -&gt; anon_pipe_read() which (before<br /> the commit above) triggered the unnecessary wakeup. This wakeup calls<br /> p9_pollwake() which kicks p9_poll_workfn() -&gt; p9_poll_mux(), p9_poll_mux()<br /> will notice EPOLLIN and schedule_work(&amp;m-&gt;rq).<br /> <br /> This no longer happens after the optimization above, change p9_fd_request()<br /> to use p9_poll_mux() instead of only checking for EPOLLOUT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: fix xattr related buffer overflow...<br /> <br /> Willy Tarreau forwarded me a message from<br /> Disclosure with the following<br /> warning:<br /> <br /> &gt; The helper `xattr_key()` uses the pointer variable in the loop condition<br /> &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL<br /> &gt; (until it runs into unmapped memory), so the loop does not terminate on<br /> &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging<br /> &gt; the thread.<br /> <br /> I easily reproduced this with setfattr and getfattr, causing a kernel<br /> oops, hung user processes and corrupted orangefs files. Disclosure<br /> sent along a diff (not a patch) with a suggested fix, which I based<br /> this patch on.<br /> <br /> After xattr_key started working right, xfstest generic/069 exposed an<br /> xattr related memory leak that lead to OOM. xattr_key returns<br /> a hashed key. When adding xattrs to the orangefs xattr cache, orangefs<br /> used hash_add, a kernel hashing macro. hash_add also hashes the key using<br /> hash_log which resulted in additions to the xattr cache going to the wrong<br /> hash bucket. generic/069 tortures a single file and orangefs does a<br /> getattr for the xattr "security.capability" every time. Orangefs<br /> negative caches on xattrs which includes a kmalloc. Since adds to the<br /> xattr cache were going to the wrong bucket, every getattr for<br /> "security.capability" resulted in another kmalloc, none of which were<br /> ever freed.<br /> <br /> I changed the two uses of hash_add to hlist_add_head instead<br /> and the memory leak ceased and generic/069 quit throwing furniture.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: validate cluster allocation bits of the allocation bitmap<br /> <br /> syzbot created an exfat image with cluster bits not set for the allocation<br /> bitmap. exfat-fs reads and uses the allocation bitmap without checking<br /> this. The problem is that if the start cluster of the allocation bitmap<br /> is 6, cluster 6 can be allocated when creating a directory with mkdir.<br /> exfat zeros out this cluster in exfat_mkdir, which can delete existing<br /> entries. This can reallocate the allocated entries. In addition,<br /> the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.<br /> This patch adds exfat_test_bitmap_range to validate that clusters used for<br /> the allocation bitmap are correctly marked as in-use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix regbuf vector size truncation<br /> <br /> There is a report of io_estimate_bvec_size() truncating the calculated<br /> number of segments that leads to corruption issues. Check it doesn&amp;#39;t<br /> overflow "int"s used later. Rough but simple, can be improved on top.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix received length check in big packets<br /> <br /> Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length<br /> for big packets"), when guest gso is off, the allocated size for big<br /> packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on<br /> negotiated MTU. The number of allocated frags for big packets is stored<br /> in vi-&gt;big_packets_num_skbfrags.<br /> <br /> Because the host announced buffer length can be malicious (e.g. the host<br /> vhost_net driver&amp;#39;s get_rx_bufs is modified to announce incorrect<br /> length), we need a check in virtio_net receive path. Currently, the<br /> check is not adapted to the new change which can lead to NULL page<br /> pointer dereference in the below while loop when receiving length that<br /> is larger than the allocated one.<br /> <br /> This commit fixes the received length check corresponding to the new<br /> change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Don&amp;#39;t overflow during division for dirty tracking<br /> <br /> If pgshift is 63 then BITS_PER_TYPE(*bitmap-&gt;bitmap) * pgsize will overflow<br /> to 0 and this triggers divide by 0.<br /> <br /> In this case the index should just be 0, so reorganize things to divide<br /> by shift and avoid hitting any overflows.