CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49018 – mptcp: fix sleep in atomic at close time
https://notcve.org/view.php?id=CVE-2022-49018
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix sleep in atomic at close time Matt reported a splat at msk close time: BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by packetdrill/155: #0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650) #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973) #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363) #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820) Preemption disabled at: 0x0 CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) __might_resched.cold (kernel/sched/core.c:9891) __mptcp_destroy_sock (include/linux/kernel.h:110) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_subflow_queue_clean (include/net/sock.h:1777) __mptcp_close_ssk (net/mptcp/protocol.c:2363) mptcp_destroy_common (net/mptcp/protocol.c:3170) mptcp_destroy (include/net/sock.h:1495) __mptcp_destroy_sock (net/mptcp/protocol.c:2886) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_close (net/mptcp/protocol.c:2974) inet_release (net/ipv4/af_inet.c:432) __sock_release (net/socket.c:651) sock_close (net/socket.c:1367) __fput (fs/file_table.c:320) task_work_run (kernel/task_work.c:181 (discriminator 1)) exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49) syscall_exit_to_user_mode (kernel/entry/common.c:130) do_syscall_64 (arch/x86/entry/common.c:87) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) We can't call mptcp_close under the 'fast' socket lock variant, replace it with a sock_lock_nested() as the relevant code is already under the listening msk socket lock protection. • https://git.kernel.org/stable/c/30e51b923e436b631e8d5b77fa5e318c6b066dc7 https://git.kernel.org/stable/c/b41808bfa049d1bc7ce8ce1ad4d591f7d203ebb9 https://git.kernel.org/stable/c/d8e6c5500dbf0f3e87aace90d4beba6ae928e866 https://git.kernel.org/stable/c/b4f166651d03b5484fa179817ba8ad4899a5a6ac •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49017 – tipc: re-fetch skb cb after tipc_msg_validate
https://notcve.org/view.php?id=CVE-2022-49017
In the Linux kernel, the following vulnerability has been resolved: tipc: re-fetch skb cb after tipc_msg_validate As the call trace shows, the original skb was freed in tipc_msg_validate(), and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: <IRQ> tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipc_msg_validate(). • https://git.kernel.org/stable/c/fc1b6d6de2208774efd2a20bf0daddb02d18b1e0 https://git.kernel.org/stable/c/a1ba595e35aa3afbe417ff0af353afb9f65559c0 https://git.kernel.org/stable/c/1daec0815655e110c6f206c5e777a4af8168ff58 https://git.kernel.org/stable/c/e128190adb2edfd5042105b5d1ed4553f295f5ef https://git.kernel.org/stable/c/3067bc61fcfe3081bf4807ce65560f499e895e77 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49016 – net: mdiobus: fix unbalanced node reference count
https://notcve.org/view.php?id=CVE-2022-49016
In the Linux kernel, the following vulnerability has been resolved: net: mdiobus: fix unbalanced node reference count I got the following report while doing device(mscc-miim) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0 If the 'fwnode' is not an acpi node, the refcount is get in fwnode_mdiobus_phy_device_register(), but it has never been put when the device is freed in the normal path. So call fwnode_handle_put() in phy_device_release() to avoid leak. If it's an acpi node, it has never been get, but it's put in the error path, so call fwnode_handle_get() before phy_device_register() to keep get/put operation balanced. • https://git.kernel.org/stable/c/bc1bee3b87ee48bd97ef7fd306445132ba2041b0 https://git.kernel.org/stable/c/543d917f691ab06885ee779c862065899eaa4251 https://git.kernel.org/stable/c/2708b357440427d6a9fee667eb7b8307f4625adc https://git.kernel.org/stable/c/cdde1560118f82498fc9e9a7c1ef7f0ef7755891 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49015 – net: hsr: Fix potential use-after-free
https://notcve.org/view.php?id=CVE-2022-49015
In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free. • https://git.kernel.org/stable/c/f421436a591d34fa5279b54a96ac07d70250cc8d https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9 https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4 https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9 https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9 https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6 https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-49014 – net: tun: Fix use-after-free in tun_detach()
https://notcve.org/view.php?id=CVE-2022-49014
In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. • https://git.kernel.org/stable/c/83c1f36f9880814b24cdf6c2f91f66f61db65326 https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7 https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054 https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12 •