Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: correctly decode TTLM with default link map<br /> <br /> TID-To-Link Mapping (TTLM) elements do not contain any link mapping<br /> presence indicator if a default mapping is used and parsing needs to be<br /> skipped.<br /> <br /> Note that access points should not explicitly report an advertised TTLM<br /> with a default mapping as that is the implied mapping if the element is<br /> not included, this is even the case when switching back to the default<br /> mapping. However, mac80211 would incorrectly parse the frame and would<br /> also read one byte beyond the end of the element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix memory leak in set_ssp_complete<br /> <br /> Fix memory leak in set_ssp_complete() where mgmt_pending_cmd structures<br /> are not freed after being removed from the pending list.<br /> <br /> Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") replaced<br /> mgmt_pending_foreach() calls with individual command handling but missed<br /> adding mgmt_pending_free() calls in both error and success paths of<br /> set_ssp_complete(). Other completion functions like set_le_complete()<br /> were fixed correctly in the same commit.<br /> <br /> This causes a memory leak of the mgmt_pending_cmd structure and its<br /> associated parameter data for each SSP command that completes.<br /> <br /> Add the missing mgmt_pending_free(cmd) calls in both code paths to fix<br /> the memory leak. Also fix the same issue in set_advertising_complete().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().<br /> <br /> syzbot reported various memory leaks related to NFC, struct<br /> nfc_llcp_sock, sk_buff, nfc_dev, etc. [0]<br /> <br /> The leading log hinted that nfc_llcp_send_ui_frame() failed<br /> to allocate skb due to sock_error(sk) being -ENXIO.<br /> <br /> ENXIO is set by nfc_llcp_socket_release() when struct<br /> nfc_llcp_local is destroyed by local_cleanup().<br /> <br /> The problem is that there is no synchronisation between<br /> nfc_llcp_send_ui_frame() and local_cleanup(), and skb<br /> could be put into local-&gt;tx_queue after it was purged in<br /> local_cleanup():<br /> <br /> CPU1 CPU2<br /> ---- ----<br /> nfc_llcp_send_ui_frame() local_cleanup()<br /> |- do { &amp;#39;<br /> |- pdu = nfc_alloc_send_skb(..., &amp;err)<br /> | .<br /> | |- nfc_llcp_socket_release(local, false, ENXIO);<br /> | |- skb_queue_purge(&amp;local-&gt;tx_queue); |<br /> | &amp;#39; |<br /> |- skb_queue_tail(&amp;local-&gt;tx_queue, pdu); |<br /> ... |<br /> |- pdu = nfc_alloc_send_skb(..., &amp;err) |<br /> ^._________________________________.&amp;#39;<br /> <br /> local_cleanup() is called for struct nfc_llcp_local only<br /> after nfc_llcp_remove_local() unlinks it from llcp_devices.<br /> <br /> If we hold local-&gt;tx_queue.lock then, we can synchronise<br /> the thread and nfc_llcp_send_ui_frame().<br /> <br /> Let&amp;#39;s do that and check list_empty(&amp;local-&gt;list) before<br /> queuing skb to local-&gt;tx_queue in nfc_llcp_send_ui_frame().<br /> <br /> [0]:<br /> [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)<br /> [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> BUG: memory leak<br /> unreferenced object 0xffff8881272f6800 (size 1024):<br /> comm "syz.0.17", pid 6096, jiffies 4294942766<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 &amp;#39;..@............<br /> backtrace (crc da58d84d):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> __do_kmalloc_node mm/slub.c:5645 [inline]<br /> __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239<br /> sk_alloc+0x36/0x360 net/core/sock.c:2295<br /> nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979<br /> llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044<br /> nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31<br /> __sock_create+0x1a9/0x340 net/socket.c:1605<br /> sock_create net/socket.c:1663 [inline]<br /> __sys_socket_create net/socket.c:1700 [inline]<br /> __sys_socket+0xb9/0x1a0 net/socket.c:1747<br /> __do_sys_socket net/socket.c:1761 [inline]<br /> __se_sys_socket net/socket.c:1759 [inline]<br /> __x64_sys_socket+0x1b/0x30 net/socket.c:1759<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810fbd9800 (size 240):<br /> comm "syz.0.17", pid 6096, jiffies 4294942850<br /> hex dump (first 32 bytes):<br /> 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......<br /> 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/&amp;#39;....<br /> backtrace (crc 6cc652b1):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336<br /> __alloc_skb+0x203/0x240 net/core/skbuff.c:660<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0x69/0x3f0 net/core/sk<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()<br /> <br /> Since GEM bo handles are u32 in the uapi and the internal implementation<br /> uses idr_alloc() which uses int ranges, passing a new handle larger than<br /> INT_MAX trivially triggers a kernel warning:<br /> <br /> idr_alloc():<br /> ...<br /> if (WARN_ON_ONCE(start

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix segmentation of forwarding fraglist GRO<br /> <br /> This patch enhances GSO segment handling by properly checking<br /> the SKB_GSO_DODGY flag for frag_list GSO packets, addressing<br /> low throughput issues observed when a station accesses IPv4<br /> servers via hotspots with an IPv6-only upstream interface.<br /> <br /> Specifically, it fixes a bug in GSO segmentation when forwarding<br /> GRO packets containing a frag_list. The function skb_segment_list<br /> cannot correctly process GRO skbs that have been converted by XLAT,<br /> since XLAT only translates the header of the head skb. Consequently,<br /> skbs in the frag_list may remain untranslated, resulting in protocol<br /> inconsistencies and reduced throughput.<br /> <br /> To address this, the patch explicitly sets the SKB_GSO_DODGY flag<br /> for GSO packets in XLAT&amp;#39;s IPv4/IPv6 protocol translation helpers<br /> (bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO<br /> packets as potentially modified after protocol translation. As a<br /> result, GSO segmentation will avoid using skb_segment_list and<br /> instead falls back to skb_segment for packets with the SKB_GSO_DODGY<br /> flag. This ensures that only safe and fully translated frag_list<br /> packets are processed by skb_segment_list, resolving protocol<br /> inconsistencies and improving throughput when forwarding GRO packets<br /> converted by XLAT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: core: fix race condition against transaction list<br /> <br /> The list of transaction is enumerated without acquiring card lock when<br /> processing AR response event. This causes a race condition bug when<br /> processing AT request completion event concurrently.<br /> <br /> This commit fixes the bug by put timer start for split transaction<br /> expiration into the scope of lock. The value of jiffies in card structure<br /> is referred before acquiring the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: virtuser: fix UAF in configfs release path<br /> <br /> The gpio-virtuser configfs release path uses guard(mutex) to protect<br /> the device structure. However, the device is freed before the guard<br /> cleanup runs, causing mutex_unlock() to operate on freed memory.<br /> <br /> Specifically, gpio_virtuser_device_config_group_release() destroys<br /> the mutex and frees the device while still inside the guard(mutex)<br /> scope. When the function returns, the guard cleanup invokes<br /> mutex_unlock(&amp;dev-&gt;lock), resulting in a slab use-after-free.<br /> <br /> Limit the mutex lifetime by using a scoped_guard() only around the<br /> activation check, so that the lock is released before mutex_destroy()<br /> and kfree() are called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not strictly require dirty metadata threshold for metadata writepages<br /> <br /> [BUG]<br /> There is an internal report that over 1000 processes are<br /> waiting at the io_schedule_timeout() of balance_dirty_pages(), causing<br /> a system hang and trigger a kernel coredump.<br /> <br /> The kernel is v6.4 kernel based, but the root problem still applies to<br /> any upstream kernel before v6.18.<br /> <br /> [CAUSE]<br /> From Jan Kara for his wisdom on the dirty page balance behavior first.<br /> <br /> This cgroup dirty limit was what was actually playing the role here<br /> because the cgroup had only a small amount of memory and so the dirty<br /> limit for it was something like 16MB.<br /> <br /> Dirty throttling is responsible for enforcing that nobody can dirty<br /> (significantly) more dirty memory than there&amp;#39;s dirty limit. Thus when<br /> a task is dirtying pages it periodically enters into balance_dirty_pages()<br /> and we let it sleep there to slow down the dirtying.<br /> <br /> When the system is over dirty limit already (either globally or within<br /> a cgroup of the running task), we will not let the task exit from<br /> balance_dirty_pages() until the number of dirty pages drops below the<br /> limit.<br /> <br /> So in this particular case, as I already mentioned, there was a cgroup<br /> with relatively small amount of memory and as a result with dirty limit<br /> set at 16MB. A task from that cgroup has dirtied about 28MB worth of<br /> pages in btrfs btree inode and these were practically the only dirty<br /> pages in that cgroup.<br /> <br /> So that means the only way to reduce the dirty pages of that cgroup is<br /> to writeback the dirty pages of btrfs btree inode, and only after that<br /> those processes can exit balance_dirty_pages().<br /> <br /> Now back to the btrfs part, btree_writepages() is responsible for<br /> writing back dirty btree inode pages.<br /> <br /> The problem here is, there is a btrfs internal threshold that if the<br /> btree inode&amp;#39;s dirty bytes are below the 32M threshold, it will not<br /> do any writeback.<br /> <br /> This behavior is to batch as much metadata as possible so we won&amp;#39;t write<br /> back those tree blocks and then later re-COW them again for another<br /> modification.<br /> <br /> This internal 32MiB is higher than the existing dirty page size (28MiB),<br /> meaning no writeback will happen, causing a deadlock between btrfs and<br /> cgroup:<br /> <br /> - Btrfs doesn&amp;#39;t want to write back btree inode until more dirty pages<br /> <br /> - Cgroup/MM doesn&amp;#39;t want more dirty pages for btrfs btree inode<br /> Thus any process touching that btree inode is put into sleep until<br /> the number of dirty pages is reduced.<br /> <br /> Thanks Jan Kara a lot for the analysis of the root cause.<br /> <br /> [ENHANCEMENT]<br /> Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the<br /> btree_inode"), btrfs btree inode pages will only be charged to the root<br /> cgroup which should have a much larger limit than btrfs&amp;#39; 32MiB<br /> threshold.<br /> So it should not affect newer kernels.<br /> <br /> But for all current LTS kernels, they are all affected by this problem,<br /> and backporting the whole AS_KERNEL_FILE may not be a good idea.<br /> <br /> Even for newer kernels I still think it&amp;#39;s a good idea to get<br /> rid of the internal threshold at btree_writepages(), since for most cases<br /> cgroup/MM has a better view of full system memory usage than btrfs&amp;#39; fixed<br /> threshold.<br /> <br /> For internal callers using btrfs_btree_balance_dirty() since that<br /> function is already doing internal threshold check, we don&amp;#39;t need to<br /> bother them.<br /> <br /> But for external callers of btree_writepages(), just respect their<br /> requests and write back whatever they want, ignoring the internal<br /> btrfs threshold to avoid such deadlock on btree inode dirty page<br /> balancing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efivarfs: fix error propagation in efivar_entry_get()<br /> <br /> efivar_entry_get() always returns success even if the underlying<br /> __efivar_entry_get() fails, masking errors.<br /> <br /> This may result in uninitialized heap memory being copied to userspace<br /> in the efivarfs_file_read() path.<br /> <br /> Fix it by returning the error from __efivar_entry_get().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): fix error message<br /> <br /> Sinc commit 79a6d1bfe114 ("can: gs_usb: gs_usb_receive_bulk_callback():<br /> unanchor URL on usb_submit_urb() error") a failing resubmit URB will print<br /> an info message.<br /> <br /> In the case of a short read where netdev has not yet been assigned,<br /> initialize as NULL to avoid dereferencing an undefined value. Also report<br /> the error value of the failed resubmit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference<br /> <br /> There is a race condition in nvmet_bio_done() that can cause a NULL<br /> pointer dereference in blk_cgroup_bio_start():<br /> <br /> 1. nvmet_bio_done() is called when a bio completes<br /> 2. nvmet_req_complete() is called, which invokes req-&gt;ops-&gt;queue_response(req)<br /> 3. The queue_response callback can re-queue and re-submit the same request<br /> 4. The re-submission reuses the same inline_bio from nvmet_req<br /> 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)<br /> invokes bio_uninit() for inline_bio, which sets bio-&gt;bi_blkg to NULL<br /> 6. The re-submitted bio enters submit_bio_noacct_nocheck()<br /> 7. blk_cgroup_bio_start() dereferences bio-&gt;bi_blkg, causing a crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:blk_cgroup_bio_start+0x10/0xd0<br /> Call Trace:<br /> submit_bio_noacct_nocheck+0x44/0x250<br /> nvmet_bdev_execute_rw+0x254/0x370 [nvmet]<br /> process_one_work+0x193/0x3c0<br /> worker_thread+0x281/0x3a0<br /> <br /> Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()<br /> BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before<br /> the request can be re-submitted, preventing the race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix the folio leak on S390 hardware acceleration<br /> <br /> [BUG]<br /> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration<br /> buffer preparation"), we no longer release the folio of the page cache<br /> of folio returned by btrfs_compress_filemap_get_folio() for S390<br /> hardware acceleration path.<br /> <br /> [CAUSE]<br /> Before that commit, we call kumap_local() and folio_put() after handling<br /> each folio.<br /> <br /> Although the timing is not ideal (it release previous folio at the<br /> beginning of the loop, and rely on some extra cleanup out of the loop),<br /> it at least handles the folio release correctly.<br /> <br /> Meanwhile the refactored code is easier to read, it lacks the call to<br /> release the filemap folio.<br /> <br /> [FIX]<br /> Add the missing folio_put() for copy_data_into_buffer().