Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix fault in reweight_entity<br /> <br /> Syzbot found a GPF in reweight_entity. This has been bisected to<br /> commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid<br /> sched_task_group")<br /> <br /> There is a race between sched_post_fork() and setpriority(PRIO_PGRP)<br /> within a thread group that causes a null-ptr-deref in<br /> reweight_entity() in CFS. The scenario is that the main process spawns<br /> number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),<br /> wait, and exit. For each of the new threads the copy_process() gets<br /> invoked, which adds the new task_struct and calls sched_post_fork()<br /> for it.<br /> <br /> In the above scenario there is a possibility that<br /> setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread<br /> in the group that is just being created by copy_process(), and for<br /> which the sched_post_fork() has not been executed yet. This will<br /> trigger a null pointer dereference in reweight_entity(), as it will<br /> try to access the run queue pointer, which hasn&amp;#39;t been set.<br /> <br /> Before the mentioned change the cfs_rq pointer for the task has been<br /> set in sched_fork(), which is called much earlier in copy_process(),<br /> before the new task is added to the thread_group. Now it is done in<br /> the sched_post_fork(), which is called after that. To fix the issue<br /> the remove the update_load param from the update_load param() function<br /> and call reweight_task() only if the task flag doesn&amp;#39;t have the<br /> TASK_NEW flag set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fix oops caused by irqsoff latency tracer<br /> <br /> The trace_hardirqs_{on,off}() require the caller to setup frame pointer<br /> properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.<br /> __builtin_return_address(1)) to acquire caller info. If the $fp is used<br /> for other purpose, the code generated this macro (as below) could trigger<br /> memory access fault.<br /> <br /> 0xffffffff8011510e : ld a1,-16(s0)<br /> 0xffffffff80115112 : ld s2,-8(a1) #

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: prevent copying too big compressed lzo segment<br /> <br /> Compressed length can be corrupted to be a lot larger than memory<br /> we have allocated for buffer.<br /> This will cause memcpy in copy_compressed_segment to write outside<br /> of allocated memory.<br /> <br /> This mostly results in stuck read syscall but sometimes when using<br /> btrfs send can get #GP<br /> <br /> kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI<br /> kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12<br /> kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]<br /> kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs<br /> Code starting with the faulting instruction<br /> ===========================================<br /> 0:* 48 8b 06 mov (%rsi),%rax

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: int340x: fix memory leak in int3400_notify()<br /> <br /> It is easy to hit the below memory leaks in my TigerLake platform:<br /> <br /> unreferenced object 0xffff927c8b91dbc0 (size 32):<br /> comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)<br /> hex dump (first 32 bytes):<br /> 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The<br /> 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.<br /> backtrace:<br /> [] __kmalloc_track_caller+0x2fe/0x4a0<br /> [] kvasprintf+0x65/0xd0<br /> [] kasprintf+0x4e/0x70<br /> [] int3400_notify+0x82/0x120 [int3400_thermal]<br /> [] acpi_ev_notify_dispatch+0x54/0x71<br /> [] acpi_os_execute_deferred+0x17/0x30<br /> [] process_one_work+0x21a/0x3f0<br /> [] worker_thread+0x4a/0x3b0<br /> [] kthread+0xfd/0x130<br /> [] ret_from_fork+0x1f/0x30<br /> <br /> Fix it by calling kfree() accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Do not change route.addr.src_addr outside state checks<br /> <br /> If the state is not idle then resolve_prepare_src() should immediately<br /> fail and no change to global state should happen. However, it<br /> unconditionally overwrites the src_addr trying to build a temporary any<br /> address.<br /> <br /> For instance if the state is already RDMA_CM_LISTEN then this will corrupt<br /> the src_addr and would cause the test in cma_cancel_operation():<br /> <br /> if (cma_any_addr(cma_src_addr(id_priv)) &amp;&amp; !id_priv-&gt;cma_dev)<br /> <br /> Which would manifest as this trace from syzkaller:<br /> <br /> BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26<br /> Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204<br /> <br /> CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:79 [inline]<br /> dump_stack+0x141/0x1d7 lib/dump_stack.c:120<br /> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232<br /> __kasan_report mm/kasan/report.c:399 [inline]<br /> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416<br /> __list_add_valid+0x93/0xa0 lib/list_debug.c:26<br /> __list_add include/linux/list.h:67 [inline]<br /> list_add_tail include/linux/list.h:100 [inline]<br /> cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]<br /> rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751<br /> ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102<br /> ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732<br /> vfs_write+0x28e/0xa30 fs/read_write.c:603<br /> ksys_write+0x1ee/0x250 fs/read_write.c:658<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> This is indicating that an rdma_id_private was destroyed without doing<br /> cma_cancel_listens().<br /> <br /> Instead of trying to re-use the src_addr memory to indirectly create an<br /> any address derived from the dst build one explicitly on the stack and<br /> bind to that as any other normal flow would do. rdma_bind_addr() will copy<br /> it over the src_addr once it knows the state is valid.<br /> <br /> This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change<br /> route.addr.src_addr.ss_family")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: get rid of warning on transaction commit when using flushoncommit<br /> <br /> When using the flushoncommit mount option, during almost every transaction<br /> commit we trigger a warning from __writeback_inodes_sb_nr():<br /> <br /> $ cat fs/fs-writeback.c:<br /> (...)<br /> static void __writeback_inodes_sb_nr(struct super_block *sb, ...<br /> {<br /> (...)<br /> WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));<br /> (...)<br /> }<br /> (...)<br /> <br /> The trace produced in dmesg looks like the following:<br /> <br /> [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3<br /> [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif<br /> [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186<br /> [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3<br /> [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)<br /> [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246<br /> [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000<br /> [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50<br /> [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000<br /> [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488<br /> [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460<br /> [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000<br /> [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0<br /> [947.571072] Call Trace:<br /> [947.572354] <br /> [947.573266] btrfs_commit_transaction+0x1f1/0x998<br /> [947.576785] ? start_transaction+0x3ab/0x44e<br /> [947.579867] ? schedule_timeout+0x8a/0xdd<br /> [947.582716] transaction_kthread+0xe9/0x156<br /> [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407<br /> [947.590104] kthread+0x131/0x139<br /> [947.592168] ? set_kthread_struct+0x32/0x32<br /> [947.595174] ret_from_fork+0x22/0x30<br /> [947.597561] <br /> [947.598553] ---[ end trace 644721052755541c ]---<br /> <br /> This is because we started using writeback_inodes_sb() to flush delalloc<br /> when committing a transaction (when using -o flushoncommit), in order to<br /> avoid deadlocks with filesystem freeze operations. This change was made<br /> by commit ce8ea7cc6eb313 ("btrfs: don&amp;#39;t call btrfs_start_delalloc_roots<br /> in flushoncommit"). After that change we started producing that warning,<br /> and every now and then a user reports this since the warning happens too<br /> often, it spams dmesg/syslog, and a user is unsure if this reflects any<br /> problem that might compromise the filesystem&amp;#39;s reliability.<br /> <br /> We can not just lock the sb-&gt;s_umount semaphore before calling<br /> writeback_inodes_sb(), because that would at least deadlock with<br /> filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()<br /> is called while we are holding that semaphore in write mode, and that can<br /> trigger a transaction commit, resulting in a deadlock. It would also<br /> trigger the same type of deadlock in the unmount path. Possibly, it could<br /> also introduce some other locking dependencies that lockdep would report.<br /> <br /> To fix this call try_to_writeback_inodes_sb() instead of<br /> writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount<br /> and then will only call writeback_inodes_sb() if it was able to lock it.<br /> This is fine because the cases where it can&amp;#39;t read lock sb-&gt;s_umount<br /> are during a filesystem unmount or during a filesystem freeze - in those<br /> cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which<br /> calls writeback_inodes_sb(). In other words, in all cases where we can&amp;#39;t<br /> take a read lock on sb-&gt;s_umount, writeback is already being triggered<br /> elsewhere.<br /> <br /> An alternative would be to call btrfs_start_delalloc_roots() with a<br /> number of pages different from LONG_MAX, for example matching the number<br /> of delalloc bytes we currently have, in <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: free reset-work-item when flushing<br /> <br /> Fix a tiny memory leak when flushing the reset work queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Correctly set DATA_FIN timeout when number of retransmits is large<br /> <br /> Syzkaller with UBSAN uncovered a scenario where a large number of<br /> DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN<br /> timeout calculation:<br /> <br /> ================================================================================<br /> UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29<br /> shift exponent 32 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: events mptcp_worker<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 /> ubsan_epilogue+0xb/0x5a lib/ubsan.c:151<br /> __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330<br /> mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]<br /> __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445<br /> mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528<br /> process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307<br /> worker_thread+0x95/0xe10 kernel/workqueue.c:2454<br /> kthread+0x2f4/0x3b0 kernel/kthread.c:377<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> ================================================================================<br /> <br /> This change limits the maximum timeout by limiting the size of the<br /> shift, which keeps all intermediate values in-bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> auxdisplay: lcd2s: Fix memory leak in -&gt;remove()<br /> <br /> Once allocated the struct lcd2s_data is never freed.<br /> Fix the memory leak by switching to devm_kzalloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()<br /> <br /> During driver initialization, the pointer of card info, i.e. the<br /> variable &amp;#39;ci&amp;#39; is required. However, the definition of<br /> &amp;#39;com20020pci_id_table&amp;#39; reveals that this field is empty for some<br /> devices, which will cause null pointer dereference when initializing<br /> these devices.<br /> <br /> The following log reveals it:<br /> <br /> [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]<br /> [ 3.975181] Call Trace:<br /> [ 3.976208] local_pci_probe+0x13f/0x210<br /> [ 3.977248] pci_device_probe+0x34c/0x6d0<br /> [ 3.977255] ? pci_uevent+0x470/0x470<br /> [ 3.978265] really_probe+0x24c/0x8d0<br /> [ 3.978273] __driver_probe_device+0x1b3/0x280<br /> [ 3.979288] driver_probe_device+0x50/0x370<br /> <br /> Fix this by checking whether the &amp;#39;ci&amp;#39; is a null pointer first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix connection leak<br /> <br /> There&amp;#39;s a potential leak issue under following execution sequence :<br /> <br /> smc_release smc_connect_work<br /> if (sk-&gt;sk_state == SMC_INIT)<br /> send_clc_confirim<br /> tcp_abort();<br /> ...<br /> sk.sk_state = SMC_ACTIVE<br /> smc_close_active<br /> switch(sk-&gt;sk_state) {<br /> ...<br /> case SMC_ACTIVE:<br /> smc_close_final()<br /> // then wait peer closed<br /> <br /> Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are<br /> still in the tcp send buffer, in which case our connection token cannot<br /> be delivered to the server side, which means that we cannot get a<br /> passive close message at all. Therefore, it is impossible for the to be<br /> disconnected at all.<br /> <br /> This patch tries a very simple way to avoid this issue, once the state<br /> has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the<br /> smc connection, considering that the state is SMC_INIT before<br /> tcp_abort(), abandoning the complete disconnection process should not<br /> cause too much problem.<br /> <br /> In fact, this problem may exist as long as the CLC CONFIRM message is<br /> not received by the server. Whether a timer should be added after<br /> smc_close_final() needs to be discussed in the future. But even so, this<br /> patch provides a faster release for connection in above case, it should<br /> also be valuable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: ensure we call ipv6_mc_down() at most once<br /> <br /> There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:<br /> either the network device is actually going down, or IPv6 was disabled<br /> on the interface.<br /> <br /> If either of them stays down while the other is toggled, we repeatedly<br /> call the code for NETDEV_DOWN, including ipv6_mc_down(), while never<br /> calling the corresponding ipv6_mc_up() in between. This will cause a<br /> new entry in idev-&gt;mc_tomb to be allocated for each multicast group<br /> the interface is subscribed to, which in turn leaks one struct ifmcaddr6<br /> per nontrivial multicast group the interface is subscribed to.<br /> <br /> The following reproducer will leak at least $n objects:<br /> <br /> ip addr add ff2e::4242/32 dev eth0 autojoin<br /> sysctl -w net.ipv6.conf.eth0.disable_ipv6=1<br /> for i in $(seq 1 $n); do<br /> ip link set up eth0; ip link set down eth0<br /> done<br /> <br /> Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the<br /> sysctl net.ipv6.conf.eth0.forwarding to 1 (=&gt; subscribing to ff02::2)<br /> can also be used to create a nontrivial idev-&gt;mc_list, which will the<br /> leak objects with the right up-down-sequence.<br /> <br /> Based on both sources for NETDEV_DOWN events the interface IPv6 state<br /> should be considered:<br /> <br /> - not ready if the network interface is not ready OR IPv6 is disabled<br /> for it<br /> - ready if the network interface is ready AND IPv6 is enabled for it<br /> <br /> The functions ipv6_mc_up() and ipv6_down() should only be run when this<br /> state changes.<br /> <br /> Implement this by remembering when the IPv6 state is ready, and only<br /> run ipv6_mc_down() if it actually changed from ready to not ready.<br /> <br /> The other direction (not ready -&gt; ready) already works correctly, as:<br /> <br /> - the interface notification triggered codepath for NETDEV_UP /<br /> NETDEV_CHANGE returns early if ipv6 is disabled, and<br /> - the disable_ipv6=0 triggered codepath skips fully initializing the<br /> interface as long as addrconf_link_ready(dev) returns false<br /> - calling ipv6_mc_up() repeatedly does not leak anything