CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49020 – net/9p: Fix a potential socket leak in p9_socket_open
https://notcve.org/view.php?id=CVE-2022-49020
In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9_socket_open Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue. • https://git.kernel.org/stable/c/6b18662e239a032f908b7f6e164bdf7e2e0a32c9 https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443 https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64 https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260 https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748 https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49019 – net: ethernet: nixge: fix NULL dereference
https://notcve.org/view.php?id=CVE-2022-49019
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/492caffa8a1a405f661c111acabfe6b8b9645db8 https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3 https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6 •
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 •