Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix server-&gt;active leak in afs_put_server<br /> <br /> The atomic_read was accidentally replaced with atomic_inc_return,<br /> which prevents the server from getting cleaned up and causes rmmod<br /> to hang with a warning:<br /> <br /> Can&amp;#39;t purge s=00000001

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix memory leak in sctp_stream_outq_migrate()<br /> <br /> When sctp_stream_outq_migrate() is called to release stream out resources,<br /> the memory pointed to by prio_head in stream out is not released.<br /> <br /> The memory leak information is as follows:<br /> unreferenced object 0xffff88801fe79f80 (size 64):<br /> comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s)<br /> hex dump (first 32 bytes):<br /> 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................<br /> 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x60<br /> [] sctp_sched_prio_set+0x4cc/0x770<br /> [] sctp_stream_init_ext+0xd2/0x1b0<br /> [] sctp_sendmsg_to_asoc+0x1614/0x1a30<br /> [] sctp_sendmsg+0xda1/0x1ef0<br /> [] inet_sendmsg+0x9d/0xe0<br /> [] sock_sendmsg+0xd3/0x120<br /> [] __sys_sendto+0x23a/0x340<br /> [] __x64_sys_sendto+0xe1/0x1b0<br /> [] do_syscall_64+0x39/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tun: Fix use-after-free in tun_detach()<br /> <br /> syzbot reported use-after-free in tun_detach() [1]. This causes call<br /> trace like below:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75<br /> Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673<br /> <br /> CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x15e/0x461 mm/kasan/report.c:395<br /> kasan_report+0xbf/0x1f0 mm/kasan/report.c:495<br /> notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75<br /> call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942<br /> call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]<br /> call_netdevice_notifiers net/core/dev.c:1997 [inline]<br /> netdev_wait_allrefs_any net/core/dev.c:10237 [inline]<br /> netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351<br /> tun_detach drivers/net/tun.c:704 [inline]<br /> tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467<br /> __fput+0x27c/0xa90 fs/file_table.c:320<br /> task_work_run+0x16f/0x270 kernel/task_work.c:179<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0xb3d/0x2a30 kernel/exit.c:820<br /> do_group_exit+0xd4/0x2a0 kernel/exit.c:950<br /> get_signal+0x21b1/0x2440 kernel/signal.c:2858<br /> arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869<br /> exit_to_user_mode_loop kernel/entry/common.c:168 [inline]<br /> exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296<br /> do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The cause of the issue is that sock_put() from __tun_detach() drops<br /> last reference count for struct net, and then notifier_call_chain()<br /> from netdev_state_change() accesses that struct net.<br /> <br /> This patch fixes the issue by calling sock_put() from tun_detach()<br /> after all necessary accesses for the struct net has done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: Fix potential use-after-free<br /> <br /> The skb is delivered to netif_rx() which may free it, after calling this,<br /> dereferencing skb may trigger use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdiobus: fix unbalanced node reference count<br /> <br /> I got the following report while doing device(mscc-miim) load test<br /> with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 2,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0<br /> <br /> If the &amp;#39;fwnode&amp;#39; is not an acpi node, the refcount is get in<br /> fwnode_mdiobus_phy_device_register(), but it has never been<br /> put when the device is freed in the normal path. So call<br /> fwnode_handle_put() in phy_device_release() to avoid leak.<br /> <br /> If it&amp;#39;s an acpi node, it has never been get, but it&amp;#39;s put<br /> in the error path, so call fwnode_handle_get() before<br /> phy_device_register() to keep get/put operation balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: re-fetch skb cb after tipc_msg_validate<br /> <br /> As the call trace shows, the original skb was freed in tipc_msg_validate(),<br /> and dereferencing the old skb cb would cause an use-after-free crash.<br /> <br /> BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]<br /> Call Trace:<br /> <br /> tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]<br /> tipc_crypto_rcv+0xd32/0x1ec0 [tipc]<br /> tipc_rcv+0x744/0x1150 [tipc]<br /> ...<br /> Allocated by task 47078:<br /> kmem_cache_alloc_node+0x158/0x4d0<br /> __alloc_skb+0x1c1/0x270<br /> tipc_buf_acquire+0x1e/0xe0 [tipc]<br /> tipc_msg_create+0x33/0x1c0 [tipc]<br /> tipc_link_build_proto_msg+0x38a/0x2100 [tipc]<br /> tipc_link_timeout+0x8b8/0xef0 [tipc]<br /> tipc_node_timeout+0x2a1/0x960 [tipc]<br /> call_timer_fn+0x2d/0x1c0<br /> ...<br /> Freed by task 47078:<br /> tipc_msg_validate+0x7b/0x440 [tipc]<br /> tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]<br /> tipc_crypto_rcv+0xd32/0x1ec0 [tipc]<br /> tipc_rcv+0x744/0x1150 [tipc]<br /> <br /> This patch fixes it by re-fetching the skb cb from the new allocated skb<br /> after calling tipc_msg_validate().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix sleep in atomic at close time<br /> <br /> Matt reported a splat at msk close time:<br /> <br /> BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill<br /> preempt_count: 201, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 4 locks held by packetdrill/155:<br /> #0: ffff888001536990 (&amp;sb-&gt;s_type-&gt;i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)<br /> #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)<br /> #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)<br /> #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)<br /> Preemption disabled at:<br /> 0x0<br /> CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))<br /> __might_resched.cold (kernel/sched/core.c:9891)<br /> __mptcp_destroy_sock (include/linux/kernel.h:110)<br /> __mptcp_close (net/mptcp/protocol.c:2959)<br /> mptcp_subflow_queue_clean (include/net/sock.h:1777)<br /> __mptcp_close_ssk (net/mptcp/protocol.c:2363)<br /> mptcp_destroy_common (net/mptcp/protocol.c:3170)<br /> mptcp_destroy (include/net/sock.h:1495)<br /> __mptcp_destroy_sock (net/mptcp/protocol.c:2886)<br /> __mptcp_close (net/mptcp/protocol.c:2959)<br /> mptcp_close (net/mptcp/protocol.c:2974)<br /> inet_release (net/ipv4/af_inet.c:432)<br /> __sock_release (net/socket.c:651)<br /> sock_close (net/socket.c:1367)<br /> __fput (fs/file_table.c:320)<br /> task_work_run (kernel/task_work.c:181 (discriminator 1))<br /> exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)<br /> syscall_exit_to_user_mode (kernel/entry/common.c:130)<br /> do_syscall_64 (arch/x86/entry/common.c:87)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> <br /> We can&amp;#39;t call mptcp_close under the &amp;#39;fast&amp;#39; socket lock variant, replace<br /> it with a sock_lock_nested() as the relevant code is already under the<br /> listening msk socket lock protection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths<br /> <br /> Any codepath that zaps page table entries must invoke MMU notifiers to<br /> ensure that secondary MMUs (like KVM) don&amp;#39;t keep accessing pages which<br /> aren&amp;#39;t mapped anymore. Secondary MMUs don&amp;#39;t hold their own references to<br /> pages that are mirrored over, so failing to notify them can lead to page<br /> use-after-free.<br /> <br /> I&amp;#39;m marking this as addressing an issue introduced in commit f3f0e1d2150b<br /> ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of<br /> the security impact of this only came in commit 27e1f8273113 ("khugepaged:<br /> enable collapse pmd for pte-mapped THP"), which actually omitted flushes<br /> for the removal of present PTEs, not just for the removal of empty page<br /> tables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-pcm: Add NULL check in BE reparenting<br /> <br /> Add NULL check in dpcm_be_reparent API, to handle<br /> kernel NULL pointer dereference error.<br /> The issue occurred in fuzzing test.

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 /> ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed.<br /> <br /> seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes<br /> matching snd_seq_dump_func_t. Adjust this and remove the casts. There<br /> are not resulting binary output differences.<br /> <br /> This was found as a result of Clang&amp;#39;s new -Wcast-function-type-strict<br /> flag, which is more sensitive than the simpler -Wcast-function-type,<br /> which only checks for type width mismatches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()<br /> <br /> There is a kmemleak when test the raydium_i2c_ts with bpf mock device:<br /> <br /> unreferenced object 0xffff88812d3675a0 (size 8):<br /> comm "python3", pid 349, jiffies 4294741067 (age 95.695s)<br /> hex dump (first 8 bytes):<br /> 11 0e 10 c0 01 00 04 00 ........<br /> backtrace:<br /> [] __kmalloc+0x46/0x1b0<br /> [] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]<br /> [] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]<br /> [] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]<br /> [] i2c_device_probe+0x651/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x352/0x4e0<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0x100/0x160<br /> unreferenced object 0xffff88812d3675c8 (size 8):<br /> comm "python3", pid 349, jiffies 4294741070 (age 95.692s)<br /> hex dump (first 8 bytes):<br /> 22 00 36 2d 81 88 ff ff ".6-....<br /> backtrace:<br /> [] __kmalloc+0x46/0x1b0<br /> [] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]<br /> [] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]<br /> [] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]<br /> [] i2c_device_probe+0x651/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x352/0x4e0<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0x100/0x160<br /> <br /> After BANK_SWITCH command from i2c BUS, no matter success or error<br /> happened, the tx_buf should be freed.