Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format<br /> <br /> On 64 bit host, if the guest doesn&amp;#39;t have X86_FEATURE_LM, KVM will<br /> access 16 gprs to 32-bit smram image, causing out-ouf-bound ram<br /> access.<br /> <br /> On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64<br /> is compiled out, thus access overflow can&amp;#39;t happen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Initialize gfn_to_pfn_cache locks in dedicated helper<br /> <br /> Move the gfn_to_pfn_cache lock initialization to another helper and<br /> call the new helper during VM/vCPU creation. There are race<br /> conditions possible due to kvm_gfn_to_pfn_cache_init()&amp;#39;s<br /> ability to re-initialize the cache&amp;#39;s locks.<br /> <br /> For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and<br /> kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.<br /> <br /> (thread 1) | (thread 2)<br /> |<br /> kvm_xen_set_evtchn_fast |<br /> read_lock_irqsave(&amp;gpc-&gt;lock, ...) |<br /> | kvm_gfn_to_pfn_cache_init<br /> | rwlock_init(&amp;gpc-&gt;lock)<br /> read_unlock_irqrestore(&amp;gpc-&gt;lock, ...) |<br /> <br /> Rename "cache_init" and "cache_destroy" to activate+deactivate to<br /> avoid implying that the cache really is destroyed/freed.<br /> <br /> Note, there more races in the newly named kvm_gpc_activate() that will<br /> be addressed separately.<br /> <br /> [sean: call out that this is a bug fix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/tdx: Panic on bad configs that #VE on "private" memory access<br /> <br /> All normal kernel memory is "TDX private memory". This includes<br /> everything from kernel stacks to kernel text. Handling<br /> exceptions on arbitrary accesses to kernel memory is essentially<br /> impossible because they can happen in horribly nasty places like<br /> kernel entry/exit. But, TDX hardware can theoretically _deliver_<br /> a virtualization exception (#VE) on any access to private memory.<br /> <br /> But, it&amp;#39;s not as bad as it sounds. TDX can be configured to never<br /> deliver these exceptions on private memory with a "TD attribute"<br /> called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this<br /> attribute, but it can check it.<br /> <br /> Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it<br /> is unset. There is no sane way for Linux to run with this<br /> attribute clear so a panic() is appropriate.<br /> <br /> There&amp;#39;s small window during boot before the check where kernel<br /> has an early #VE handler. But the handler is only for port I/O<br /> and will also panic() as soon as it sees any other #VE, such as<br /> a one generated by a private memory access.<br /> <br /> [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().<br /> Add Kirill&amp;#39;s tested-by because I made changes since<br /> he wrote this. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()<br /> <br /> On some machines the number of listed CPUs may be bigger than the actual<br /> CPUs that exist. The tracing subsystem allocates a per_cpu directory with<br /> access to the per CPU ring buffer via a cpuX file. But to save space, the<br /> ring buffer will only allocate buffers for online CPUs, even though the<br /> CPU array will be as big as the nr_cpu_ids.<br /> <br /> With the addition of waking waiters on the ring buffer when closing the<br /> file, the ring_buffer_wake_waiters() now needs to make sure that the<br /> buffer is allocated (with the irq_work allocated with it) before trying to<br /> wake waiters, as it will cause a NULL pointer dereference.<br /> <br /> While debugging this, I added a NULL check for the buffer itself (which is<br /> OK to do), and also NULL pointer checks against buffer-&gt;buffers (which is<br /> not fine, and will WARN) as well as making sure the CPU number passed in<br /> is within the nr_cpu_ids (which is also not fine if it isn&amp;#39;t).<br /> <br /> <br /> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: avoid kprobe recursion<br /> <br /> The cortex_a76_erratum_1463225_debug_handler() function is called when<br /> handling debug exceptions (and synchronous exceptions from BRK<br /> instructions), and so is called when a probed function executes. If the<br /> compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it<br /> can be probed.<br /> <br /> If cortex_a76_erratum_1463225_debug_handler() is probed, any debug<br /> exception or software breakpoint exception will result in recursive<br /> exceptions leading to a stack overflow. This can be triggered with the<br /> ftrace multiple_probes selftest, and as per the example splat below.<br /> <br /> This is a regression caused by commit:<br /> <br /> 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")<br /> <br /> ... which removed the NOKPROBE_SYMBOL() annotation associated with the<br /> function.<br /> <br /> My intent was that cortex_a76_erratum_1463225_debug_handler() would be<br /> inlined into its caller, el1_dbg(), which is marked noinstr and cannot<br /> be probed. Mark cortex_a76_erratum_1463225_debug_handler() as<br /> __always_inline to ensure this.<br /> <br /> Example splat prior to this patch (with recursive entries elided):<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo p do_el0_svc &gt;&gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/enable<br /> | Insufficient stack space to handle exception!<br /> | ESR: 0x0000000096000047 -- DABT (current EL)<br /> | FAR: 0xffff800009cefff0<br /> | Task stack: [0xffff800009cf0000..0xffff800009cf4000]<br /> | IRQ stack: [0xffff800008000000..0xffff800008004000]<br /> | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : arm64_enter_el1_dbg+0x4/0x20<br /> | lr : el1_dbg+0x24/0x5c<br /> | sp : ffff800009cf0000<br /> | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000<br /> | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068<br /> | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000<br /> | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0<br /> | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4<br /> | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040<br /> | Kernel panic - not syncing: kernel stack overflow<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Call trace:<br /> | dump_backtrace+0xe4/0x104<br /> | show_stack+0x18/0x4c<br /> | dump_stack_lvl+0x64/0x7c<br /> | dump_stack+0x18/0x38<br /> | panic+0x14c/0x338<br /> | test_taint+0x0/0x2c<br /> | panic_bad_stack+0x104/0x118<br /> | handle_bad_stack+0x34/0x48<br /> | __bad_stack+0x78/0x7c<br /> | arm64_enter_el1_dbg+0x4/0x20<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | do_el0_svc+0x0/0x28<br /> | el0t_64_sync_handler+0x84/0xf0<br /> | el0t_64_sync+0x18c/0x190<br /> | Kernel Offset: disabled<br /> | CPU features: 0x0080,00005021,19001080<br /> | Memory Limit: none<br /> | ---[ end Kernel panic - not syncing: kernel stack overflow ]---<br /> <br /> With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined<br /> into el1_dbg(), and el1_dbg() cannot be probed:<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | sh: write error: No such file or directory<br /> | # grep -w cortex_a76_errat<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: meson: vdec: fix possible refcount leak in vdec_probe()<br /> <br /> v4l2_device_unregister need to be called to put the refcount got by<br /> v4l2_device_register when vdec_probe fails or vdec_remove is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()<br /> <br /> Change num_ghes from int to unsigned int, preventing an overflow<br /> and causing subsequent vmalloc() to fail.<br /> <br /> The overflow happens in ghes_estatus_pool_init() when calculating<br /> len during execution of the statement below as both multiplication<br /> operands here are signed int:<br /> <br /> len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);<br /> <br /> The following call trace is observed because of this bug:<br /> <br /> [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1<br /> [ 9.317131] Call Trace:<br /> [ 9.317134] <br /> [ 9.317137] dump_stack_lvl+0x49/0x5f<br /> [ 9.317145] dump_stack+0x10/0x12<br /> [ 9.317146] warn_alloc.cold+0x7b/0xdf<br /> [ 9.317150] ? __device_attach+0x16a/0x1b0<br /> [ 9.317155] __vmalloc_node_range+0x702/0x740<br /> [ 9.317160] ? device_add+0x17f/0x920<br /> [ 9.317164] ? dev_set_name+0x53/0x70<br /> [ 9.317166] ? platform_device_add+0xf9/0x240<br /> [ 9.317168] __vmalloc_node+0x49/0x50<br /> [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317176] vmalloc+0x21/0x30<br /> [ 9.317177] ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317179] acpi_hest_init+0x129/0x19c<br /> [ 9.317185] acpi_init+0x434/0x4a4<br /> [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a<br /> [ 9.317190] do_one_initcall+0x48/0x200<br /> [ 9.317195] kernel_init_freeable+0x221/0x284<br /> [ 9.317200] ? rest_init+0xe0/0xe0<br /> [ 9.317204] kernel_init+0x1a/0x130<br /> [ 9.317205] ret_from_fork+0x22/0x30<br /> [ 9.317208] <br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: fix memory leak in query_regdb_file()<br /> <br /> In the function query_regdb_file() the alpha2 parameter is duplicated<br /> using kmemdup() and subsequently freed in regdb_fw_cb(). However,<br /> request_firmware_nowait() can fail without calling regdb_fw_cb() and<br /> thus leak memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix panic on frag_list with mixed head alloc types<br /> <br /> Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when<br /> splitting gso_size mangled skb having linear-headed frag_list"), it is<br /> allowed to change gso_size of a GRO packet. However, that commit assumes<br /> that "checking the first list_skb member suffices; i.e if either of the<br /> list_skb members have non head_frag head, then the first one has too".<br /> <br /> It turns out this assumption does not hold. We&amp;#39;ve seen BUG_ON being hit<br /> in skb_segment when skbs on the frag_list had differing head_frag with<br /> the vmxnet3 driver. This happens because __netdev_alloc_skb and<br /> __napi_alloc_skb can return a skb that is page backed or kmalloced<br /> depending on the requested size. As the result, the last small skb in<br /> the GRO packet can be kmalloced.<br /> <br /> There are three different locations where this can be fixed:<br /> <br /> (1) We could check head_frag in GRO and not allow GROing skbs with<br /> different head_frag. However, that would lead to performance<br /> regression on normal forward paths with unmodified gso_size, where<br /> !head_frag in the last packet is not a problem.<br /> <br /> (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating<br /> that NETIF_F_SG is undesirable. That would need to eat a bit in<br /> sk_buff. Furthermore, that flag can be unset when all skbs on the<br /> frag_list are page backed. To retain good performance,<br /> bpf_skb_net_grow/shrink would have to walk the frag_list.<br /> <br /> (3) Walk the frag_list in skb_segment when determining whether<br /> NETIF_F_SG should be cleared. This of course slows things down.<br /> <br /> This patch implements (3). To limit the performance impact in<br /> skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set<br /> that have gso_size changed. Normal paths thus will not hit it.<br /> <br /> We could check only the last skb but since we need to walk the whole<br /> list anyway, let&amp;#39;s stay on the safe side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix the sk-&gt;sk_forward_alloc warning of sk_stream_kill_queues<br /> <br /> When running `test_sockmap` selftests, the following warning appears:<br /> <br /> WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xd28/0x1380<br /> ? tcp_v4_do_rcv+0x77/0x2c0<br /> tcp_v4_do_rcv+0x77/0x2c0<br /> __release_sock+0x106/0x130<br /> __tcp_close+0x1a7/0x4e0<br /> tcp_close+0x20/0x70<br /> inet_release+0x3c/0x80<br /> __sock_release+0x3a/0xb0<br /> sock_close+0x14/0x20<br /> __fput+0xa3/0x260<br /> task_work_run+0x59/0xb0<br /> exit_to_user_mode_prepare+0x1b3/0x1c0<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x48/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged<br /> while msg has more_data"), where I used msg-&gt;sg.size to replace the tosend,<br /> causing breakage:<br /> <br /> if (msg-&gt;apply_bytes &amp;&amp; msg-&gt;apply_bytes apply_bytes;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix BUG_ON() when directory entry has invalid rec_len<br /> <br /> The rec_len field in the directory entry has to be a multiple of 4. A<br /> corrupted filesystem image can be used to hit a BUG() in<br /> ext4_rec_len_to_disk(), called from make_indexed_dir().<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/ext4.h:2413!<br /> ...<br /> RIP: 0010:make_indexed_dir+0x53f/0x5f0<br /> ...<br /> Call Trace:<br /> <br /> ? add_dirent_to_buf+0x1b2/0x200<br /> ext4_add_entry+0x36e/0x480<br /> ext4_add_nondir+0x2b/0xc0<br /> ext4_create+0x163/0x200<br /> path_openat+0x635/0xe90<br /> do_filp_open+0xb4/0x160<br /> ? __create_object.isra.0+0x1de/0x3b0<br /> ? _raw_spin_unlock+0x12/0x30<br /> do_sys_openat2+0x91/0x150<br /> __x64_sys_open+0x6c/0xa0<br /> do_syscall_64+0x3c/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The fix simply adds a call to ext4_check_dir_entry() to validate the<br /> directory entry, returning -EFSCORRUPTED if the entry is invalid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix warning in &amp;#39;ext4_da_release_space&amp;#39;<br /> <br /> Syzkaller report issue as follows:<br /> EXT4-fs (loop0): Free/Dirty block details<br /> EXT4-fs (loop0): free_blocks=0<br /> EXT4-fs (loop0): dirty_blocks=0<br /> EXT4-fs (loop0): Block reservation details<br /> EXT4-fs (loop0): i_reserved_data_blocks=0<br /> EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524<br /> Modules linked in:<br /> CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528<br /> RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296<br /> RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00<br /> RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000<br /> RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5<br /> R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000<br /> R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740<br /> FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461<br /> mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589<br /> ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852<br /> do_writepages+0x3c3/0x680 mm/page-writeback.c:2469<br /> __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587<br /> writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870<br /> wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044<br /> wb_do_writeback fs/fs-writeback.c:2187 [inline]<br /> wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> Above issue may happens as follows:<br /> ext4_da_write_begin<br /> ext4_create_inline_data<br /> ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);<br /> ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);<br /> __ext4_ioctl<br /> ext4_ext_migrate -&gt; will lead to eh-&gt;eh_entries not zero, and set extent flag<br /> ext4_da_write_begin<br /> ext4_da_convert_inline_data_to_extent<br /> ext4_da_write_inline_data_begin<br /> ext4_da_map_blocks<br /> ext4_insert_delayed_block<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_delonly, lblk))<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_mapped, lblk))<br /> ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -&gt; will return 1<br /> allocated = true;<br /> ext4_es_insert_delayed_block(inode, lblk, allocated);<br /> ext4_writepages<br /> mpage_map_and_submit_extent(handle, &amp;mpd, &amp;give_up_on_write); -&gt; return -ENOSPC<br /> mpage_release_unused_pages(&amp;mpd, give_up_on_write); -&gt; give_up_on_write == 1<br /> ext4_es_remove_extent<br /> ext4_da_release_space(inode, reserved);<br /> if (unlikely(to_free &gt; ei-&gt;i_reserved_data_blocks))<br /> -&gt; to_free == 1 but ei-&gt;i_reserved_data_blocks == 0<br /> -&gt; then trigger warning as above<br /> <br /> To solve above issue, forbid inode do migrate which has inline data.