CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56642 – tipc: Fix use-after-free of kernel socket in cleanup_bearer().
https://notcve.org/view.php?id=CVE-2024-56642
In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanup_bearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1] When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer(). tipc_net_stop() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer • https://git.kernel.org/stable/c/26abe14379f8e2fa3fd1bcf97c9a7ad9364886fe https://git.kernel.org/stable/c/4e69457f9dfae67435f3ccf29008768eae860415 https://git.kernel.org/stable/c/650ee9a22d7a2de8999fac2d45983597a0c22359 https://git.kernel.org/stable/c/d2a4894f238551eae178904e7f45af87577074fd https://git.kernel.org/stable/c/d62d5180c036eeac09f80660edc7a602b369125f https://git.kernel.org/stable/c/d00d4470bf8c4282617a3a10e76b20a9c7e4cffa https://git.kernel.org/stable/c/e48b211c4c59062cb6dd6c2c37c51a7cc235a464 https://git.kernel.org/stable/c/6a2fa13312e51a621f652d522d7e2df70 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56641 – net/smc: initialize close_work early to avoid warning
https://notcve.org/view.php?id=CVE-2024-56641
In the Linux kernel, the following vulnerability has been resolved: net/smc: initialize close_work early to avoid warning We encountered a warning that close_work was canceled before initialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(! • https://git.kernel.org/stable/c/46c28dbd4c23c3f7fa37f5ea48772af79c9cc40e https://git.kernel.org/stable/c/f0c37002210aaede10dae849d1a78efc2243add2 https://git.kernel.org/stable/c/6638e52dcfafaf1b9cbc34544f0c832db0069ea1 https://git.kernel.org/stable/c/0541db8ee32c09463a72d0987382b3a3336b0043 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56640 – net/smc: fix LGR and link use-after-free issue
https://notcve.org/view.php?id=CVE-2024-56640
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix LGR and link use-after-free issue We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 It is caused by repeated release of LGR/link refcnt. One suspect is that smc_conn_free() is called repeatedly because some smc_conn_free() from server listening path are not protected by sock lock. e.g. Calls under socklock | smc_listen_work ------------------------------------------------------- lock_sock(sk) | smc_conn_abort smc_conn_free | \- smc_conn_free \- smcr_link_put | \- smcr_link_put (duplicated) release_sock(sk) So here add sock lock protection in smc_listen_work() path, making it exclusive with other connection operations. • https://git.kernel.org/stable/c/3b2dec2603d5b06ad3af71c1164ca0b92df3d2a8 https://git.kernel.org/stable/c/f502a88fdd415647a1f2dc45fac71b9c522a052b https://git.kernel.org/stable/c/0cf598548a6c36d90681d53c6b77d52363f2f295 https://git.kernel.org/stable/c/673d606683ac70bc074ca6676b938bff18635226 https://git.kernel.org/stable/c/6f0ae06a234a78ae137064f2c89135ac078a00eb https://git.kernel.org/stable/c/2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56638 – netfilter: nft_inner: incorrect percpu area handling under softirq
https://notcve.org/view.php?id=CVE-2024-56638
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: incorrect percpu area handling under softirq Softirq can interrupt ongoing packet from process context that is walking over the percpu area that contains inner header offsets. Disable bh and perform three checks before restoring the percpu inner header offsets to validate that the percpu area is valid for this skbuff: 1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff has already been parsed before for inner header fetching to register. 2) Validate that the percpu area refers to this skbuff using the skbuff pointer as a cookie. If there is a cookie mismatch, then this skbuff needs to be parsed again. 3) Finally, validate if the percpu area refers to this tunnel type. Only after these three checks the percpu area is restored to a on-stack copy and bh is enabled again. After inner header fetching, the on-stack copy is stored back to the percpu area. • https://git.kernel.org/stable/c/3a07327d10a09379315c844c63f27941f5081e0a https://git.kernel.org/stable/c/53c7314208c865086d78b4e88da53bc33da0b603 https://git.kernel.org/stable/c/da5cc778e7bf78fe525bc90ec2043f41415c31d9 https://git.kernel.org/stable/c/7b1d83da254be3bf054965c8f3b1ad976f460ae5 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56637 – netfilter: ipset: Hold module reference while requesting a module
https://notcve.org/view.php?id=CVE-2024-56637
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Hold module reference while requesting a module User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call. • https://git.kernel.org/stable/c/a7b4f989a629493bb4ec4a354def784d440b32c4 https://git.kernel.org/stable/c/e5e2d3024753fdaca818b822e3827614bacbdccf https://git.kernel.org/stable/c/6099b5d3e37145484fac4b8b4070c3f1abfb3519 https://git.kernel.org/stable/c/0e67805e805c1f3edd6f43adbe08ea14b552694b https://git.kernel.org/stable/c/5bae60a933ba5d16eed55c6b279be51bcbbc79b0 https://git.kernel.org/stable/c/90bf312a6b6b3d6012137f6776a4052ee85e0340 https://git.kernel.org/stable/c/ba5e070f36682d07ca7ad2a953e6c9d96be19dca https://git.kernel.org/stable/c/456f010bfaefde84d3390c755eedb1b0a •