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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56636 – geneve: do not assume mac header is set in geneve_xmit_skb()
https://notcve.org/view.php?id=CVE-2024-56636
In the Linux kernel, the following vulnerability has been resolved: geneve: do not assume mac header is set in geneve_xmit_skb() We should not assume mac header is set in output path. Use skb_eth_hdr() instead of eth_hdr() to fix the issue. sysbot reported the following : WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Modules linked in: CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283 RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000 RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003 RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000 R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23 FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/a025fb5f49ad38cf749753b16fcd031d0d678f2b https://git.kernel.org/stable/c/d9fa09ca004befe9cf826d6820439cb6f93cecd7 https://git.kernel.org/stable/c/b65958284401016b983078c68f70b047537f4aba https://git.kernel.org/stable/c/2ee7bdc7cb40abfe658a71fbd10c7db2f4fc4f9a https://git.kernel.org/stable/c/97ce3a4ec55eac6b5e2949ffb04028d604afda3b https://git.kernel.org/stable/c/177b72ed7c77b11e46dd4336d73a87a77a5603af https://git.kernel.org/stable/c/8588c99c7d47448fcae39e3227d6e2bb97aad86d •