Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: i740fb: Check the argument of i740_calc_vclk()<br /> <br /> Since the user can control the arguments of the ioctl() from the user<br /> space, under special arguments that may result in a divide-by-zero bug.<br /> <br /> If the user provides an improper &amp;#39;pixclock&amp;#39; value that makes the argumet<br /> of i740_calc_vclk() less than &amp;#39;I740_RFREQ_FIX&amp;#39;, it will cause a<br /> divide-by-zero bug in:<br /> drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));<br /> <br /> The following log can reveal it:<br /> <br /> divide error: 0000 [#1] PREEMPT SMP KASAN PTI<br /> RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]<br /> RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]<br /> RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742<br /> Call Trace:<br /> fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189<br /> <br /> Fix this by checking the argument of i740_calc_vclk() first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_tproxy: restrict to prerouting hook<br /> <br /> TPROXY is only allowed from prerouting, but nft_tproxy doesn&amp;#39;t check this.<br /> This fixes a crash (null dereference) when using tproxy from e.g. output.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: fix stuck flows on cleanup due to pending work<br /> <br /> To clear the flow table on flow table free, the following sequence<br /> normally happens in order:<br /> <br /> 1) gc_step work is stopped to disable any further stats/del requests.<br /> 2) All flow table entries are set to teardown state.<br /> 3) Run gc_step which will queue HW del work for each flow table entry.<br /> 4) Waiting for the above del work to finish (flush).<br /> 5) Run gc_step again, deleting all entries from the flow table.<br /> 6) Flow table is freed.<br /> <br /> But if a flow table entry already has pending HW stats or HW add work<br /> step 3 will not queue HW del work (it will be skipped), step 4 will wait<br /> for the pending add/stats to finish, and step 5 will queue HW del work<br /> which might execute after freeing of the flow table.<br /> <br /> To fix the above, this patch flushes the pending work, then it sets the<br /> teardown flag to all flows in the flowtable and it forces a garbage<br /> collector run to queue work to remove the flows from hardware, then it<br /> flushes this new pending work and (finally) it forces another garbage<br /> collector run to remove the entry from the software flowtable.<br /> <br /> Stack trace:<br /> [47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460<br /> [47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704<br /> [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2<br /> [47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)<br /> [47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table]<br /> [47773.889727] Call Trace:<br /> [47773.890214] dump_stack+0xbb/0x107<br /> [47773.890818] print_address_description.constprop.0+0x18/0x140<br /> [47773.892990] kasan_report.cold+0x7c/0xd8<br /> [47773.894459] kasan_check_range+0x145/0x1a0<br /> [47773.895174] down_read+0x99/0x460<br /> [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table]<br /> [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table]<br /> [47773.913372] process_one_work+0x8ac/0x14e0<br /> [47773.921325]<br /> [47773.921325] Allocated by task 592159:<br /> [47773.922031] kasan_save_stack+0x1b/0x40<br /> [47773.922730] __kasan_kmalloc+0x7a/0x90<br /> [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct]<br /> [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct]<br /> [47773.925207] tcf_action_init_1+0x45b/0x700<br /> [47773.925987] tcf_action_init+0x453/0x6b0<br /> [47773.926692] tcf_exts_validate+0x3d0/0x600<br /> [47773.927419] fl_change+0x757/0x4a51 [cls_flower]<br /> [47773.928227] tc_new_tfilter+0x89a/0x2070<br /> [47773.936652]<br /> [47773.936652] Freed by task 543704:<br /> [47773.937303] kasan_save_stack+0x1b/0x40<br /> [47773.938039] kasan_set_track+0x1c/0x30<br /> [47773.938731] kasan_set_free_info+0x20/0x30<br /> [47773.939467] __kasan_slab_free+0xe7/0x120<br /> [47773.940194] slab_free_freelist_hook+0x86/0x190<br /> [47773.941038] kfree+0xce/0x3a0<br /> [47773.941644] tcf_ct_flow_table_cleanup_work<br /> <br /> Original patch description and stack trace by Paul Blakey.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix space cache corruption and potential double allocations<br /> <br /> When testing space_cache v2 on a large set of machines, we encountered a<br /> few symptoms:<br /> <br /> 1. "unable to add free space :-17" (EEXIST) errors.<br /> 2. Missing free space info items, sometimes caught with a "missing free<br /> space info for X" error.<br /> 3. Double-accounted space: ranges that were allocated in the extent tree<br /> and also marked as free in the free space tree, ranges that were<br /> marked as allocated twice in the extent tree, or ranges that were<br /> marked as free twice in the free space tree. If the latter made it<br /> onto disk, the next reboot would hit the BUG_ON() in<br /> add_new_free_space().<br /> 4. On some hosts with no on-disk corruption or error messages, the<br /> in-memory space cache (dumped with drgn) disagreed with the free<br /> space tree.<br /> <br /> All of these symptoms have the same underlying cause: a race between<br /> caching the free space for a block group and returning free space to the<br /> in-memory space cache for pinned extents causes us to double-add a free<br /> range to the space cache. This race exists when free space is cached<br /> from the free space tree (space_cache=v2) or the extent tree<br /> (nospace_cache, or space_cache=v1 if the cache needs to be regenerated).<br /> struct btrfs_block_group::last_byte_to_unpin and struct<br /> btrfs_block_group::progress are supposed to protect against this race,<br /> but commit d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when<br /> waiting for a transaction commit") subtly broke this by allowing<br /> multiple transactions to be unpinning extents at the same time.<br /> <br /> Specifically, the race is as follows:<br /> <br /> 1. An extent is deleted from an uncached block group in transaction A.<br /> 2. btrfs_commit_transaction() is called for transaction A.<br /> 3. btrfs_run_delayed_refs() -&gt; __btrfs_free_extent() runs the delayed<br /> ref for the deleted extent.<br /> 4. __btrfs_free_extent() -&gt; do_free_extent_accounting() -&gt;<br /> add_to_free_space_tree() adds the deleted extent back to the free<br /> space tree.<br /> 5. do_free_extent_accounting() -&gt; btrfs_update_block_group() -&gt;<br /> btrfs_cache_block_group() queues up the block group to get cached.<br /> block_group-&gt;progress is set to block_group-&gt;start.<br /> 6. btrfs_commit_transaction() for transaction A calls<br /> switch_commit_roots(). It sets block_group-&gt;last_byte_to_unpin to<br /> block_group-&gt;progress, which is block_group-&gt;start because the block<br /> group hasn&amp;#39;t been cached yet.<br /> 7. The caching thread gets to our block group. Since the commit roots<br /> were already switched, load_free_space_tree() sees the deleted extent<br /> as free and adds it to the space cache. It finishes caching and sets<br /> block_group-&gt;progress to U64_MAX.<br /> 8. btrfs_commit_transaction() advances transaction A to<br /> TRANS_STATE_SUPER_COMMITTED.<br /> 9. fsync calls btrfs_commit_transaction() for transaction B. Since<br /> transaction A is already in TRANS_STATE_SUPER_COMMITTED and the<br /> commit is for fsync, it advances.<br /> 10. btrfs_commit_transaction() for transaction B calls<br /> switch_commit_roots(). This time, the block group has already been<br /> cached, so it sets block_group-&gt;last_byte_to_unpin to U64_MAX.<br /> 11. btrfs_commit_transaction() for transaction A calls<br /> btrfs_finish_extent_commit(), which calls unpin_extent_range() for<br /> the deleted extent. It sees last_byte_to_unpin set to U64_MAX (by<br /> transaction B!), so it adds the deleted extent to the space cache<br /> again!<br /> <br /> This explains all of our symptoms above:<br /> <br /> * If the sequence of events is exactly as described above, when the free<br /> space is re-added in step 11, it will fail with EEXIST.<br /> * If another thread reallocates the deleted extent in between steps 7<br /> and 11, then step 11 will silently re-add that space to the space<br /> cache as free even though it is actually allocated. Then, if that<br /> space is allocated *again*, the free space tree will be corrupted<br /> (namely, the wrong item will be deleted).<br /> * If we don&amp;#39;t catch this free space tree corr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix locking in rxrpc&amp;#39;s sendmsg<br /> <br /> Fix three bugs in the rxrpc&amp;#39;s sendmsg implementation:<br /> <br /> (1) rxrpc_new_client_call() should release the socket lock when returning<br /> an error from rxrpc_get_call_slot().<br /> <br /> (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex<br /> held in the event that we&amp;#39;re interrupted by a signal whilst waiting<br /> for tx space on the socket or relocking the call mutex afterwards.<br /> <br /> Fix this by: (a) moving the unlock/lock of the call mutex up to<br /> rxrpc_send_data() such that the lock is not held around all of<br /> rxrpc_wait_for_tx_window*() and (b) indicating to higher callers<br /> whether we&amp;#39;re return with the lock dropped. Note that this means<br /> recvmsg() will not block on this call whilst we&amp;#39;re waiting.<br /> <br /> (3) After dropping and regaining the call mutex, rxrpc_send_data() needs<br /> to go and recheck the state of the tx_pending buffer and the<br /> tx_total_len check in case we raced with another sendmsg() on the same<br /> call.<br /> <br /> Thinking on this some more, it might make sense to have different locks for<br /> sendmsg() and recvmsg(). There&amp;#39;s probably no need to make recvmsg() wait<br /> for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating<br /> that a call is dead before a sendmsg() to that call returns - but that can<br /> currently happen anyway.<br /> <br /> Without fix (2), something like the following can be induced:<br /> <br /> WARNING: bad unlock balance detected!<br /> 5.16.0-rc6-syzkaller #0 Not tainted<br /> -------------------------------------<br /> syz-executor011/3597 is trying to release lock (&amp;call-&gt;user_mutex) at:<br /> [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748<br /> but there are no more locks to release!<br /> <br /> other info that might help us debug this:<br /> no locks held by syz-executor011/3597.<br /> ...<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]<br /> __lock_release kernel/locking/lockdep.c:5306 [inline]<br /> lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657<br /> __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900<br /> rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748<br /> rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2463<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lantiq_xrx200: restore buffer if memory allocation failed<br /> <br /> In a situation where memory allocation fails, an invalid buffer address<br /> is stored. When this descriptor is used again, the system panics in the<br /> build_skb() function when accessing memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()<br /> <br /> In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if<br /> the path is invalid. In this case, btrfs_get_dev_args_from_path()<br /> returns directly without freeing args-&gt;uuid and args-&gt;fsid allocated<br /> before, which causes memory leak.<br /> <br /> To fix these possible leaks, when btrfs_get_bdev_and_sb() fails,<br /> btrfs_put_dev_args_from_path() is called to clean up the memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> writeback: avoid use-after-free after removing device<br /> <br /> When a disk is removed, bdi_unregister gets called to stop further<br /> writeback and wait for associated delayed work to complete. However,<br /> wb_inode_writeback_end() may schedule bandwidth estimation dwork after<br /> this has completed, which can result in the timer attempting to access the<br /> just freed bdi_writeback.<br /> <br /> Fix this by checking if the bdi_writeback is alive, similar to when<br /> scheduling writeback work.<br /> <br /> Since this requires wb-&gt;work_lock, and wb_inode_writeback_end() may get<br /> called from interrupt, switch wb-&gt;work_lock to an irqsafe lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem<br /> <br /> The vmemmap pages is marked by kmemleak when allocated from memblock. <br /> Remove it from kmemleak when freeing the page. Otherwise, when we reuse<br /> the page, kmemleak may report such an error and then stop working.<br /> <br /> kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing)<br /> kmemleak: Kernel memory leak detector disabled<br /> kmemleak: Object 0xffff98fb6be00000 (size 335544320):<br /> kmemleak: comm "swapper", pid 0, jiffies 4294892296<br /> kmemleak: min_count = 0<br /> kmemleak: count = 0<br /> kmemleak: flags = 0x1<br /> kmemleak: checksum = 0<br /> kmemleak: backtrace:

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390: fix double free of GS and RI CBs on fork() failure<br /> <br /> The pointers for guarded storage and runtime instrumentation control<br /> blocks are stored in the thread_struct of the associated task. These<br /> pointers are initially copied on fork() via arch_dup_task_struct()<br /> and then cleared via copy_thread() before fork() returns. If fork()<br /> happens to fail after the initial task dup and before copy_thread(),<br /> the newly allocated task and associated thread_struct memory are<br /> freed via free_task() -&gt; arch_release_task_struct(). This results in<br /> a double free of the guarded storage and runtime info structs<br /> because the fields in the failed task still refer to memory<br /> associated with the source task.<br /> <br /> This problem can manifest as a BUG_ON() in set_freepointer() (with<br /> CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)<br /> when running trinity syscall fuzz tests on s390x. To avoid this<br /> problem, clear the associated pointer fields in<br /> arch_dup_task_struct() immediately after the new task is copied.<br /> Note that the RI flag is still cleared in copy_thread() because it<br /> resides in thread stack memory and that is where stack info is<br /> copied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/privcmd: fix error exit of privcmd_ioctl_dm_op()<br /> <br /> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()<br /> potentially with pages being NULL, leading to a NULL dereference.<br /> <br /> Additionally lock_pages() doesn&amp;#39;t check for pin_user_pages_fast()<br /> having been completely successful, resulting in potentially not<br /> locking all pages into memory. This could result in sporadic failures<br /> when using the related memory in user mode.<br /> <br /> Fix all of that by calling unlock_pages() always with the real number<br /> of pinned pages, which will be zero in case pages being NULL, and by<br /> checking the number of pages pinned by pin_user_pages_fast() matching<br /> the expected number of pages.