{"schema_version":"1.7.2","id":"OESA-2024-2076","modified":"2024-08-30T11:09:00Z","published":"2024-08-30T11:09:00Z","upstream":["CVE-2024-33621","CVE-2024-33847","CVE-2024-34777","CVE-2024-36270","CVE-2024-36281","CVE-2024-36286","CVE-2024-36484","CVE-2024-36908","CVE-2024-36914","CVE-2024-36933","CVE-2024-36938","CVE-2024-36947","CVE-2024-36959","CVE-2024-38390","CVE-2024-38539","CVE-2024-38543","CVE-2024-38544","CVE-2024-38546","CVE-2024-38550","CVE-2024-38557","CVE-2024-38560","CVE-2024-38561","CVE-2024-38565","CVE-2024-38566","CVE-2024-38580","CVE-2024-38593","CVE-2024-38597","CVE-2024-38611","CVE-2024-38613","CVE-2024-38616","CVE-2024-38627","CVE-2024-38635","CVE-2024-39276","CVE-2024-39298","CVE-2024-39476","CVE-2024-39490","CVE-2024-39491","CVE-2024-39501","CVE-2024-39504","CVE-2024-40901","CVE-2024-40910","CVE-2024-40911","CVE-2024-40914","CVE-2024-40919","CVE-2024-40925","CVE-2024-40928","CVE-2024-40938","CVE-2024-40939","CVE-2024-40940","CVE-2024-40944","CVE-2024-40945","CVE-2024-40948","CVE-2024-40950","CVE-2024-40955","CVE-2024-40966","CVE-2024-40969","CVE-2024-40970","CVE-2024-40988","CVE-2024-40992","CVE-2024-40994","CVE-2024-40996","CVE-2024-41015","CVE-2024-41025","CVE-2024-41028","CVE-2024-41030","CVE-2024-41031","CVE-2024-41036","CVE-2024-41038","CVE-2024-41047","CVE-2024-41050","CVE-2024-41051","CVE-2024-41053","CVE-2024-41054","CVE-2024-41058","CVE-2024-41059","CVE-2024-41060","CVE-2024-41066","CVE-2024-41068","CVE-2024-41084","CVE-2024-41087","CVE-2024-41088","CVE-2024-41092","CVE-2024-41093","CVE-2024-41094","CVE-2024-42063","CVE-2024-42069","CVE-2024-42070","CVE-2024-42073","CVE-2024-42074","CVE-2024-42079","CVE-2024-42085","CVE-2024-42100","CVE-2024-42103","CVE-2024-42109","CVE-2024-42113","CVE-2024-42120","CVE-2024-42121","CVE-2024-42130","CVE-2024-42132","CVE-2024-42133","CVE-2024-42135","CVE-2024-42136","CVE-2024-42138","CVE-2024-42140","CVE-2024-42142","CVE-2024-42144","CVE-2024-42156","CVE-2024-42160","CVE-2024-42161","CVE-2024-42224","CVE-2024-42225","CVE-2024-42230","CVE-2024-42265","CVE-2024-42267","CVE-2024-42268","CVE-2024-42269","CVE-2024-42270","CVE-2024-42273","CVE-2024-42274","CVE-2024-42284","CVE-2024-42285","CVE-2024-42302","CVE-2024-43819","CVE-2024-43824","CVE-2024-43853","CVE-2024-43861","CVE-2024-43863","CVE-2024-43864","CVE-2024-43866","CVE-2024-43868","CVE-2024-43869","CVE-2024-43882","CVE-2024-44938","CVE-2024-44941"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: Dont Use skb-\u0026gt;sk in ipvlan_process_v{4,6}_outbound\r\n\r\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\r\n\r\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n ? __warn (kernel/panic.c:693)\n ? sk_mc_loop (net/core/sock.c:760)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:239)\n ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? sk_mc_loop (net/core/sock.c:760)\n ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n ? nf_hook_slow (net/netfilter/core.c:626)\n ip6_finish_output (net/ipv6/ip6_output.c:222)\n ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\n ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\n ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\n dev_hard_start_xmit (net/core/dev.c:3594)\n sch_direct_xmit (net/sched/sch_generic.c:343)\n __qdisc_run (net/sched/sch_generic.c:416)\n net_tx_action (net/core/dev.c:5286)\n handle_softirqs (kernel/softirq.c:555)\n __irq_exit_rcu (kernel/softirq.c:589)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\r\n\r\nThe warning triggers as this:\npacket_sendmsg\n   packet_snd //skb-\u0026gt;sk is packet sk\n      __dev_queue_xmit\n         __dev_xmit_skb //q-\u0026gt;enqueue is not NULL\n             __qdisc_run\n               sch_direct_xmit\n                 dev_hard_start_xmit\n                   ipvlan_start_xmit\n                      ipvlan_xmit_mode_l3 //l3 mode\n                        ipvlan_process_outbound //vepa flag\n                          ipvlan_process_v6_outbound\n                            ip6_local_out\n                                __ip6_finish_output\n                                  ip6_finish_output2 //multicast packet\n                                    sk_mc_loop //sk-\u0026gt;sk_family is AF_PACKET\r\n\r\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: don\u0026apos;t allow unaligned truncation on released compress inode\r\n\r\nf2fs image may be corrupted after below testcase:\n- mkfs.f2fs -O extra_attr,compression -f /dev/vdb\n- mount /dev/vdb /mnt/f2fs\n- touch /mnt/f2fs/file\n- f2fs_io setflags compression /mnt/f2fs/file\n- dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4\n- f2fs_io release_cblocks /mnt/f2fs/file\n- truncate -s 8192 /mnt/f2fs/file\n- umount /mnt/f2fs\n- fsck.f2fs /dev/vdb\r\n\r\n[ASSERT] (fsck_chk_inode_blk:1256)  --\u0026gt; ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks\n[FSCK] valid_block_count matching with CP             [Fail] [0x4, 0x5]\n[FSCK] other corrupted bugs                           [Fail]\r\n\r\nThe reason is: partial truncation assume compressed inode has reserved\nblocks, after partial truncation, valid block count may change w/o\n.i_blocks and .total_valid_block_count update, result in corruption.\r\n\r\nThis patch only allow cluster size aligned truncation on released\ncompress inode for fixing.(CVE-2024-33847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: tproxy: bail out if IP has been disabled on the device\r\n\r\nsyzbot reports:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n[..]\nRIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62\nCall Trace:\n nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]\n nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168\r\n\r\n__in_dev_get_rcu() can return NULL, so check for this.(CVE-2024-36270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules\r\n\r\nrx_create no longer allocates a modify_hdr instance that needs to be\ncleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer\ndereference. A leak in the rules also previously occurred since there are\nnow two rules populated related to status.\r\n\r\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 109907067 P4D 109907067 PUD 116890067 PMD 0\n  Oops: 0000 [#1] SMP\n  CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70\n  \u0026lt;snip\u0026gt;\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? show_regs+0x60/0x70\n   ? __die+0x24/0x70\n   ? page_fault_oops+0x15f/0x430\n   ? free_to_partial_list.constprop.0+0x79/0x150\n   ? do_user_addr_fault+0x2c9/0x5c0\n   ? exc_page_fault+0x63/0x110\n   ? asm_exc_page_fault+0x27/0x30\n   ? mlx5_modify_header_dealloc+0xd/0x70\n   rx_create+0x374/0x590\n   rx_add_rule+0x3ad/0x500\n   ? rx_add_rule+0x3ad/0x500\n   ? mlx5_cmd_exec+0x2c/0x40\n   ? mlx5_create_ipsec_obj+0xd6/0x200\n   mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0\n   mlx5e_xfrm_add_state+0x426/0xc00\n  \u0026lt;snip\u0026gt;(CVE-2024-36281)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n  rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n  __do_softirq kernel/softirq.c:588 [inline]\n  invoke_softirq kernel/softirq.c:428 [inline]\n  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: relax socket state check at accept time.\r\n\r\nChristoph reported the following splat:\r\n\r\nWARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0\nModules linked in:\nCPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759\nCode: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd \u0026lt;0f\u0026gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80\nRSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293\nRAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64\nR10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000\nR13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800\nFS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786\n do_accept+0x435/0x620 net/socket.c:1929\n __sys_accept4_file net/socket.c:1969 [inline]\n __sys_accept4+0x9b/0x110 net/socket.c:1999\n __do_sys_accept net/socket.c:2016 [inline]\n __se_sys_accept net/socket.c:2013 [inline]\n __x64_sys_accept+0x7d/0x90 net/socket.c:2013\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x4315f9\nCode: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300\nR10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe reproducer invokes shutdown() before entering the listener status.\nAfter commit 94062790aedb (\u0026quot;tcp: defer shutdown(SEND_SHUTDOWN) for\nTCP_SYN_RECV sockets\u0026quot;), the above causes the child to reach the accept\nsyscall in FIN_WAIT1 status.\r\n\r\nEric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: do not WARN if iocg was already offlined\r\n\r\nIn iocg_pay_debt(), warn is triggered if \u0026apos;active_list\u0026apos; is empty, which\nis intended to confirm iocg is active when it has debt. However, warn\ncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()\nis run at that time:\r\n\r\n  WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190\n  Call trace:\n  iocg_pay_debt+0x14c/0x190\n  iocg_kick_waitq+0x438/0x4c0\n  iocg_waitq_timer_fn+0xd8/0x130\n  __run_hrtimer+0x144/0x45c\n  __hrtimer_run_queues+0x16c/0x244\n  hrtimer_interrupt+0x2cc/0x7b0\r\n\r\nThe warn in this situation is meaningless. Since this iocg is being\nremoved, the state of the \u0026apos;active_list\u0026apos; is irrelevant, and \u0026apos;waitq_timer\u0026apos;\nis canceled after removing \u0026apos;active_list\u0026apos; in ioc_pd_free(), which ensures\niocg is freed after iocg_waitq_timer_fn() returns.\r\n\r\nTherefore, add the check if iocg was already offlined to avoid warn\nwhen removing a blkcg or disk.(CVE-2024-36908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip on writeback when it\u0026apos;s not applicable\r\n\r\n[WHY]\ndynamic memory safety error detector (KASAN) catches and generates error\nmessages \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot; as writeback connector does not\nsupport certain features which are not initialized.\r\n\r\n[HOW]\nSkip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnsh: Restore skb-\u0026gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().\r\n\r\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\r\n\r\n  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\r\n\r\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\r\n\r\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\r\n\r\n  1. reset skb-\u0026gt;network_header\n  2. save the original skb-\u0026gt;{mac_heaeder,mac_len} in a local variable\n  3. pull the NSH header\n  4. resets skb-\u0026gt;mac_header\n  5. set up skb-\u0026gt;mac_len and skb-\u0026gt;protocol for the inner protocol.\r\n\r\nand does the following for the segmented skb\r\n\r\n  6. set ntohs(ETH_P_NSH) to skb-\u0026gt;protocol\n  7. push the NSH header\n  8. restore skb-\u0026gt;mac_header\n  9. set skb-\u0026gt;mac_header + mac_len to skb-\u0026gt;network_header\n 10. restore skb-\u0026gt;mac_len\r\n\r\nThere are two problems in 6-7 and 8-9.\r\n\r\n  (a)\n  After 6 \u0026amp; 7, skb-\u0026gt;data points to the NSH header, so the outer header\n  (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\r\n\r\n  Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n  skb_pull() in the first nsh_gso_segment() will make skb-\u0026gt;data point\n  to the middle of the outer NSH or Ethernet header because the Ethernet\n  header is not pulled by the second nsh_gso_segment().\r\n\r\n  (b)\n  While restoring skb-\u0026gt;{mac_header,network_header} in 8 \u0026amp; 9,\n  nsh_gso_segment() does not assume that the data in the linear\n  buffer is shifted.\r\n\r\n  However, udp6_ufo_fragment() could shift the data and change\n  skb-\u0026gt;mac_header accordingly as demonstrated by syzbot.\r\n\r\n  If this happens, even the restored skb-\u0026gt;mac_header points to\n  the middle of the outer header.\r\n\r\nIt seems nsh_gso_segment() has never worked with outer headers so far.\r\n\r\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\r\n\r\nTo do that, let\u0026apos;s calculate the outer header position relatively from\nthe inner header and set skb-\u0026gt;{data,mac_header,protocol} properly.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---(CVE-2024-36933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\r\n\r\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\r\n\r\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\r\n\r\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nvalue changed: 0xffffffff83d7feb0 -\u0026gt; 0x0000000000000000\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\r\n\r\nPrior to this, commit 4cd12c6065df (\u0026quot;bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()\u0026quot;) fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses \u0026quot;write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock);\u0026quot;.\r\n\r\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nqibfs: fix dentry leak\r\n\r\nsimple_recursive_removal() drops the pinning references to all positives\nin subtree.  For the cases when its argument has been kept alive by\nthe pinning alone that\u0026apos;s exactly the right thing to do, but here\nthe argument comes from dcache lookup, that needs to be balanced by\nexplicit dput().\r\n\r\nFucked-up-by: Al Viro \u0026lt;viro@zeniv.linux.org.uk\u0026gt;(CVE-2024-36947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()\r\n\r\nIf we fail to allocate propname buffer, we need to drop the reference\ncount we just took. Because the pinctrl_dt_free_maps() includes the\ndroping operation, here we call it directly.(CVE-2024-36959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\r\n\r\nCalling a6xx_destroy() before adreno_gpu_init() leads to a null pointer\ndereference on:\r\n\r\nmsm_gpu_cleanup() : platform_set_drvdata(gpu-\u0026gt;pdev, NULL);\r\n\r\nas gpu-\u0026gt;pdev is only assigned in:\r\n\r\na6xx_gpu_init()\n|_ adreno_gpu_init\n    |_ msm_gpu_init()\r\n\r\nInstead of relying on handwavy null checks down the cleanup chain,\nexplicitly de-allocate the LLC data and free a6xx_gpu instead.\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/588919/(CVE-2024-38390)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw\r\n\r\nWhen running blktests nvme/rdma, the following kmemleak issue will appear.\r\n\r\nkmemleak: Kernel memory leak detector initialized (mempool available:36041)\nkmemleak: Automatic memory scanning thread started\nkmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\r\n\r\nunreferenced object 0xffff88855da53400 (size 192):\n  comm \u0026quot;rdma\u0026quot;, pid 10630, jiffies 4296575922\n  hex dump (first 32 bytes):\n    37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00  7...............\n    10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff  .4.].....4.]....\n  backtrace (crc 47f66721):\n    [\u0026lt;ffffffff911251bd\u0026gt;] kmalloc_trace+0x30d/0x3b0\n    [\u0026lt;ffffffffc2640ff7\u0026gt;] alloc_gid_entry+0x47/0x380 [ib_core]\n    [\u0026lt;ffffffffc2642206\u0026gt;] add_modify_gid+0x166/0x930 [ib_core]\n    [\u0026lt;ffffffffc2643468\u0026gt;] ib_cache_update.part.0+0x6d8/0x910 [ib_core]\n    [\u0026lt;ffffffffc2644e1a\u0026gt;] ib_cache_setup_one+0x24a/0x350 [ib_core]\n    [\u0026lt;ffffffffc263949e\u0026gt;] ib_register_device+0x9e/0x3a0 [ib_core]\n    [\u0026lt;ffffffffc2a3d389\u0026gt;] 0xffffffffc2a3d389\n    [\u0026lt;ffffffffc2688cd8\u0026gt;] nldev_newlink+0x2b8/0x520 [ib_core]\n    [\u0026lt;ffffffffc2645fe3\u0026gt;] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]\n    [\u0026lt;ffffffffc264648c\u0026gt;]\nrdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]\n    [\u0026lt;ffffffff9270e7b5\u0026gt;] netlink_unicast+0x445/0x710\n    [\u0026lt;ffffffff9270f1f1\u0026gt;] netlink_sendmsg+0x761/0xc40\n    [\u0026lt;ffffffff9249db29\u0026gt;] __sys_sendto+0x3a9/0x420\n    [\u0026lt;ffffffff9249dc8c\u0026gt;] __x64_sys_sendto+0xdc/0x1b0\n    [\u0026lt;ffffffff92db0ad3\u0026gt;] do_syscall_64+0x93/0x180\n    [\u0026lt;ffffffff92e00126\u0026gt;] entry_SYSCALL_64_after_hwframe+0x71/0x79\r\n\r\nThe root cause: rdma_put_gid_attr is not called when sgid_attr is set\nto ERR_PTR(-ENODEV).(CVE-2024-38539)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/test_hmm.c: handle src_pfns and dst_pfns allocation failure\r\n\r\nThe kcalloc() in dmirror_device_evict_chunk() will return null if the\nphysical memory has run out.  As a result, if src_pfns or dst_pfns is\ndereferenced, the null pointer dereference bug will happen.\r\n\r\nMoreover, the device is going away.  If the kcalloc() fails, the pages\nmapping a chunk could not be evicted.  So add a __GFP_NOFAIL flag in\nkcalloc().\r\n\r\nFinally, as there is no need to have physically contiguous memory, Switch\nkcalloc() to kvcalloc() in order to avoid failing allocations.(CVE-2024-38543)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault.  This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: vc4: Fix possible null pointer dereference\r\n\r\nIn vc4_hdmi_audio_init() of_get_address() may return\nNULL which is later dereferenced. Fix this bug by adding NULL check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: kirkwood: Fix potential NULL dereference\r\n\r\nIn kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if\nCONFIG_PLAT_ORION macro is not defined.\nFix this bug by adding NULL check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38550)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Reload only IB representors upon lag disable/enable\r\n\r\nOn lag disable, the bond IB device along with all of its\nrepresentors are destroyed, and then the slaves\u0026apos; representors get reloaded.\r\n\r\nIn case the slave IB representor load fails, the eswitch error flow\nunloads all representors, including ethernet representors, where the\nnetdevs get detached and removed from lag bond. Such flow is inaccurate\nas the lag driver is not responsible for loading/unloading ethernet\nrepresentors. Furthermore, the flow described above begins by holding\nlag lock to prevent bond changes during disable flow. However, when\nreaching the ethernet representors detachment from lag, the lag lock is\nrequired again, triggering the following deadlock:\r\n\r\nCall trace:\n__switch_to+0xf4/0x148\n__schedule+0x2c8/0x7d0\nschedule+0x50/0xe0\nschedule_preempt_disabled+0x18/0x28\n__mutex_lock.isra.13+0x2b8/0x570\n__mutex_lock_slowpath+0x1c/0x28\nmutex_lock+0x4c/0x68\nmlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]\nmlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]\nmlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]\nmlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]\nmlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]\nmlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]\nmlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]\nmlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]\nmlx5_disable_lag+0x130/0x138 [mlx5_core]\nmlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev-\u0026gt;lock\nmlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]\ndevlink_nl_cmd_eswitch_set_doit+0xdc/0x180\ngenl_family_rcv_msg_doit.isra.17+0xe8/0x138\ngenl_rcv_msg+0xe4/0x220\nnetlink_rcv_skb+0x44/0x108\ngenl_rcv+0x40/0x58\nnetlink_unicast+0x198/0x268\nnetlink_sendmsg+0x1d4/0x418\nsock_sendmsg+0x54/0x60\n__sys_sendto+0xf4/0x120\n__arm64_sys_sendto+0x30/0x40\nel0_svc_common+0x8c/0x120\ndo_el0_svc+0x30/0xa0\nel0_svc+0x20/0x30\nel0_sync_handler+0x90/0xb8\nel0_sync+0x160/0x180\r\n\r\nThus, upon lag enable/disable, load and unload only the IB representors\nof the slaves preventing the deadlock mentioned above.\r\n\r\nWhile at it, refactor the mlx5_esw_offloads_rep_load() function to have\na static helper method for its internal logic, in symmetry with the\nrepresentor unload design.(CVE-2024-38557)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bfa: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul instead\nof memdup_user.(CVE-2024-38560)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkunit: Fix kthread reference\r\n\r\nThere is a race condition when a kthread finishes after the deadline and\nbefore the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix verifier assumptions about socket-\u0026gt;sk\r\n\r\nThe verifier assumes that \u0026apos;sk\u0026apos; field in \u0026apos;struct socket\u0026apos; is valid\nand non-NULL when \u0026apos;socket\u0026apos; pointer itself is trusted and non-NULL.\nThat may not be the case when socket was just created and\npassed to LSM socket_accept hook.\nFix this verifier assumption and adjust tests.(CVE-2024-38566)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nepoll: be better about file lifetimes\r\n\r\nepoll can call out to vfs_poll() with a file pointer that may race with\nthe last \u0026apos;fput()\u0026apos;. That would make f_count go down to zero, and while\nthe ep-\u0026gt;mtx locking means that the resulting file pointer tear-down will\nbe blocked until the poll returns, it means that f_count is already\ndead, and any use of it won\u0026apos;t actually get a reference to the file any\nmore: it\u0026apos;s dead regardless.\r\n\r\nMake sure we have a valid ref on the file pointer before we call down to\nvfs_poll() from the epoll routines.(CVE-2024-38580)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: micrel: Fix receiving the timestamp in the frame for lan8841\r\n\r\nThe blamed commit started to use the ptp workqueue to get the second\npart of the timestamp. And when the port was set down, then this\nworkqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING\nis not enabled, then the ptp_clock is not initialized so then it would\ncrash when it would try to access the delayed work.\nSo then basically by setting up and then down the port, it would crash.\nThe fix consists in checking if the ptp_clock is initialized and only\nthen cancel the delayed work.(CVE-2024-38593)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n  netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n  WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nm68k: Fix spinlock race in kernel thread creation\r\n\r\nContext switching does take care to retain the correct lock owner across\nthe switch from \u0026apos;prev\u0026apos; to \u0026apos;next\u0026apos; tasks.  This does rely on interrupts\nremaining disabled for the entire duration of the switch.\r\n\r\nThis condition is guaranteed for normal process creation and context\nswitching between already running processes, because both \u0026apos;prev\u0026apos; and\n\u0026apos;next\u0026apos; already have interrupts disabled in their saved copies of the\nstatus register.\r\n\r\nThe situation is different for newly created kernel threads.  The status\nregister is set to PS_S in copy_thread(), which does leave the IPL at 0.\nUpon restoring the \u0026apos;next\u0026apos; thread\u0026apos;s status register in switch_to() aka\nresume(), interrupts then become enabled prematurely.  resume() then\nreturns via ret_from_kernel_thread() and schedule_tail() where run queue\nlock is released (see finish_task_switch() and finish_lock_switch()).\r\n\r\nA timer interrupt calling scheduler_tick() before the lock is released\nin finish_task_switch() will find the lock already taken, with the\ncurrent task as lock owner.  This causes a spinlock recursion warning as\nreported by Guenter Roeck.\r\n\r\nAs far as I can ascertain, this race has been opened in commit\n533e6903bea0 (\u0026quot;m68k: split ret_from_fork(), simplify kernel_thread()\u0026quot;)\nbut I haven\u0026apos;t done a detailed study of kernel history so it may well\npredate that commit.\r\n\r\nInterrupts cannot be disabled in the saved status register copy for\nkernel threads (init will complain about interrupts disabled when\nfinally starting user space).  Disable interrupts temporarily when\nswitching the tasks\u0026apos; register sets in resume().\r\n\r\nNote that a simple oriw 0x700,%sr after restoring sr is not enough here\n- this leaves enough of a race for the \u0026apos;spinlock recursion\u0026apos; warning to\nstill be observed.\r\n\r\nTested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: re-fix fortified-memset warning\r\n\r\nThe carl9170_tx_release() function sometimes triggers a fortified-memset\nwarning in my randconfig builds:\r\n\r\nIn file included from include/linux/string.h:254,\n                 from drivers/net/wireless/ath/carl9170/tx.c:40:\nIn function \u0026apos;fortify_memset_chk\u0026apos;,\n    inlined from \u0026apos;carl9170_tx_release\u0026apos; at drivers/net/wireless/ath/carl9170/tx.c:283:2,\n    inlined from \u0026apos;kref_put\u0026apos; at include/linux/kref.h:65:3,\n    inlined from \u0026apos;carl9170_tx_put_skb\u0026apos; at drivers/net/wireless/ath/carl9170/tx.c:342:9:\ninclude/linux/fortify-string.h:493:25: error: call to \u0026apos;__write_overflow_field\u0026apos; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]\n  493 |                         __write_overflow_field(p_size_field, size);\r\n\r\nKees previously tried to avoid this by using memset_after(), but it seems\nthis does not fully address the problem. I noticed that the memset_after()\nhere is done on a different part of the union (status) than the original\ncast was from (rate_driver_data), which may confuse the compiler.\r\n\r\nUnfortunately, the memset_after() trick does not work on driver_rates[]\nbecause that is part of an anonymous struct, and I could not get\nstruct_group() to do this either. Using two separate memset() calls\non the two members does address the warning though.(CVE-2024-38616)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstm class: Fix a double free in stm_register_device()\r\n\r\nThe put_device(\u0026amp;stm-\u0026gt;dev) call will trigger stm_device_release() which\nfrees \u0026quot;stm\u0026quot; so the vfree(stm) on the next line is a double free.(CVE-2024-38627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/memory-failure: fix handling of dissolved but not taken off from buddy pages\r\n\r\nWhen I did memory failure tests recently, below panic occurs:\r\n\r\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00\nflags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)\nraw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000\nraw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000\npage dumped because: VM_BUG_ON_PAGE(!PageBuddy(page))\n------------[ cut here ]------------\nkernel BUG at include/linux/page-flags.h:1009!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:__del_page_from_free_list+0x151/0x180\nRSP: 0018:ffffa49c90437998 EFLAGS: 00000046\nRAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0\nRBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69\nR10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80\nR13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009\nFS:  00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rmqueue_pcplist+0x23b/0x520\n get_page_from_freelist+0x26b/0xe40\n __alloc_pages_noprof+0x113/0x1120\n __folio_alloc_noprof+0x11/0xb0\n alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130\n __alloc_fresh_hugetlb_folio+0xe7/0x140\n alloc_pool_huge_folio+0x68/0x100\n set_max_huge_pages+0x13d/0x340\n hugetlb_sysctl_handler_common+0xe8/0x110\n proc_sys_call_handler+0x194/0x280\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xc2/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7ff916114887\nRSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887\nRDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003\nRBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0\nR10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004\nR13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00\n \u0026lt;/TASK\u0026gt;\nModules linked in: mce_inject hwpoison_inject\n---[ end trace 0000000000000000 ]---\r\n\r\nAnd before the panic, there had an warning about bad page state:\r\n\r\nBUG: Bad page state in process page-types  pfn:8cee00\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00\nflags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)\npage_type: 0xffffff7f(buddy)\nraw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000\nraw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000\npage dumped because: nonzero mapcount\nModules linked in: mce_inject hwpoison_inject\nCPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x83/0xa0\n bad_page+0x63/0xf0\n free_unref_page+0x36e/0x5c0\n unpoison_memory+0x50b/0x630\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xcd/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xc2/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f189a514887\nRSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887\nRDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003\nRBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8\nR13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe root cause should be the below race:\r\n\r\n memory_failure\n  try_memory_failure_hugetlb\n   me_huge_page\n    __page_handle_poison\n     dissolve_free_hugetlb_folio\n     drain_all_pages -- Buddy page can be isolated e.g. for compaction.\n     take_page_off_buddy -- Failed as page is not in the \n---truncated---(CVE-2024-39298)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n   MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix missing sk_buff release in seg6_input_core\r\n\r\nThe seg6_input() function is responsible for adding the SRH into a\npacket, delegating the operation to the seg6_input_core(). This function\nuses the skb_cow_head() to ensure that there is sufficient headroom in\nthe sk_buff for accommodating the link-layer header.\nIn the event that the skb_cow_header() function fails, the\nseg6_input_core() catches the error but it does not release the sk_buff,\nwhich will result in a memory leak.\r\n\r\nThis issue was introduced in commit af3b5158b89d (\u0026quot;ipv6: sr: fix BUG due\nto headroom too small after SRH push\u0026quot;) and persists even after commit\n7a3f5b0de364 (\u0026quot;netfilter: add netfilter hooks to SRv6 data plane\u0026quot;),\nwhere the entire seg6_input() code was refactored to deal with netfilter\nhooks.\r\n\r\nThe proposed patch addresses the identified memory leak by requiring the\nseg6_input_core() function to release the sk_buff in the event that\nskb_cow_head() fails.(CVE-2024-39490)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: hda: cs35l56: Fix lifetime of cs_dsp instance\r\n\r\nThe cs_dsp instance is initialized in the driver probe() so it\nshould be freed in the driver remove(). Also fix a missing call\nto cs_dsp_remove() in the error path of cs35l56_hda_common_probe().\r\n\r\nThe call to cs_dsp_remove() was being done in the component unbind\ncallback cs35l56_hda_unbind(). This meant that if the driver was\nunbound and then re-bound it would be using an uninitialized cs_dsp\ninstance.\r\n\r\nIt is best to initialize the cs_dsp instance in probe() so that it\ncan return an error if it fails. The component binding API doesn\u0026apos;t\nhave any error handling so there\u0026apos;s no way to handle a failure if\ncs_dsp was initialized in the bind.(CVE-2024-39491)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_inner: validate mandatory meta and payload\r\n\r\nCheck for mandatory netlink attributes in payload and meta expression\nwhen used embedded from the inner expression, otherwise NULL pointer\ndereference is possible from userspace.(CVE-2024-39504)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix refcount imbalance on inbound connections\r\n\r\nWhen releasing a socket in ax25_release(), we call netdev_put() to\ndecrease the refcount on the associated ax.25 device. However, the\nexecution path for accepting an incoming connection never calls\nnetdev_hold(). This imbalance leads to refcount errors, and ultimately\nto kernel crashes.\r\n\r\nA typical call trace for the above situation will start with one of the\nfollowing errors:\r\n\r\n    refcount_t: decrement hit 0; leaking memory.\n    refcount_t: underflow; use-after-free.\r\n\r\nAnd will then have a trace like:\r\n\r\n    Call Trace:\n    \u0026lt;TASK\u0026gt;\n    ? show_regs+0x64/0x70\n    ? __warn+0x83/0x120\n    ? refcount_warn_saturate+0xb2/0x100\n    ? report_bug+0x158/0x190\n    ? prb_read_valid+0x20/0x30\n    ? handle_bug+0x3e/0x70\n    ? exc_invalid_op+0x1c/0x70\n    ? asm_exc_invalid_op+0x1f/0x30\n    ? refcount_warn_saturate+0xb2/0x100\n    ? refcount_warn_saturate+0xb2/0x100\n    ax25_release+0x2ad/0x360\n    __sock_release+0x35/0xa0\n    sock_close+0x19/0x20\n    [...]\r\n\r\nOn reboot (or any attempt to remove the interface), the kernel gets\nstuck in an infinite loop:\r\n\r\n    unregister_netdevice: waiting for ax0 to become free. Usage count = 0\r\n\r\nThis patch corrects these issues by ensuring that we call netdev_hold()\nand ax25_dev_hold() for new connections in ax25_accept(). This makes the\nlogic leading to ax25_accept() match the logic for ax25_bind(): in both\ncases we increment the refcount, which is ultimately decremented in\nax25_release().(CVE-2024-40910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: Lock wiphy in cfg80211_get_station\r\n\r\nWiphy should be locked before calling rdev_get_station() (see lockdep\nassert in ieee80211_get_station()).\r\n\r\nThis fixes the following kernel NULL dereference:\r\n\r\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050\n Mem abort info:\n   ESR = 0x0000000096000006\n   EC = 0x25: DABT (current EL), IL = 32 bits\n   SET = 0, FnV = 0\n   EA = 0, S1PTW = 0\n   FSC = 0x06: level 2 translation fault\n Data abort info:\n   ISV = 0, ISS = 0x00000006\n   CM = 0, WnR = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000\n [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000\n Internal error: Oops: 0000000096000006 [#1] SMP\n Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath\n CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705\n Hardware name: RPT (r1) (DT)\n Workqueue: bat_events batadv_v_elp_throughput_metric_update\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core]\n lr : sta_set_sinfo+0xcc/0xbd4\n sp : ffff000007b43ad0\n x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98\n x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000\n x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc\n x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000\n x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d\n x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e\n x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000\n x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000\n x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90\n x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000\n Call trace:\n  ath10k_sta_statistics+0x10/0x2dc [ath10k_core]\n  sta_set_sinfo+0xcc/0xbd4\n  ieee80211_get_station+0x2c/0x44\n  cfg80211_get_station+0x80/0x154\n  batadv_v_elp_get_throughput+0x138/0x1fc\n  batadv_v_elp_throughput_metric_update+0x1c/0xa4\n  process_one_work+0x1ec/0x414\n  worker_thread+0x70/0x46c\n  kthread+0xdc/0xe0\n  ret_from_fork+0x10/0x20\n Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)\r\n\r\nThis happens because STA has time to disconnect and reconnect before\nbatadv_v_elp_throughput_metric_update() delayed work gets scheduled. In\nthis situation, ath10k_sta_state() can be in the middle of resetting\narsta data when the work queue get chance to be scheduled and ends up\naccessing it. Locking wiphy prevents that.(CVE-2024-40911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/huge_memory: don\u0026apos;t unpoison huge_zero_folio\r\n\r\nWhen I did memory failure tests recently, below panic occurs:\r\n\r\n kernel BUG at include/linux/mm.h:1135!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14\n RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0\n RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246\n RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8\n RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0\n RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492\n R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00\n FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  do_shrink_slab+0x14f/0x6a0\n  shrink_slab+0xca/0x8c0\n  shrink_node+0x2d0/0x7d0\n  balance_pgdat+0x33a/0x720\n  kswapd+0x1f3/0x410\n  kthread+0xd5/0x100\n  ret_from_fork+0x2f/0x50\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\n Modules linked in: mce_inject hwpoison_inject\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0\n RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246\n RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8\n RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0\n RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492\n R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00\n FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0\r\n\r\nThe root cause is that HWPoison flag will be set for huge_zero_folio\nwithout increasing the folio refcnt.  But then unpoison_memory() will\ndecrease the folio refcnt unexpectedly as it appears like a successfully\nhwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when\nreleasing huge_zero_folio.\r\n\r\nSkip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. \nWe\u0026apos;re not prepared to unpoison huge_zero_folio yet.(CVE-2024-40914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()\r\n\r\nIn case of token is released due to token-\u0026gt;state == BNXT_HWRM_DEFERRED,\nreleased token (set to NULL) is used in log messages. This issue is\nexpected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But\nthis error code is returned by recent firmware. So some firmware may not\nreturn it. This may lead to NULL pointer dereference.\nAdjust this issue by adding token pointer check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix request.queuelist usage in flush\r\n\r\nFriedrich Weber reported a kernel crash problem and bisected to commit\n81ada09cc25e (\u0026quot;blk-flush: reuse rq queuelist in flush state machine\u0026quot;).\r\n\r\nThe root cause is that we use \u0026quot;list_move_tail(\u0026amp;rq-\u0026gt;queuelist, pending)\u0026quot;\nin the PREFLUSH/POSTFLUSH sequences. But rq-\u0026gt;queuelist.next == xxx since\nit\u0026apos;s popped out from plug-\u0026gt;cached_rq in __blk_mq_alloc_requests_batch().\nWe don\u0026apos;t initialize its queuelist just for this first request, although\nthe queuelist of all later popped requests will be initialized.\r\n\r\nFix it by changing to use \u0026quot;list_add_tail(\u0026amp;rq-\u0026gt;queuelist, pending)\u0026quot; so\nrq-\u0026gt;queuelist doesn\u0026apos;t need to be initialized. It should be ok since rq\ncan\u0026apos;t be on any list when PREFLUSH or POSTFLUSH, has no move actually.\r\n\r\nPlease note the commit 81ada09cc25e (\u0026quot;blk-flush: reuse rq queuelist in\nflush state machine\u0026quot;) also has another requirement that no drivers would\ntouch rq-\u0026gt;queuelist after blk_mq_end_request() since we will reuse it to\nadd rq to the post-flush pending list in POSTFLUSH. If this is not true,\nwe will have to revert that commit IMHO.\r\n\r\nThis updated version adds \u0026quot;list_del_init(\u0026amp;rq-\u0026gt;queuelist)\u0026quot; in flush rq\ncallback since the dm layer may submit request of a weird invalid format\n(REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add\nif without this \u0026quot;list_del_init(\u0026amp;rq-\u0026gt;queuelist)\u0026quot;. The weird invalid format\nproblem should be fixed in dm layer.(CVE-2024-40925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()\r\n\r\nClang static checker (scan-build) warning:\nnet/ethtool/ioctl.c:line 2233, column 2\nCalled function pointer is null (null dereference).\r\n\r\nReturn \u0026apos;-EOPNOTSUPP\u0026apos; when \u0026apos;ops-\u0026gt;get_ethtool_phy_stats\u0026apos; is NULL to fix\nthis typo error.(CVE-2024-40928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlandlock: Fix d_parent walk\r\n\r\nThe WARN_ON_ONCE() in collect_domain_accesses() can be triggered when\ntrying to link a root mount point.  This cannot work in practice because\nthis directory is mounted, but the VFS check is done after the call to\nsecurity_path_link().\r\n\r\nDo not use source directory\u0026apos;s d_parent when the source directory is the\nmount point.\r\n\r\n[mic: Fix commit message](CVE-2024-40938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: wwan: iosm: Fix tainted pointer delete is case of region creation fail\r\n\r\nIn case of region creation fail in ipc_devlink_create_region(), previously\ncreated regions delete process starts from tainted pointer which actually\nholds error code value.\nFix this bug by decreasing region index before delete.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix tainted pointer delete is case of flow rules creation fail\r\n\r\nIn case of flow rule creation fail in mlx5_lag_create_port_sel_table(),\ninstead of previously created rules, the tainted pointer is deleted\ndeveral times.\nFix this bug by using correct flow rules pointers.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/kexec: Fix bug with call depth tracking\r\n\r\nThe call to cc_platform_has() triggers a fault and system crash if call depth\ntracking is active because the GS segment has been reset by load_segments() and\nGS_BASE is now 0 but call depth tracking uses per-CPU variables to operate.\r\n\r\nCall cc_platform_has() earlier in the function when GS is still valid.\r\n\r\n  [ bp: Massage. ](CVE-2024-40944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/page_table_check: fix crash on ZONE_DEVICE\r\n\r\nNot all pages may apply to pgtable check.  One example is ZONE_DEVICE\npages: they map PFNs directly, and they don\u0026apos;t allocate page_ext at all\neven if there\u0026apos;s struct page around.  One may reference\ndevm_memremap_pages().\r\n\r\nWhen both ZONE_DEVICE and page-table-check enabled, then try to map some\ndax memories, one can trigger kernel bug constantly now when the kernel\nwas trying to inject some pfn maps on the dax device:\r\n\r\n kernel BUG at mm/page_table_check.c:55!\r\n\r\nWhile it\u0026apos;s pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page\nfault resolutions, skip all the checks if page_ext doesn\u0026apos;t even exist in\npgtable checker, which applies to ZONE_DEVICE but maybe more.(CVE-2024-40948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: huge_memory: fix misused mapping_large_folio_support() for anon folios\r\n\r\nWhen I did a large folios split test, a WARNING \u0026quot;[ 5059.122759][ T166]\nCannot split file folio to non-0 order\u0026quot; was triggered.  But the test cases\nare only for anonmous folios.  while mapping_large_folio_support() is only\nreasonable for page cache folios.\r\n\r\nIn split_huge_page_to_list_to_order(), the folio passed to\nmapping_large_folio_support() maybe anonmous folio.  The folio_test_anon()\ncheck is missing.  So the split of the anonmous THP is failed.  This is\nalso the same for shmem_mapping().  We\u0026apos;d better add a check for both.  But\nthe shmem_mapping() in __split_huge_page() is not involved, as for\nanonmous folios, the end parameter is set to -1, so (head[i].index \u0026gt;= end)\nis always false.  shmem_mapping() is not called.\r\n\r\nAlso add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon\nmapping, So we can detect the wrong use more easily.\r\n\r\nTHP folios maybe exist in the pagecache even the file system doesn\u0026apos;t\nsupport large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is\nenabled, khugepaged will try to collapse read-only file-backed pages to\nTHP.  But the mapping does not actually support multi order large folios\nproperly.\r\n\r\nUsing /sys/kernel/debug/split_huge_pages to verify this, with this patch,\nlarge anon THP is successfully split and the warning is ceased.(CVE-2024-40950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()\r\n\r\nWe can trigger a slab-out-of-bounds with the following commands:\r\n\r\n    mkfs.ext4 -F /dev/$disk 10G\n    mount /dev/$disk /tmp/test\n    echo 2147483647 \u0026gt; /sys/fs/ext4/$disk/mb_group_prealloc\n    echo test \u0026gt; /tmp/test/file \u0026amp;\u0026amp; sync\r\n\r\n==================================================================\nBUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]\nRead of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11\nCPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521\nCall Trace:\n dump_stack_lvl+0x2c/0x50\n kasan_report+0xb6/0xf0\n ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]\n ext4_mb_regular_allocator+0x19e9/0x2370 [ext4]\n ext4_mb_new_blocks+0x88a/0x1370 [ext4]\n ext4_ext_map_blocks+0x14f7/0x2390 [ext4]\n ext4_map_blocks+0x569/0xea0 [ext4]\n ext4_do_writepages+0x10f6/0x1bc0 [ext4]\n[...]\n==================================================================\r\n\r\nThe flow of issue triggering is as follows:\r\n\r\n// Set s_mb_group_prealloc to 2147483647 via sysfs\next4_mb_new_blocks\n  ext4_mb_normalize_request\n    ext4_mb_normalize_group_request\n      ac-\u0026gt;ac_g_ex.fe_len = EXT4_SB(sb)-\u0026gt;s_mb_group_prealloc\n  ext4_mb_regular_allocator\n    ext4_mb_choose_next_group\n      ext4_mb_choose_next_group_best_avail\n        mb_avg_fragment_size_order\n          order = fls(len) - 2 = 29\n        ext4_mb_find_good_group_avg_frag_lists\n          frag_list = \u0026amp;sbi-\u0026gt;s_mb_avg_fragment_size[order]\n          if (list_empty(frag_list)) // Trigger SOOB!\r\n\r\nAt 4k block size, the length of the s_mb_avg_fragment_size list is 14,\nbut an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds\nto be triggered by an attempt to access an element at index 29.\r\n\r\nAdd a new attr_id attr_clusters_in_group with values in the range\n[0, sbi-\u0026gt;s_clusters_per_group] and declare mb_group_prealloc as\nthat type to fix the issue. In addition avoid returning an order\nfrom mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb)\nand reduce some useless loops.(CVE-2024-40955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY.  They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n   BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: don\u0026apos;t set RO when shutting down f2fs\r\n\r\nShutdown does not check the error of thaw_super due to readonly, which\ncauses a deadlock like below.\r\n\r\nf2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC)        issue_discard_thread\n - bdev_freeze\n  - freeze_super\n - f2fs_stop_checkpoint()\n  - f2fs_handle_critical_error                     - sb_start_write\n    - set RO                                         - waiting\n - bdev_thaw\n  - thaw_super_locked\n    - return -EINVAL, if sb_rdonly()\n - f2fs_stop_discard_thread\n  -\u0026gt; wait for kthread_stop(discard_thread);(CVE-2024-40969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nAvoid hw_desc array overrun in dw-axi-dmac\r\n\r\nI have a use case where nr_buffers = 3 and in which each descriptor is composed by 3\nsegments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()\nhandles the hw_desc considering the descs_allocated, this scenario would result in a\nkernel panic (hw_desc array will be overrun).\r\n\r\nTo fix this, the proposal is to add a new member to the axi_dma_desc structure,\nwhere we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in\naxi_desc_put() to handle the hw_desc array correctly.\r\n\r\nAdditionally I propose to remove the axi_chan_start_first_queued() call after completing\nthe transfer, since it was identified that unbalance can occur (started descriptors can\nbe interrupted and transfer ignored due to DMA channel not being enabled).(CVE-2024-40970)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix responder length checking for UD request packets\r\n\r\nAccording to the IBA specification:\nIf a UD request packet is detected with an invalid length, the request\nshall be an invalid request and it shall be silently dropped by\nthe responder. The responder then waits for a new request packet.\r\n\r\ncommit 689c5421bfe0 (\u0026quot;RDMA/rxe: Fix incorrect responder length checking\u0026quot;)\ndefers responder length check for UD QPs in function `copy_data`.\nBut it introduces a regression issue for UD QPs.\r\n\r\nWhen the packet size is too large to fit in the receive buffer.\n`copy_data` will return error code -EINVAL. Then `send_data_in`\nwill return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into\nERROR state.(CVE-2024-40992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: fix integer overflow in max_vclocks_store\r\n\r\nOn 32bit systems, the \u0026quot;4 * max\u0026quot; multiply can overflow.  Use kcalloc()\nto do the allocation to prevent this.(CVE-2024-40994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Avoid splat in pskb_pull_reason\r\n\r\nsyzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug\nhint in pskb_may_pull.\r\n\r\nWe\u0026apos;d like to retain this debug check because it might hint at integer\noverflows and other issues (kernel code should pull headers, not huge\nvalue).\r\n\r\nIn bpf case, this splat isn\u0026apos;t interesting at all: such (nonsensical)\nbpf programs are typically generated by a fuzzer anyway.\r\n\r\nDo what Eric suggested and suppress such warning.\r\n\r\nFor CONFIG_DEBUG_NET=n we don\u0026apos;t need the extra check because\npskb_may_pull will do the right thing: return an error without the\nWARN() backtrace.(CVE-2024-40996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc: fastrpc: Fix memory leak in audio daemon attach operation\r\n\r\nAudio PD daemon send the name as part of the init IOCTL call. This\nname needs to be copied to kernel for which memory is allocated.\nThis memory is never freed which might result in memory leak. Free\nthe memory when it is not needed.(CVE-2024-41025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: toshiba_acpi: Fix array out-of-bounds access\r\n\r\nIn order to use toshiba_dmi_quirks[] together with the standard DMI\nmatching functions, it must be terminated by a empty entry.\r\n\r\nSince this entry is missing, an array out-of-bounds access occurs\nevery time the quirk list is processed.\r\n\r\nFix this by adding the terminating empty entry.(CVE-2024-41028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/filemap: skip to create PMD-sized page cache if needed\r\n\r\nOn ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB.  The\nPMD-sized page cache can\u0026apos;t be supported by xarray as the following error\nmessages indicate.\r\n\r\n------------[ cut here ]------------\nWARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \\\nnft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \\\nnft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \\\nip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm      \\\nfuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64      \\\nsha1_ce virtio_net net_failover virtio_console virtio_blk failover \\\ndimlib virtio_mmio\nCPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : xas_split_alloc+0xf8/0x128\nlr : split_huge_page_to_list_to_order+0x1c4/0x720\nsp : ffff800087a4f6c0\nx29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff\nx26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858\nx23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000\nx20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000\nx17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000\nx14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020\nx11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28\nx8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8\nx5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40\nx2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000\nCall trace:\n xas_split_alloc+0xf8/0x128\n split_huge_page_to_list_to_order+0x1c4/0x720\n truncate_inode_partial_folio+0xdc/0x160\n truncate_inode_pages_range+0x1b4/0x4a8\n truncate_pagecache_range+0x84/0xa0\n xfs_flush_unmap_range+0x70/0x90 [xfs]\n xfs_file_fallocate+0xfc/0x4d8 [xfs]\n vfs_fallocate+0x124/0x2e8\n ksys_fallocate+0x4c/0xa0\n __arm64_sys_fallocate+0x24/0x38\n invoke_syscall.constprop.0+0x7c/0xd8\n do_el0_svc+0xb4/0xd0\n el0_svc+0x44/0x1d8\n el0t_64_sync_handler+0x134/0x150\n el0t_64_sync+0x17c/0x180\r\n\r\nFix it by skipping to allocate PMD-sized page cache when its size is\nlarger than MAX_PAGECACHE_ORDER.  For this specific case, we will fall to\nregular path where the readahead window is determined by BDI\u0026apos;s sysfs file\n(read_ahead_kb).(CVE-2024-41031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ks8851: Fix deadlock with the SPI chip variant\r\n\r\nWhen SMP is enabled and spinlocks are actually functional then there is\na deadlock with the \u0026apos;statelock\u0026apos; spinlock between ks8851_start_xmit_spi\nand ks8851_irq:\r\n\r\n    watchdog: BUG: soft lockup - CPU#0 stuck for 27s!\n    call trace:\n      queued_spin_lock_slowpath+0x100/0x284\n      do_raw_spin_lock+0x34/0x44\n      ks8851_start_xmit_spi+0x30/0xb8\n      ks8851_start_xmit+0x14/0x20\n      netdev_start_xmit+0x40/0x6c\n      dev_hard_start_xmit+0x6c/0xbc\n      sch_direct_xmit+0xa4/0x22c\n      __qdisc_run+0x138/0x3fc\n      qdisc_run+0x24/0x3c\n      net_tx_action+0xf8/0x130\n      handle_softirqs+0x1ac/0x1f0\n      __do_softirq+0x14/0x20\n      ____do_softirq+0x10/0x1c\n      call_on_irq_stack+0x3c/0x58\n      do_softirq_own_stack+0x1c/0x28\n      __irq_exit_rcu+0x54/0x9c\n      irq_exit_rcu+0x10/0x1c\n      el1_interrupt+0x38/0x50\n      el1h_64_irq_handler+0x18/0x24\n      el1h_64_irq+0x64/0x68\n      __netif_schedule+0x6c/0x80\n      netif_tx_wake_queue+0x38/0x48\n      ks8851_irq+0xb8/0x2c8\n      irq_thread_fn+0x2c/0x74\n      irq_thread+0x10c/0x1b0\n      kthread+0xc8/0xd8\n      ret_from_fork+0x10/0x20\r\n\r\nThis issue has not been identified earlier because tests were done on\na device with SMP disabled and so spinlocks were actually NOPs.\r\n\r\nNow use spin_(un)lock_bh for TX queue related locking to avoid execution\nof softirq work synchronously that would lead to a deadlock.(CVE-2024-41036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers\r\n\r\nCheck that all fields of a V2 algorithm header fit into the available\nfirmware data buffer.\r\n\r\nThe wmfw V2 format introduced variable-length strings in the algorithm\nblock header. This means the overall header length is variable, and the\nposition of most fields varies depending on the length of the string\nfields. Each field must be checked to ensure that it does not overflow\nthe firmware data buffer.\r\n\r\nAs this ia bugfix patch, the fixes avoid making any significant change to\nthe existing code. This makes it easier to review and less likely to\nintroduce new bugs.(CVE-2024-41038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Fix XDP program unloading while removing the driver\r\n\r\nThe commit 6533e558c650 (\u0026quot;i40e: Fix reset path while removing\nthe driver\u0026quot;) introduced a new PF state \u0026quot;__I40E_IN_REMOVE\u0026quot; to block\nmodifying the XDP program while the driver is being removed.\nUnfortunately, such a change is useful only if the \u0026quot;.ndo_bpf()\u0026quot;\ncallback was called out of the rmmod context because unloading the\nexisting XDP program is also a part of driver removing procedure.\nIn other words, from the rmmod context the driver is expected to\nunload the XDP program without reporting any errors. Otherwise,\nthe kernel warning with callstack is printed out to dmesg.\r\n\r\nExample failing scenario:\n 1. Load the i40e driver.\n 2. Load the XDP program.\n 3. Unload the i40e driver (using \u0026quot;rmmod\u0026quot; command).\r\n\r\nThe example kernel warning log:\r\n\r\n[  +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870\n[...]\n[  +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870\n[...]\n[  +0.002726] Call Trace:\n[  +0.002457]  \u0026lt;TASK\u0026gt;\n[  +0.002119]  ? __warn+0x80/0x120\n[  +0.003245]  ? unregister_netdevice_many_notify+0x7a9/0x870\n[  +0.005586]  ? report_bug+0x164/0x190\n[  +0.003678]  ? handle_bug+0x3c/0x80\n[  +0.003503]  ? exc_invalid_op+0x17/0x70\n[  +0.003846]  ? asm_exc_invalid_op+0x1a/0x20\n[  +0.004200]  ? unregister_netdevice_many_notify+0x7a9/0x870\n[  +0.005579]  ? unregister_netdevice_many_notify+0x3cc/0x870\n[  +0.005586]  unregister_netdevice_queue+0xf7/0x140\n[  +0.004806]  unregister_netdev+0x1c/0x30\n[  +0.003933]  i40e_vsi_release+0x87/0x2f0 [i40e]\n[  +0.004604]  i40e_remove+0x1a1/0x420 [i40e]\n[  +0.004220]  pci_device_remove+0x3f/0xb0\n[  +0.003943]  device_release_driver_internal+0x19f/0x200\n[  +0.005243]  driver_detach+0x48/0x90\n[  +0.003586]  bus_remove_driver+0x6d/0xf0\n[  +0.003939]  pci_unregister_driver+0x2e/0xb0\n[  +0.004278]  i40e_exit_module+0x10/0x5f0 [i40e]\n[  +0.004570]  __do_sys_delete_module.isra.0+0x197/0x310\n[  +0.005153]  do_syscall_64+0x85/0x170\n[  +0.003684]  ? syscall_exit_to_user_mode+0x69/0x220\n[  +0.004886]  ? do_syscall_64+0x95/0x170\n[  +0.003851]  ? exc_page_fault+0x7e/0x180\n[  +0.003932]  entry_SYSCALL_64_after_hwframe+0x71/0x79\n[  +0.005064] RIP: 0033:0x7f59dc9347cb\n[  +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83\nc8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f\n05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48\n[  +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0\n[  +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb\n[  +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748\n[  +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000\n[  +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000\n[  +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000\n[  +0.007151]  \u0026lt;/TASK\u0026gt;\n[  +0.002204] ---[ end trace 0000000000000000 ]---\r\n\r\nFix this by checking if the XDP program is being loaded or unloaded.\nThen, block only loading a new program while \u0026quot;__I40E_IN_REMOVE\u0026quot; is set.\nAlso, move testing \u0026quot;__I40E_IN_REMOVE\u0026quot; flag to the beginning of XDP_SETUP\ncallback to avoid unnecessary operations and checks.(CVE-2024-41047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: cyclic allocation of msg_id to avoid reuse\r\n\r\nReusing the msg_id after a maliciously completed reopen request may cause\na read request to remain unprocessed and result in a hung, as shown below:\r\n\r\n       t1       |      t2       |      t3\n-------------------------------------------------\ncachefiles_ondemand_select_req\n cachefiles_ondemand_object_is_close(A)\n cachefiles_ondemand_set_object_reopening(A)\n queue_work(fscache_object_wq, \u0026amp;info-\u0026gt;work)\n                ondemand_object_worker\n                 cachefiles_ondemand_init_object(A)\n                  cachefiles_ondemand_send_req(OPEN)\n                    // get msg_id 6\n                    wait_for_completion(\u0026amp;req_A-\u0026gt;done)\ncachefiles_ondemand_daemon_read\n // read msg_id 6 req_A\n cachefiles_ondemand_get_fd\n copy_to_user\n                                // Malicious completion msg_id 6\n                                copen 6,-1\n                                cachefiles_ondemand_copen\n                                 complete(\u0026amp;req_A-\u0026gt;done)\n                                 // will not set the object to close\n                                 // because ondemand_id \u0026amp;\u0026amp; fd is valid.\r\n\r\n                // ondemand_object_worker() is done\n                // but the object is still reopening.\r\n\r\n                                // new open req_B\n                                cachefiles_ondemand_init_object(B)\n                                 cachefiles_ondemand_send_req(OPEN)\n                                 // reuse msg_id 6\nprocess_open_req\n copen 6,A.size\n // The expected failed copen was executed successfully\r\n\r\nExpect copen to fail, and when it does, it closes fd, which sets the\nobject to close, and then close triggers reopen again. However, due to\nmsg_id reuse resulting in a successful copen, the anonymous fd is not\nclosed until the daemon exits. Therefore read requests waiting for reopen\nto complete may trigger hung task.\r\n\r\nTo avoid this issue, allocate the msg_id cyclically to avoid reusing the\nmsg_id for a very short duration of time.(CVE-2024-41050)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: wait for ondemand_object_worker to finish when dropping object\r\n\r\nWhen queuing ondemand_object_worker() to re-open the object,\ncachefiles_object is not pinned. The cachefiles_object may be freed when\nthe pending read request is completed intentionally and the related\nerofs is umounted. If ondemand_object_worker() runs after the object is\nfreed, it will incur use-after-free problem as shown below.\r\n\r\nprocess A  processs B  process C  process D\r\n\r\ncachefiles_ondemand_send_req()\n// send a read req X\n// wait for its completion\r\n\r\n           // close ondemand fd\n           cachefiles_ondemand_fd_release()\n           // set object as CLOSE\r\n\r\n                       cachefiles_ondemand_daemon_read()\n                       // set object as REOPENING\n                       queue_work(fscache_wq, \u0026amp;info-\u0026gt;ondemand_work)\r\n\r\n                                // close /dev/cachefiles\n                                cachefiles_daemon_release\n                                cachefiles_flush_reqs\n                                complete(\u0026amp;req-\u0026gt;done)\r\n\r\n// read req X is completed\n// umount the erofs fs\ncachefiles_put_object()\n// object will be freed\ncachefiles_ondemand_deinit_obj_info()\nkmem_cache_free(object)\n                       // both info and object are freed\n                       ondemand_object_worker()\r\n\r\nWhen dropping an object, it is no longer necessary to reopen the object,\nso use cancel_work_sync() to cancel or wait for ondemand_object_worker()\nto finish.(CVE-2024-41051)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: ufs: core: Fix ufshcd_abort_one racing issue\r\n\r\nWhen ufshcd_abort_one is racing with the completion ISR, the completed tag\nof the request\u0026apos;s mq_hctx pointer will be set to NULL by ISR.  Return\nsuccess when request is completed by ISR because ufshcd_abort_one does not\nneed to do anything.\r\n\r\nThe racing flow is:\r\n\r\nThread A\nufshcd_err_handler\t\t\t\t\tstep 1\n\t...\n\tufshcd_abort_one\n\t\tufshcd_try_to_abort_task\n\t\t\tufshcd_cmd_inflight(true)\tstep 3\n\t\tufshcd_mcq_req_to_hwq\n\t\t\tblk_mq_unique_tag\n\t\t\t\trq-\u0026gt;mq_hctx-\u0026gt;queue_num\tstep 5\r\n\r\nThread B\nufs_mtk_mcq_intr(cq complete ISR)\t\t\tstep 2\n\tscsi_done\n\t\t...\n\t\t__blk_mq_free_request\n\t\t\trq-\u0026gt;mq_hctx = NULL;\t\tstep 4\r\n\r\nBelow is KE back trace.\n  ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device.\n  ufshcd_try_to_abort_task: cmd at tag=41 is cleared.\n  Aborting tag 41 / CDB 0x28 succeeded\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194\n  pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14\n  lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise]\n   do_mem_abort+0x58/0x118\n   el1_abort+0x3c/0x5c\n   el1h_64_sync_handler+0x54/0x90\n   el1h_64_sync+0x68/0x6c\n   blk_mq_unique_tag+0x8/0x14\n   ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]\n   process_one_work+0x208/0x4fc\n   worker_thread+0x228/0x438\n   kthread+0x104/0x1d4\n   ret_from_fork+0x10/0x20(CVE-2024-41053)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: ufs: core: Fix ufshcd_clear_cmd racing issue\r\n\r\nWhen ufshcd_clear_cmd is racing with the completion ISR, the completed tag\nof the request\u0026apos;s mq_hctx pointer will be set to NULL by the ISR.  And\nufshcd_clear_cmd\u0026apos;s call to ufshcd_mcq_req_to_hwq will get NULL pointer KE.\nReturn success when the request is completed by ISR because sq does not\nneed cleanup.\r\n\r\nThe racing flow is:\r\n\r\nThread A\nufshcd_err_handler\t\t\t\t\tstep 1\n\tufshcd_try_to_abort_task\n\t\tufshcd_cmd_inflight(true)\t\tstep 3\n\t\tufshcd_clear_cmd\n\t\t\t...\n\t\t\tufshcd_mcq_req_to_hwq\n\t\t\tblk_mq_unique_tag\n\t\t\t\trq-\u0026gt;mq_hctx-\u0026gt;queue_num\tstep 5\r\n\r\nThread B\nufs_mtk_mcq_intr(cq complete ISR)\t\t\tstep 2\n\tscsi_done\n\t\t...\n\t\t__blk_mq_free_request\n\t\t\trq-\u0026gt;mq_hctx = NULL;\t\tstep 4\r\n\r\nBelow is KE back trace:\r\n\r\n  ufshcd_try_to_abort_task: cmd pending in the device. tag = 6\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194\n   pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14\n   lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise]\n   Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise]\n   Call trace:\n    dump_backtrace+0xf8/0x148\n    show_stack+0x18/0x24\n    dump_stack_lvl+0x60/0x7c\n    dump_stack+0x18/0x3c\n    mrdump_common_die+0x24c/0x398 [mrdump]\n    ipanic_die+0x20/0x34 [mrdump]\n    notify_die+0x80/0xd8\n    die+0x94/0x2b8\n    __do_kernel_fault+0x264/0x298\n    do_page_fault+0xa4/0x4b8\n    do_translation_fault+0x38/0x54\n    do_mem_abort+0x58/0x118\n    el1_abort+0x3c/0x5c\n    el1h_64_sync_handler+0x54/0x90\n    el1h_64_sync+0x68/0x6c\n    blk_mq_unique_tag+0x8/0x14\n    ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise]\n    ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise]\n    ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise]\n    process_one_work+0x208/0x4fc\n    worker_thread+0x228/0x438\n    kthread+0x104/0x1d4\n    ret_from_fork+0x10/0x20(CVE-2024-41054)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: fix slab-use-after-free in fscache_withdraw_volume()\r\n\r\nWe got the following issue in our fault injection stress test:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370\nRead of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798\r\n\r\nCPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565\nCall Trace:\n kasan_check_range+0xf6/0x1b0\n fscache_withdraw_volume+0x2e1/0x370\n cachefiles_withdraw_volume+0x31/0x50\n cachefiles_withdraw_cache+0x3ad/0x900\n cachefiles_put_unbind_pincount+0x1f6/0x250\n cachefiles_daemon_release+0x13b/0x290\n __fput+0x204/0xa00\n task_work_run+0x139/0x230\r\n\r\nAllocated by task 5820:\n __kmalloc+0x1df/0x4b0\n fscache_alloc_volume+0x70/0x600\n __fscache_acquire_volume+0x1c/0x610\n erofs_fscache_register_volume+0x96/0x1a0\n erofs_fscache_register_fs+0x49a/0x690\n erofs_fc_fill_super+0x6c0/0xcc0\n vfs_get_super+0xa9/0x140\n vfs_get_tree+0x8e/0x300\n do_new_mount+0x28c/0x580\n [...]\r\n\r\nFreed by task 5820:\n kfree+0xf1/0x2c0\n fscache_put_volume.part.0+0x5cb/0x9e0\n erofs_fscache_unregister_fs+0x157/0x1b0\n erofs_kill_sb+0xd9/0x1c0\n deactivate_locked_super+0xa3/0x100\n vfs_get_super+0x105/0x140\n vfs_get_tree+0x8e/0x300\n do_new_mount+0x28c/0x580\n [...]\n==================================================================\r\n\r\nFollowing is the process that triggers the issue:\r\n\r\n        mount failed         |         daemon exit\n------------------------------------------------------------\n deactivate_locked_super        cachefiles_daemon_release\n  erofs_kill_sb\n   erofs_fscache_unregister_fs\n    fscache_relinquish_volume\n     __fscache_relinquish_volume\n      fscache_put_volume(fscache_volume, fscache_volume_put_relinquish)\n       zero = __refcount_dec_and_test(\u0026amp;fscache_volume-\u0026gt;ref, \u0026amp;ref);\n                                 cachefiles_put_unbind_pincount\n                                  cachefiles_daemon_unbind\n                                   cachefiles_withdraw_cache\n                                    cachefiles_withdraw_volumes\n                                     list_del_init(\u0026amp;volume-\u0026gt;cache_link)\n       fscache_free_volume(fscache_volume)\n        cache-\u0026gt;ops-\u0026gt;free_volume\n         cachefiles_free_volume\n          list_del_init(\u0026amp;cachefiles_volume-\u0026gt;cache_link);\n        kfree(fscache_volume)\n                                     cachefiles_withdraw_volume\n                                      fscache_withdraw_volume\n                                       fscache_volume-\u0026gt;n_accesses\n                                       // fscache_volume UAF !!!\r\n\r\nThe fscache_volume in cache-\u0026gt;volumes must not have been freed yet, but its\nreference count may be 0. So use the new fscache_try_get_volume() helper\nfunction try to get its reference count.\r\n\r\nIf the reference count of fscache_volume is 0, fscache_put_volume() is\nfreeing it, so wait for it to be removed from cache-\u0026gt;volumes.\r\n\r\nIf its reference count is not 0, call cachefiles_withdraw_volume() with\nreference count protection to avoid the above issue.(CVE-2024-41058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfsplus: fix uninit-value in copy_name\r\n\r\n[syzbot reported]\nBUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160\n sized_strscpy+0xc4/0x160\n copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411\n hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3877 [inline]\n slab_alloc_node mm/slub.c:3918 [inline]\n kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065\n kmalloc include/linux/slab.h:628 [inline]\n hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[Fix]\nWhen allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nibmvnic: Add tx check to prevent skb leak\r\n\r\nBelow is a summary of how the driver stores a reference to an skb during\ntransmit:\n    tx_buff[free_map[consumer_index]]-\u0026gt;skb = new_skb;\n    free_map[consumer_index] = IBMVNIC_INVALID_MAP;\n    consumer_index ++;\nWhere variable data looks like this:\n    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]\n                                               \tconsumer_index^\n    tx_buff == [skb=null, skb=\u0026lt;ptr\u0026gt;, skb=\u0026lt;ptr\u0026gt;, skb=null, skb=null]\r\n\r\nThe driver has checks to ensure that free_map[consumer_index] pointed to\na valid index but there was no check to ensure that this index pointed\nto an unused/null skb address. So, if, by some chance, our free_map and\ntx_buff lists become out of sync then we were previously risking an\nskb memory leak. This could then cause tcp congestion control to stop\nsending packets, eventually leading to ETIMEDOUT.\r\n\r\nTherefore, add a conditional to ensure that the skb address is null. If\nnot then warn the user (because this is still a bug that should be\npatched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncxl/region: Avoid null pointer dereference in region lookup\r\n\r\ncxl_dpa_to_region() looks up a region based on a memdev and DPA.\nIt wrongly assumes an endpoint found mapping the DPA is also of\na fully assembled region. When not true it leads to a null pointer\ndereference looking up the region name.\r\n\r\nThis appears during testing of region lookup after a failure to\nassemble a BIOS defined region or if the lookup raced with the\nassembly of the BIOS defined region.\r\n\r\nFailure to clean up BIOS defined regions that fail assembly is an\nissue in itself and a fix to that problem will alleviate some of\nthe impact. It will not alleviate the race condition so let\u0026apos;s harden\nthis path.\r\n\r\nThe behavior change is that the kernel oops due to a null pointer\ndereference is replaced with a dev_dbg() message noting that an\nendpoint was mapped.\r\n\r\nAdditional comments are added so that future users of this function\ncan more clearly understand what it provides.(CVE-2024-41084)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix double free on error\r\n\r\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\r\n\r\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.(CVE-2024-41087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[  441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[  441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\r\n\r\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\r\n\r\n\u0026lt;6\u0026gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u0026lt;6\u0026gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u0026lt;6\u0026gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u0026lt;3\u0026gt; [414.070354] Unable to pin Y-tiled fence; err:-4\n\u0026lt;3\u0026gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active))\n...\n\u0026lt;4\u0026gt;[  609.603992] ------------[ cut here ]------------\n\u0026lt;2\u0026gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u0026lt;4\u0026gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;4\u0026gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u0026lt;4\u0026gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u0026lt;4\u0026gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u0026lt;4\u0026gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u0026lt;4\u0026gt;[  609.604271] Call Trace:\n\u0026lt;4\u0026gt;[  609.604273]  \u0026lt;TASK\u0026gt;\n...\n\u0026lt;4\u0026gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]\n\u0026lt;4\u0026gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]\n\u0026lt;4\u0026gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]\n\u0026lt;4\u0026gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]\n\u0026lt;4\u0026gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u0026lt;4\u0026gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u0026lt;4\u0026gt;[  609.605440]  process_scheduled_works+0x351/0x690\n...\r\n\r\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\r\n\r\nBefore commit 63baf4f3d587 (\u0026quot;drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\u0026quot;), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u0026gt;active via fence_update().   That commit introduced\nvma-\u0026gt;fence-\u0026gt;active in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u0026gt;active since only idleness of\nfence registers was needed.  But then, another commit 0d86ee35097a\n(\u0026quot;drm/i915/gt: Make fence revocation unequivocal\u0026quot;) replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u0026gt;fence-\u0026gt;active without first waiting on it.\r\n\r\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers.  Fix it by\nwaiting for idleness of vma-\u0026gt;fence-\u0026gt;active in i915_vma_revoke_fence().\r\n\r\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: avoid using null object of framebuffer\r\n\r\nInstead of using state-\u0026gt;fb-\u0026gt;obj[0] directly, get object from framebuffer\nby calling drm_gem_fb_get_obj() and return error code when object is\nnull to avoid using null object of framebuffer.(CVE-2024-41093)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/fbdev-dma: Only set smem_start is enable per module option\r\n\r\nOnly export struct fb_info.fix.smem_start if that is required by the\nuser and the memory does not come from vmalloc().\r\n\r\nSetting struct fb_info.fix.smem_start breaks systems where DMA\nmemory is backed by vmalloc address space. An example error is\nshown below.\r\n\r\n[    3.536043] ------------[ cut here ]------------\n[    3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)\n[    3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98\n[    3.565455] Modules linked in:\n[    3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250\n[    3.577310] Hardware name: NXP i.MX95 19X19 board (DT)\n[    3.582452] Workqueue: events_unbound deferred_probe_work_func\n[    3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    3.595233] pc : __virt_to_phys+0x68/0x98\n[    3.599246] lr : __virt_to_phys+0x68/0x98\n[    3.603276] sp : ffff800083603990\n[    3.677939] Call trace:\n[    3.680393]  __virt_to_phys+0x68/0x98\n[    3.684067]  drm_fbdev_dma_helper_fb_probe+0x138/0x238\n[    3.689214]  __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0\n[    3.695385]  drm_fb_helper_initial_config+0x4c/0x68\n[    3.700264]  drm_fbdev_dma_client_hotplug+0x8c/0xe0\n[    3.705161]  drm_client_register+0x60/0xb0\n[    3.709269]  drm_fbdev_dma_setup+0x94/0x148\r\n\r\nAdditionally, DMA memory is assumed to by contiguous in physical\naddress space, which is not guaranteed by vmalloc().\r\n\r\nResolve this by checking the module flag drm_leak_fbdev_smem when\nDRM allocated the instance of struct fb_info. Fbdev-dma then only\nsets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also\nguarantee that the framebuffer is not located in vmalloc address\nspace.(CVE-2024-41094)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode\r\n\r\nsyzbot reported uninit memory usages during map_{lookup,delete}_elem.\r\n\r\n==========\nBUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]\nBUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796\n__dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]\ndev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796\n____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline]\nbpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38\n___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n__bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237\n==========\r\n\r\nThe reproducer should be in the interpreter mode.\r\n\r\nThe C reproducer is trying to run the following bpf prog:\r\n\r\n    0: (18) r0 = 0x0\n    2: (18) r1 = map[id:49]\n    4: (b7) r8 = 16777216\n    5: (7b) *(u64 *)(r10 -8) = r8\n    6: (bf) r2 = r10\n    7: (07) r2 += -229\n            ^^^^^^^^^^\r\n\r\n    8: (b7) r3 = 8\n    9: (b7) r4 = 0\n   10: (85) call dev_map_lookup_elem#1543472\n   11: (95) exit\r\n\r\nIt is due to the \u0026quot;void *key\u0026quot; (r2) passed to the helper. bpf allows uninit\nstack memory access for bpf prog with the right privileges. This patch\nuses kmsan_unpoison_memory() to mark the stack as initialized.\r\n\r\nThis should address different syzbot reports on the uninit \u0026quot;void *key\u0026quot;\nargument during map_{lookup,delete}_elem.(CVE-2024-42063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mana: Fix possible double free in error handling path\r\n\r\nWhen auxiliary_device_add() returns error and then calls\nauxiliary_device_uninit(), callback function adev_release\ncalls kfree(madev). We shouldn\u0026apos;t call kfree(madev) again\nin the error handling path. Set \u0026apos;madev\u0026apos; to NULL.(CVE-2024-42069)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems\r\n\r\nThe following two shared buffer operations make use of the Shared Buffer\nStatus Register (SBSR):\r\n\r\n # devlink sb occupancy snapshot pci/0000:01:00.0\n # devlink sb occupancy clearmax pci/0000:01:00.0\r\n\r\nThe register has two masks of 256 bits to denote on which ingress /\negress ports the register should operate on. Spectrum-4 has more than\n256 ports, so the register was extended by cited commit with a new\n\u0026apos;port_page\u0026apos; field.\r\n\r\nHowever, when filling the register\u0026apos;s payload, the driver specifies the\nports as absolute numbers and not relative to the first port of the port\npage, resulting in memory corruptions [1].\r\n\r\nFix by specifying the ports relative to the first port of the port page.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\nRead of size 1 at addr ffff8881068cb00f by task devlink/1566\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\n mlxsw_devlink_sb_occ_snapshot+0x75/0xb0\n devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0\n genl_family_rcv_msg_doit+0x20c/0x300\n genl_rcv_msg+0x567/0x800\n netlink_rcv_skb+0x170/0x450\n genl_rcv+0x2d/0x40\n netlink_unicast+0x547/0x830\n netlink_sendmsg+0x8d4/0xdb0\n __sys_sendto+0x49b/0x510\n __x64_sys_sendto+0xe5/0x1c0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[...]\nAllocated by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n copy_verifier_state+0xbc2/0xfb0\n do_check_common+0x2c51/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nFreed by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x109/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xca/0x2b0\n free_verifier_state+0xce/0x270\n do_check_common+0x4828/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-42073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: amd: acp: add a null check for chip_pdev structure\r\n\r\nWhen acp platform device creation is skipped, chip-\u0026gt;chip_pdev value will\nremain NULL. Add NULL check for chip-\u0026gt;chip_pdev structure in\nsnd_acp_resume() function to avoid null pointer dereference.(CVE-2024-42074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix NULL pointer dereference in gfs2_log_flush\r\n\r\nIn gfs2_jindex_free(), set sdp-\u0026gt;sd_jdesc to NULL under the log flush\nlock to provide exclusion against gfs2_log_flush().\r\n\r\nIn gfs2_log_flush(), check if sdp-\u0026gt;sd_jdesc is non-NULL before\ndereferencing it.  Otherwise, we could run into a NULL pointer\ndereference when outstanding glock work races with an unmount\n(glock_work_func -\u0026gt; run_queue -\u0026gt; do_xmote -\u0026gt; inode_go_sync -\u0026gt;\ngfs2_log_flush).(CVE-2024-42079)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock\r\n\r\nWhen config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system\nto enter suspend status with below command:\necho mem \u0026gt; /sys/power/state\nThere will be a deadlock issue occurring. Detailed invoking path as\nbelow:\ndwc3_suspend_common()\n    spin_lock_irqsave(\u0026amp;dwc-\u0026gt;lock, flags);              \u0026lt;-- 1st\n    dwc3_gadget_suspend(dwc);\n        dwc3_gadget_soft_disconnect(dwc);\n            spin_lock_irqsave(\u0026amp;dwc-\u0026gt;lock, flags);      \u0026lt;-- 2nd\nThis issue is exposed by commit c7ebd8149ee5 (\u0026quot;usb: dwc3: gadget: Fix\nNULL pointer dereference in dwc3_gadget_suspend\u0026quot;) that removes the code\nof checking whether dwc-\u0026gt;gadget_driver is NULL or not. It causes the\nfollowing code is executed and deadlock occurs when trying to get the\nspinlock. In fact, the root cause is the commit 5265397f9442(\u0026quot;usb: dwc3:\nRemove DWC3 locking during gadget suspend/resume\u0026quot;) that forgot to remove\nthe lock of otg mode. So, remove the redundant lock of otg mode during\ngadget suspend/resume.(CVE-2024-42085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: common: Don\u0026apos;t call hw_to_ccu_common on hw without common\r\n\r\nIn order to set the rate range of a hw sunxi_ccu_probe calls\nhw_to_ccu_common() assuming all entries in desc-\u0026gt;ccu_clks are contained\nin a ccu_common struct. This assumption is incorrect and, in\nconsequence, causes invalid pointer de-references.\r\n\r\nRemove the faulty call. Instead, add one more loop that iterates over\nthe ccu_clks and sets the rate range, if required.(CVE-2024-42100)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix adding block group to a reclaim list and the unused list during reclaim\r\n\r\nThere is a potential parallel list adding for retrying in\nbtrfs_reclaim_bgs_work and adding to the unused list. Since the block\ngroup is removed from the reclaim list and it is on a relocation work,\nit can be added into the unused list in parallel. When that happens,\nadding it to the reclaim list will corrupt the list head and trigger\nlist corruption like below.\r\n\r\nFix it by taking fs_info-\u0026gt;unused_bgs_lock.\r\n\r\n  [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104\n  [177.514][T2585409] list_del corruption. next-\u0026gt;prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)\n  [177.529][T2585409] ------------[ cut here ]------------\n  [177.537][T2585409] kernel BUG at lib/list_debug.c:65!\n  [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G        W          6.10.0-rc5-kts #1\n  [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022\n  [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]\n  [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286\n  [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000\n  [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40\n  [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08\n  [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0\n  [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000\n  [177.687][T2585409] FS:  0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000\n  [177.700][T2585409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0\n  [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000\n  [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400\n  [177.742][T2585409] PKRU: 55555554\n  [177.748][T2585409] Call Trace:\n  [177.753][T2585409]  \u0026lt;TASK\u0026gt;\n  [177.759][T2585409]  ? __die_body.cold+0x19/0x27\n  [177.766][T2585409]  ? die+0x2e/0x50\n  [177.772][T2585409]  ? do_trap+0x1ea/0x2d0\n  [177.779][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.788][T2585409]  ? do_error_trap+0xa3/0x160\n  [177.795][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.805][T2585409]  ? handle_invalid_op+0x2c/0x40\n  [177.812][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.820][T2585409]  ? exc_invalid_op+0x2d/0x40\n  [177.827][T2585409]  ? asm_exc_invalid_op+0x1a/0x20\n  [177.834][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.843][T2585409]  btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]\r\n\r\nThere is a similar retry_list code in btrfs_delete_unused_bgs(), but it is\nsafe, AFAICS. Since the block group was in the unused list, the used bytes\nshould be 0 when it was added to the unused list. Then, it checks\nblock_group-\u0026gt;{used,reserved,pinned} are still 0 under the\nblock_group-\u0026gt;lock. So, they should be still eligible for the unused list,\nnot the reclaim list.\r\n\r\nThe reason it is safe there it\u0026apos;s because because we\u0026apos;re holding\nspace_info-\u0026gt;groups_sem in write mode.\r\n\r\nThat means no other task can allocate from the block group, so while we\nare at deleted_unused_bgs() it\u0026apos;s not possible for other tasks to\nallocate and deallocate extents from the block group, so it can\u0026apos;t be\nadded to the unused list or the reclaim list by anyone else.\r\n\r\nThe bug can be reproduced by btrfs/166 after a few rounds. In practice\nthis can be hit when relocation cannot find more chunk space and ends\nwith ENOSPC.(CVE-2024-42103)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: unconditionally flush pending work before notifier\r\n\r\nsyzbot reports:\r\n\r\nKASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831\nKASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530\nKASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597\nRead of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45\n[..]\nWorkqueue: events nf_tables_trans_destroy_work\nCall Trace:\n nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline]\n nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline]\n nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597\r\n\r\nProblem is that the notifier does a conditional flush, but its possible\nthat the table-to-be-removed is still referenced by transactions being\nprocessed by the worker, so we need to flush unconditionally.\r\n\r\nWe could make the flush_work depend on whether we found a table to delete\nin nf-next to avoid the flush for most cases.\r\n\r\nAFAICS this problem is only exposed in nf-next, with\ncommit e169285f8c56 (\u0026quot;netfilter: nf_tables: do not store nft_ctx in transaction objects\u0026quot;),\nwith this commit applied there is an unconditional fetch of\ntable-\u0026gt;family which is whats triggering the above splat.(CVE-2024-42109)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: txgbe: initialize num_q_vectors for MSI/INTx interrupts\r\n\r\nWhen using MSI/INTx interrupts, wx-\u0026gt;num_q_vectors is uninitialized.\nThus there will be kernel panic in wx_alloc_q_vectors() to allocate\nqueue vectors.(CVE-2024-42113)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check pipe offset before setting vblank\r\n\r\npipe_ctx has a size of MAX_PIPES so checking its index before accessing\nthe array.\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-42120)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check index msg_id before read or write\r\n\r\n[WHAT]\nmsg_id is used as an array index and it cannot be a negative value, and\ntherefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).\r\n\r\n[HOW]\nCheck whether msg_id is valid before reading and setting.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-42121)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc/nci: Add the inconsistency check between the input data length and count\r\n\r\nwrite$nci(r0, \u0026amp;(0x7f0000000740)=ANY=[@ANYBLOB=\u0026quot;610501\u0026quot;], 0xf)\r\n\r\nSyzbot constructed a write() call with a data length of 3 bytes but a count value\nof 15, which passed too little data to meet the basic requirements of the function\nnci_rf_intf_activated_ntf_packet().\r\n\r\nTherefore, increasing the comparison between data length and count value to avoid\nproblems caused by inconsistent data length and count.(CVE-2024-42130)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX\r\n\r\nSyzbot hit warning in hci_conn_del() caused by freeing handle that was\nnot allocated using ida allocator.\r\n\r\nThis is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by\nhci_le_big_sync_established_evt(), which makes code think it\u0026apos;s unset\nconnection.\r\n\r\nAdd same check for handle upper bound as in hci_conn_set_handle() to\nprevent warning.(CVE-2024-42132)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Ignore too large handle values in BIG\r\n\r\nhci_le_big_sync_established_evt is necessary to filter out cases where the\nhandle value is belonging to ida id range, otherwise ida will be erroneously\nreleased in hci_conn_cleanup.(CVE-2024-42133)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvhost_task: Handle SIGKILL by flushing work and exiting\r\n\r\nInstead of lingering until the device is closed, this has us handle\nSIGKILL by:\r\n\r\n1. marking the worker as killed so we no longer try to use it with\n   new virtqueues and new flush operations.\n2. setting the virtqueue to worker mapping so no new works are queued.\n3. running all the exiting works.(CVE-2024-42135)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncdrom: rearrange last_media_change check to avoid unintentional overflow\r\n\r\nWhen running syzkaller with the newly reintroduced signed integer wrap\nsanitizer we encounter this splat:\r\n\r\n[  366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33\n[  366.021089] -9223372036854775808 - 346321 cannot be represented in type \u0026apos;__s64\u0026apos; (aka \u0026apos;long long\u0026apos;)\n[  366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO\n[  366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1\n[  366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  366.027518] Call Trace:\n[  366.027523]  \u0026lt;TASK\u0026gt;\n[  366.027533]  dump_stack_lvl+0x93/0xd0\n[  366.027899]  handle_overflow+0x171/0x1b0\n[  366.038787] ata1.00: invalid multi_count 32 ignored\n[  366.043924]  cdrom_ioctl+0x2c3f/0x2d10\n[  366.063932]  ? __pm_runtime_resume+0xe6/0x130\n[  366.071923]  sr_block_ioctl+0x15d/0x1d0\n[  366.074624]  ? __pfx_sr_block_ioctl+0x10/0x10\n[  366.077642]  blkdev_ioctl+0x419/0x500\n[  366.080231]  ? __pfx_blkdev_ioctl+0x10/0x10\n...\r\n\r\nHistorically, the signed integer overflow sanitizer did not work in the\nkernel due to its interaction with `-fwrapv` but this has since been\nchanged [1] in the newest version of Clang. It was re-enabled in the\nkernel with Commit 557f8c582a9ba8ab (\u0026quot;ubsan: Reintroduce signed overflow\nsanitizer\u0026quot;).\r\n\r\nLet\u0026apos;s rearrange the check to not perform any arithmetic, thus not\ntripping the sanitizer.(CVE-2024-42136)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file\r\n\r\nIn case of invalid INI file mlxsw_linecard_types_init() deallocates memory\nbut doesn\u0026apos;t reset pointer to NULL and returns 0. In case of any error\noccurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init()\ncalls mlxsw_linecard_types_fini() which performs memory deallocation again.\r\n\r\nAdd pointer reset to NULL.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42138)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: kexec: Avoid deadlock in kexec crash path\r\n\r\nIf the kexec crash code is called in the interrupt context, the\nmachine_kexec_mask_interrupts() function will trigger a deadlock while\ntrying to acquire the irqdesc spinlock and then deactivate irqchip in\nirq_set_irqchip_state() function.\r\n\r\nUnlike arm64, riscv only requires irq_eoi handler to complete EOI and\nkeeping irq_set_irqchip_state() will only leave this possible deadlock\nwithout any use. So we simply remove it.(CVE-2024-42140)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: E-switch, Create ingress ACL when needed\r\n\r\nCurrently, ingress acl is used for three features. It is created only\nwhen vport metadata match and prio tag are enabled. But active-backup\nlag mode also uses it. It is independent of vport metadata match and\nprio tag. And vport metadata match can be disabled using the\nfollowing devlink command:\r\n\r\n # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \\\n\tvalue false cmode runtime\r\n\r\nIf ingress acl is not created, will hit panic when creating drop rule\nfor active-backup lag mode. If always create it, there will be about\n5% performance degradation.\r\n\r\nFix it by creating ingress acl when needed. If esw_port_metadata is\ntrue, ingress acl exists, then create drop rule using existing\ningress acl. If esw_port_metadata is false, create ingress acl and\nthen create drop rule.(CVE-2024-42142)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data\r\n\r\nVerify that lvts_data is not NULL before using it.(CVE-2024-42144)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of clear-key structures on failure\r\n\r\nWipe all sensitive data from stack for all IOCTLs, which convert a\nclear-key into a protected- or secure-key.(CVE-2024-42156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: check validation of fault attrs in f2fs_build_fault_attr()\r\n\r\n- It missed to check validation of fault attrs in parse_options(),\nlet\u0026apos;s fix to add check condition in f2fs_build_fault_attr().\n- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD\r\n\r\n[Changes from V1:\n - Use a default branch in the switch statement to initialize `val\u0026apos;.]\r\n\r\nGCC warns that `val\u0026apos; may be used uninitialized in the\nBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:\r\n\r\n\t[...]\n\tunsigned long long val;\t\t\t\t\t\t      \\\n\t[...]\t\t\t\t\t\t\t\t      \\\n\tswitch (__CORE_RELO(s, field, BYTE_SIZE)) {\t\t\t      \\\n\tcase 1: val = *(const unsigned char *)p; break;\t\t\t      \\\n\tcase 2: val = *(const unsigned short *)p; break;\t\t      \\\n\tcase 4: val = *(const unsigned int *)p; break;\t\t\t      \\\n\tcase 8: val = *(const unsigned long long *)p; break;\t\t      \\\n        }       \t\t\t\t\t\t\t      \\\n\t[...]\n\tval;\t\t\t\t\t\t\t\t      \\\n\t}\t\t\t\t\t\t\t\t      \\\r\n\r\nThis patch adds a default entry in the switch statement that sets\n`val\u0026apos; to zero in order to avoid the warning, and random values to be\nused in case __builtin_preserve_field_info returns unexpected values\nfor BPF_FIELD_BYTE_SIZE.\r\n\r\nTested in bpf-next master.\nNo regressions.(CVE-2024-42161)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: mv88e6xxx: Correct check for empty list\r\n\r\nSince commit a3c53be55c95 (\u0026quot;net: dsa: mv88e6xxx: Support multiple MDIO\nbusses\u0026quot;) mv88e6xxx_default_mdio_bus() has checked that the\nreturn value of list_first_entry() is non-NULL.\r\n\r\nThis appears to be intended to guard against the list chip-\u0026gt;mdios being\nempty.  However, it is not the correct check as the implementation of\nlist_first_entry is not designed to return NULL for empty lists.\r\n\r\nInstead, use list_first_entry_or_null() which does return NULL if the\nlist is empty.\r\n\r\nFlagged by Smatch.\nCompile tested only.(CVE-2024-42224)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mt76: replace skb_put with skb_put_zero\r\n\r\nAvoid potentially reusing uninitialized data(CVE-2024-42225)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n        tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed.  That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix missing lock on sync reset reload\r\n\r\nOn sync reset reload work, when remote host updates devlink on reload\nactions performed on that host, it misses taking devlink lock before\ncalling devlink_remote_reload_actions_performed() which results in\ntriggering lock assert like the following:\r\n\r\nWARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50\n…\n CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S      W          6.10.0-rc2+ #116\n Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015\n Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core]\n RIP: 0010:devl_assert_locked+0x3e/0x50\n…\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __warn+0xa4/0x210\n  ? devl_assert_locked+0x3e/0x50\n  ? report_bug+0x160/0x280\n  ? handle_bug+0x3f/0x80\n  ? exc_invalid_op+0x17/0x40\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? devl_assert_locked+0x3e/0x50\n  devlink_notify+0x88/0x2b0\n  ? mlx5_attach_device+0x20c/0x230 [mlx5_core]\n  ? __pfx_devlink_notify+0x10/0x10\n  ? process_one_work+0x4b6/0xbb0\n  process_one_work+0x4b6/0xbb0\n[…](CVE-2024-42268)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init().\r\n\r\nip6table_nat_table_init() accesses net-\u0026gt;gen-\u0026gt;ptr[ip6table_nat_net_ops.id],\nbut the function is exposed to user space before the entry is allocated\nvia register_pernet_subsys().\r\n\r\nLet\u0026apos;s call register_pernet_subsys() before xt_register_template().(CVE-2024-42269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().\r\n\r\nWe had a report that iptables-restore sometimes triggered null-ptr-deref\nat boot time. [0]\r\n\r\nThe problem is that iptable_nat_table_init() is exposed to user space\nbefore the kernel fully initialises netns.\r\n\r\nIn the small race window, a user could call iptable_nat_table_init()\nthat accesses net_generic(net, iptable_nat_net_id), which is available\nonly after registering iptable_nat_net_ops.\r\n\r\nLet\u0026apos;s call register_pernet_subsys() before xt_register_template().\r\n\r\n[0]:\nbpfilter: Loaded bpfilter_umh pid 11702\nStarted bpfilter\nBUG: kernel NULL pointer dereference, address: 0000000000000013\n PF: supervisor write access in kernel mode\n PF: error_code(0x0002) - not-present page\nPGD 0 P4D 0\nPREEMPT SMP NOPTI\nCPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1\nHardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017\nRIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\nCode: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 \u0026lt;48\u0026gt; 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c\nRSP: 0018:ffffbef902843cd0 EFLAGS: 00010246\nRAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80\nRDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0\nRBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240\nR10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000\nR13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004\nFS:  00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? xt_find_table_lock (net/netfilter/x_tables.c:1259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? page_fault_oops (arch/x86/mm/fault.c:727)\n ? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518)\n ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570)\n ? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\n xt_find_table_lock (net/netfilter/x_tables.c:1259)\n xt_request_find_table_lock (net/netfilter/x_tables.c:1287)\n get_info (net/ipv4/netfilter/ip_tables.c:965)\n ? security_capable (security/security.c:809 (discriminator 13))\n ? ns_capable (kernel/capability.c:376 kernel/capability.c:397)\n ? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656)\n ? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter\n nf_getsockopt (net/netfilter/nf_sockopt.c:116)\n ip_getsockopt (net/ipv4/ip_sockglue.c:1827)\n __sys_getsockopt (net/socket.c:2327)\n __x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339)\n do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)\nRIP: 0033:0x7f62844685ee\nCode: 48 8b 0d 45 28 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09\nRSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037\nRAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0\nR10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2\nR13: 00007f6284\n---truncated---(CVE-2024-42270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: assign CURSEG_ALL_DATA_ATGC if blkaddr is valid\r\n\r\nmkdir /mnt/test/comp\nf2fs_io setflags compression /mnt/test/comp\ndd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1\ntruncate --size 13 /mnt/test/comp/testfile\r\n\r\nIn the above scenario, we can get a BUG_ON.\n kernel BUG at fs/f2fs/segment.c:3589!\n Call Trace:\n  do_write_page+0x78/0x390 [f2fs]\n  f2fs_outplace_write_data+0x62/0xb0 [f2fs]\n  f2fs_do_write_data_page+0x275/0x740 [f2fs]\n  f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs]\n  f2fs_write_multi_pages+0x1e5/0xae0 [f2fs]\n  f2fs_write_cache_pages+0xab1/0xc60 [f2fs]\n  f2fs_write_data_pages+0x2d8/0x330 [f2fs]\n  do_writepages+0xcf/0x270\n  __writeback_single_inode+0x44/0x350\n  writeback_sb_inodes+0x242/0x530\n  __writeback_inodes_wb+0x54/0xf0\n  wb_writeback+0x192/0x310\n  wb_workfn+0x30d/0x400\r\n\r\nThe reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the\npage was set the gcing flag by set_cluster_dirty().(CVE-2024-42273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRevert \u0026quot;ALSA: firewire-lib: operate for period elapse event in process context\u0026quot;\r\n\r\nCommit 7ba5ca32fe6e (\u0026quot;ALSA: firewire-lib: operate for period elapse event\nin process context\u0026quot;) removed the process context workqueue from\namdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove\nits overhead.\r\n\r\nWith RME Fireface 800, this lead to a regression since\nKernels 5.14.0, causing an AB/BA deadlock competition for the\nsubstream lock with eventual system freeze under ALSA operation:\r\n\r\nthread 0:\n    * (lock A) acquire substream lock by\n\tsnd_pcm_stream_lock_irq() in\n\tsnd_pcm_status64()\n    * (lock B) wait for tasklet to finish by calling\n    \ttasklet_unlock_spin_wait() in\n\ttasklet_disable_in_atomic() in\n\tohci_flush_iso_completions() of ohci.c\r\n\r\nthread 1:\n    * (lock B) enter tasklet\n    * (lock A) attempt to acquire substream lock,\n    \twaiting for it to be released:\n\tsnd_pcm_stream_lock_irqsave() in\n    \tsnd_pcm_period_elapsed() in\n\tupdate_pcm_pointers() in\n\tprocess_ctx_payloads() in\n\tprocess_rx_packets() of amdtp-stream.c\r\n\r\n? tasklet_unlock_spin_wait\n \u0026lt;/NMI\u0026gt;\n \u0026lt;TASK\u0026gt;\nohci_flush_iso_completions firewire_ohci\namdtp_domain_stream_pcm_pointer snd_firewire_lib\nsnd_pcm_update_hw_ptr0 snd_pcm\nsnd_pcm_status64 snd_pcm\r\n\r\n? native_queued_spin_lock_slowpath\n \u0026lt;/NMI\u0026gt;\n \u0026lt;IRQ\u0026gt;\n_raw_spin_lock_irqsave\nsnd_pcm_period_elapsed snd_pcm\nprocess_rx_packets snd_firewire_lib\nirq_target_callback snd_firewire_lib\nhandle_it_packet firewire_ohci\ncontext_tasklet firewire_ohci\r\n\r\nRestore the process context work queue to prevent deadlock\nAB/BA deadlock competition for ALSA substream lock of\nsnd_pcm_stream_lock_irq() in snd_pcm_status64()\nand snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().\r\n\r\nrevert commit 7ba5ca32fe6e (\u0026quot;ALSA: firewire-lib: operate for period\nelapse event in process context\u0026quot;)\r\n\r\nReplace inline description to prevent future deadlock.(CVE-2024-42274)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n        conn_id-\u0026gt;cm_id.iw = cm_id;\n        cm_id-\u0026gt;context = conn_id;\n        cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/DPC: Fix use-after-free on concurrent DPC and hot-removal\r\n\r\nKeith reports a use-after-free when a DPC event occurs concurrently to\nhot-removal of the same portion of the hierarchy:\r\n\r\nThe dpc_handler() awaits readiness of the secondary bus below the\nDownstream Port where the DPC event occurred.  To do so, it polls the\nconfig space of the first child device on the secondary bus.  If that\nchild device is concurrently removed, accesses to its struct pci_dev\ncause the kernel to oops.\r\n\r\nThat\u0026apos;s because pci_bridge_wait_for_secondary_bus() neglects to hold a\nreference on the child device.  Before v6.3, the function was only\ncalled on resume from system sleep or on runtime resume.  Holding a\nreference wasn\u0026apos;t necessary back then because the pciehp IRQ thread\ncould never run concurrently.  (On resume from system sleep, IRQs are\nnot enabled until after the resume_noirq phase.  And runtime resume is\nalways awaited before a PCI device is removed.)\r\n\r\nHowever starting with v6.3, pci_bridge_wait_for_secondary_bus() is also\ncalled on a DPC event.  Commit 53b54ad074de (\u0026quot;PCI/DPC: Await readiness\nof secondary bus after reset\u0026quot;), which introduced that, failed to\nappreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a\nreference on the child device because dpc_handler() and pciehp may\nindeed run concurrently.  The commit was backported to v5.10+ stable\nkernels, so that\u0026apos;s the oldest one affected.\r\n\r\nAdd the missing reference acquisition.\r\n\r\nAbridged stack trace:\r\n\r\n  BUG: unable to handle page fault for address: 00000000091400c0\n  CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0\n  RIP: pci_bus_read_config_dword+0x17/0x50\n  pci_dev_wait()\n  pci_bridge_wait_for_secondary_bus()\n  dpc_reset_link()\n  pcie_do_recovery()\n  dpc_handler()(CVE-2024-42302)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkvm: s390: Reject memory region operations for ucontrol VMs\r\n\r\nThis change rejects the KVM_SET_USER_MEMORY_REGION and\nKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.\nThis is necessary since ucontrol VMs have kvm-\u0026gt;arch.gmap set to 0 and\nwould thus result in a null pointer dereference further in.\nMemory management needs to be performed in userspace and using the\nioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.\r\n\r\nAlso improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION\nand KVM_SET_USER_MEMORY_REGION2.\r\n\r\n[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix](CVE-2024-43819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncgroup/cpuset: Prevent UAF in proc_cpuset_show()\r\n\r\nAn UAF can happen when /proc/cpuset is read as reported in [1].\r\n\r\nThis can be reproduced by the following methods:\n1.add an mdelay(1000) before acquiring the cgroup_lock In the\n cgroup_path_ns function.\n2.$cat /proc/\u0026lt;pid\u0026gt;/cpuset   repeatly.\n3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/\n$umount /sys/fs/cgroup/cpuset/   repeatly.\r\n\r\nThe race that cause this bug can be shown as below:\r\n\r\n(umount)\t\t|\t(cat /proc/\u0026lt;pid\u0026gt;/cpuset)\ncss_release\t\t|\tproc_cpuset_show\ncss_release_work_fn\t|\tcss = task_get_css(tsk, cpuset_cgrp_id);\ncss_free_rwork_fn\t|\tcgroup_path_ns(css-\u0026gt;cgroup, ...);\ncgroup_destroy_root\t|\tmutex_lock(\u0026amp;cgroup_mutex);\nrebind_subsystems\t|\ncgroup_free_root \t|\n\t\t\t|\t// cgrp was freed, UAF\n\t\t\t|\tcgroup_path_ns_locked(cgrp,..);\r\n\r\nWhen the cpuset is initialized, the root node top_cpuset.css.cgrp\nwill point to \u0026amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will\nallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated\n\u0026amp;cgroup_root.cgrp. When the umount operation is executed,\ntop_cpuset.css.cgrp will be rebound to \u0026amp;cgrp_dfl_root.cgrp.\r\n\r\nThe problem is that when rebinding to cgrp_dfl_root, there are cases\nwhere the cgroup_root allocated by setting up the root for cgroup v1\nis cached. This could lead to a Use-After-Free (UAF) if it is\nsubsequently freed. The descendant cgroups of cgroup v1 can only be\nfreed after the css is released. However, the css of the root will never\nbe released, yet the cgroup_root should be freed when it is unmounted.\nThis means that obtaining a reference to the css of the root does\nnot guarantee that css.cgrp-\u0026gt;root will not be freed.\r\n\r\nFix this problem by using rcu_read_lock in proc_cpuset_show().\nAs cgroup_root is kfree_rcu after commit d23b5c577715\n(\u0026quot;cgroup: Make operations on the cgroup root_list RCU safe\u0026quot;),\ncss-\u0026gt;cgroup won\u0026apos;t be freed during the critical section.\nTo call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to\nreplace task_get_css with task_css.\r\n\r\n[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Fix CT entry update leaks of modify header context\r\n\r\nThe cited commit allocates a new modify header to replace the old\none when updating CT entry. But if failed to allocate a new one, eg.\nexceed the max number firmware can support, modify header will be\nan error pointer that will trigger a panic when deallocating it. And\nthe old modify header point is copied to old attr. When the old\nattr is freed, the old modify header is lost.\r\n\r\nFix it by restoring the old attr to attr when failed to allocate a\nnew modify header context. So when the CT entry is freed, the right\nmodify header context will be freed. And the panic of accessing\nerror pointer is also fixed.(CVE-2024-43864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Always drain health in shutdown callback\r\n\r\nThere is no point in recovery during device shutdown. if health\nwork started need to wait for it to avoid races and NULL pointer\naccess.\r\n\r\nHence, drain health WQ on shutdown callback.(CVE-2024-43866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv/purgatory: align riscv_kernel_entry\r\n\r\nWhen alignment handling is delegated to the kernel, everything must be\nword-aligned in purgatory, since the trap handler is then set to the\nkexec one. Without the alignment, hitting the exception would\nultimately crash. On other occasions, the kernel\u0026apos;s handler would take\ncare of exceptions.\nThis has been tested on a JH7110 SoC with oreboot and its SBI delegating\nunaligned access exceptions and the kernel configured to handle them.(CVE-2024-43868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf: Fix event leak upon exec and file release\r\n\r\nThe perf pending task work is never waited upon the matching event\nrelease. In the case of a child event, released via free_event()\ndirectly, this can potentially result in a leaked event, such as in the\nfollowing scenario that doesn\u0026apos;t even require a weak IRQ work\nimplementation to trigger:\r\n\r\nschedule()\n   prepare_task_switch()\n=======\u0026gt; \u0026lt;NMI\u0026gt;\n      perf_event_overflow()\n         event-\u0026gt;pending_sigtrap = ...\n         irq_work_queue(\u0026amp;event-\u0026gt;pending_irq)\n\u0026lt;======= \u0026lt;/NMI\u0026gt;\n      perf_event_task_sched_out()\n          event_sched_out()\n              event-\u0026gt;pending_sigtrap = 0;\n              atomic_long_inc_not_zero(\u0026amp;event-\u0026gt;refcount)\n              task_work_add(\u0026amp;event-\u0026gt;pending_task)\n   finish_lock_switch()\n=======\u0026gt; \u0026lt;IRQ\u0026gt;\n   perf_pending_irq()\n      //do nothing, rely on pending task work\n\u0026lt;======= \u0026lt;/IRQ\u0026gt;\r\n\r\nbegin_new_exec()\n   perf_event_exit_task()\n      perf_event_exit_event()\n         // If is child event\n         free_event()\n            WARN(atomic_long_cmpxchg(\u0026amp;event-\u0026gt;refcount, 1, 0) != 1)\n            // event is leaked\r\n\r\nSimilar scenarios can also happen with perf_event_remove_on_exec() or\nsimply against concurrent perf_event_release().\r\n\r\nFix this with synchonizing against the possibly remaining pending task\nwork while freeing the event, just like is done with remaining pending\nIRQ work. This means that the pending task callback neither need nor\nshould hold a reference to the event, preventing it from ever beeing\nfreed.(CVE-2024-43869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug  7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug  7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to cover read extent cache access with lock\r\n\r\nsyzbot reports a f2fs bug as below:\r\n\r\nBUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46\nRead of size 4 at addr ffff8880739ab220 by task syz-executor200/5097\r\n\r\nCPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46\n do_read_inode fs/f2fs/inode.c:509 [inline]\n f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560\n f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237\n generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413\n exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444\n exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584\n do_handle_to_path fs/fhandle.c:155 [inline]\n handle_to_path fs/fhandle.c:210 [inline]\n do_handle_open+0x495/0x650 fs/fhandle.c:226\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nWe missed to cover sanity_check_extent_cache() w/ extent cache lock,\nso, below race case may happen, result in use after free issue.\r\n\r\n- f2fs_iget\n - do_read_inode\n  - f2fs_init_read_extent_tree\n  : add largest extent entry in to cache\n\t\t\t\t\t- shrink\n\t\t\t\t\t - f2fs_shrink_read_extent_tree\n\t\t\t\t\t  - __shrink_extent_tree\n\t\t\t\t\t   - __detach_extent_node\n\t\t\t\t\t   : drop largest extent entry\n  - sanity_check_extent_cache\n  : access et-\u0026gt;largest w/o lock\r\n\r\nlet\u0026apos;s refactor sanity_check_extent_cache() to avoid extent cache access\nand call it before f2fs_init_read_extent_tree() to fix this issue.(CVE-2024-44941)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-39.0.0.47.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-39.0.0.47.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-devel-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-headers-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-source-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-tools-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-39.0.0.47.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-39.0.0.47.oe2403.aarch64.rpm","perf-6.6.0-39.0.0.47.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-39.0.0.47.oe2403.aarch64.rpm","python3-perf-6.6.0-39.0.0.47.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-39.0.0.47.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-39.0.0.47.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-39.0.0.47.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-devel-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-headers-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-source-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-tools-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-39.0.0.47.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-39.0.0.47.oe2403.x86_64.rpm","perf-6.6.0-39.0.0.47.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-39.0.0.47.oe2403.x86_64.rpm","python3-perf-6.6.0-39.0.0.47.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-39.0.0.47.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-33621"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-33847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-34777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36281"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36286"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36484"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36908"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36933"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36959"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38390"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38539"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38543"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38544"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38546"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38550"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38557"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38560"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38561"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38565"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38566"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38580"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38593"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38613"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38616"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38635"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39276"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39298"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39490"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39491"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39504"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40910"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40925"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40939"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40944"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40945"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40988"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41030"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41031"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41036"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41050"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41060"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41068"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41088"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41092"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41093"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42069"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42070"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42100"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42109"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42121"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42130"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42132"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42133"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42138"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42140"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42144"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42161"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42224"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42225"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42230"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42265"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42267"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42268"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42273"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42274"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42284"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42285"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43819"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43824"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43853"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43864"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43866"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43868"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43869"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43882"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44941"}],"database_specific":{"severity":"High"}}