CVSS: -EPSS: 0%CPEs: 8EXPL: 1CVE-2024-44946 – kcm: Serialise kcm_sendmsg() for the same socket.
https://notcve.org/view.php?id=CVE-2024-44946
In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queue When a thread is building a MSG_MORE skb, another thread must not touch it. Let's add a per-sk mutex and serialise kcm_sendmsg(). [0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167 CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated--- • https://github.com/Abdurahmon3236/CVE-2024-44946 https://git.kernel.org/stable/c/ab7ac4eb9832e32a09f4e8042705484d2fb0aad3 https://git.kernel.org/stable/c/8c9cdbf600143bd6835c8b8351e5ac956da79aec https://git.kernel.org/stable/c/6633b17840bf828921254d788ccd15602843fe9b https://git.kernel.org/stable/c/eb06c8d3022ce6738711191c89f9b3e9cfb91914 https://git.kernel.org/stable/c/fa6c23fe6dcac8c8bd63920ee8681292a2bd544e https://git.kernel.org/stable/c/72da240aafb142630cf16adc803ccdacb3780849 https://git.kernel.org/stable/c/00425508f30baa5ab6449a1f478480ca7cffa6da https:&#x •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48944 – sched: Fix yet more sched_fork() races
https://notcve.org/view.php?id=CVE-2022-48944
In the Linux kernel, the following vulnerability has been resolved: sched: Fix yet more sched_fork() races Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash. Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit. • https://git.kernel.org/stable/c/3869eecf050416a1d19bac60926f6b5d64b0aa58 https://git.kernel.org/stable/c/4ef0c5c6b5ba1f38f0ea1cedad0cad722f00c14a https://git.kernel.org/stable/c/c85c6fadbef0a3eab41540ea628fa8fe8928c820 https://git.kernel.org/stable/c/25d40b828fb855ee62e1039c65a666c9afd60786 https://git.kernel.org/stable/c/3411613611a5cddf7e80908010dc87cb527dd13b https://git.kernel.org/stable/c/c65cfd89cef669d90c59f3bf150af6458137a04f https://git.kernel.org/stable/c/b1e8206582f9d680cff7d04828708c8b6ab32957 •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2024-44944 – netfilter: ctnetlink: use helper function to calculate expect ID
https://notcve.org/view.php?id=CVE-2024-44944
In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use helper function to calculate expect ID Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace. • https://git.kernel.org/stable/c/7b115755fb9d3aff0ddcd18a5c4d83381362acce https://git.kernel.org/stable/c/3c79107631db1f7fd32cf3f7368e4672004a3010 https://git.kernel.org/stable/c/3d8b3d0384f709126beef6b917b7e97c23f18e74 https://git.kernel.org/stable/c/36bbd861a402a8c5bd8f0365a5967d34cc492f09 https://git.kernel.org/stable/c/1922476beeeea46bebbe577215078736dd4231dc https://git.kernel.org/stable/c/f862c13c3c926d3008b2c2bcc746ab813108dfbf https://git.kernel.org/stable/c/b0a90cae081d7ee14eaa46524fb70f4e23ae8905 https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-4442 – tcp: add sanity tests to TCP_QUEUE_SEQ
https://notcve.org/view.php?id=CVE-2021-4442
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity tests to TCP_QUEUE_SEQ Qingyu Li reported a syzkaller bug where the repro changes RCV SEQ _after_ restoring data in the receive queue. mprotect(0x4aa000, 12288, PROT_READ) = 0 mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ffff000 mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000 mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x21000000 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0 setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [1], 4) = 0 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0x0000000000000003\0\0", iov_len=20}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20 setsockopt(3, SOL_TCP, TCP_REPAIR, [0], 4) = 0 setsockopt(3, SOL_TCP, TCP_QUEUE_SEQ, [128], 4) = 0 recvfrom(3, NULL, 20, 0, NULL, NULL) = -1 ECONNRESET (Connection reset by peer) syslog shows: [ 111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0 [ 111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcp_recvmsg_locked+0x90e/0x29a0 This should not be allowed. TCP_QUEUE_SEQ should only be used when queues are empty. This patch fixes this case, and the tx path as well. • https://git.kernel.org/stable/c/ee9952831cfd0bbe834f4a26489d7dce74582e37 https://git.kernel.org/stable/c/319f460237fc2965a80aa9a055044e1da7b3692a https://git.kernel.org/stable/c/3bf899438c123c444f6b644a57784dfbb6b15ad6 https://git.kernel.org/stable/c/046f3c1c2ff450fb7ae53650e9a95e0074a61f3e https://git.kernel.org/stable/c/3b72d5a703842f582502d97906f17d6ee122dac2 https://git.kernel.org/stable/c/8811f4a9836e31c14ecdf79d9f3cb7c5d463265d https://access.redhat.com/security/cve/CVE-2021-4442 https://bugzilla.redhat.com/show_bug.cgi?id=2308455 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44942 – f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
https://notcve.org/view.php?id=CVE-2024-44942
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing. • https://git.kernel.org/stable/c/ae00e6536a2dd54b64b39e9a39548870cf835745 https://git.kernel.org/stable/c/26c07775fb5dc74351d1c3a2bc3cdf609b03e49f https://git.kernel.org/stable/c/fc01008c92f40015aeeced94750855a7111b6929 •