Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9381/1: kasan: clear stale stack poison<br /> <br /> We found below OOB crash:<br /> <br /> [ 33.452494] ==================================================================<br /> [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec<br /> [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0<br /> [ 33.455515]<br /> [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1<br /> [ 33.456880] Hardware name: Generic DT based system<br /> [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c<br /> [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c<br /> [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4<br /> [ 33.459863] print_report from kasan_report+0x9c/0x148<br /> [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0<br /> [ 33.461424] kasan_check_range from memset+0x20/0x3c<br /> [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec<br /> [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c<br /> [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354<br /> [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24<br /> [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4<br /> [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18<br /> [ 33.467397]<br /> [ 33.467644] The buggy address belongs to stack of task swapper/0/0<br /> [ 33.468493] and is located at offset 112 in frame:<br /> [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec<br /> [ 33.469917]<br /> [ 33.470165] This frame has 2 objects:<br /> [ 33.470696] [32, 76) &amp;#39;global_zone_diff&amp;#39;<br /> [ 33.470729] [112, 276) &amp;#39;global_node_diff&amp;#39;<br /> [ 33.471294]<br /> [ 33.472095] The buggy address belongs to the physical page:<br /> [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03<br /> [ 33.473944] flags: 0x1000(reserved|zone=0)<br /> [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001<br /> [ 33.475656] raw: 00000000<br /> [ 33.476050] page dumped because: kasan: bad access detected<br /> [ 33.476816]<br /> [ 33.477061] Memory state around the buggy address:<br /> [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00<br /> [ 33.479526] &gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1<br /> [ 33.480415] ^<br /> [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3<br /> [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 33.482978] ==================================================================<br /> <br /> We find the root cause of this OOB is that arm does not clear stale stack<br /> poison in the case of cpuidle.<br /> <br /> This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.<br /> <br /> From cited commit [1] that explain the problem<br /> <br /> Functions which the compiler has instrumented for KASAN place poison on<br /> the stack shadow upon entry and remove this poison prior to returning.<br /> <br /> In the case of cpuidle, CPUs exit the kernel a number of levels deep in<br /> C code. Any instrumented functions on this critical path will leave<br /> portions of the stack shadow poisoned.<br /> <br /> If CPUs lose context and return to the kernel via a cold path, we<br /> restore a prior context saved in __cpu_suspend_enter are forgotten, and<br /> we never remove the poison they placed in the stack shadow area by<br /> functions calls between this and the actual exit of the kernel.<br /> <br /> Thus, (depending on stackframe layout) subsequent calls to instrumented<br /> functions may hit this stale poison, resulting in (spurious) KASAN<br /> splats to the console.<br /> <br /> To avoid this, clear any stale poison from the idle thread for a CPU<br /> prior to bringing a CPU online.<br /> <br /> From cited commit [2]<br /> <br /> Extend to check for CONFIG_KASAN_STACK<br /> <br /> [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")<br /> [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Don&amp;#39;t free ring buffers that couldn&amp;#39;t be re-encrypted<br /> <br /> In CoCo VMs it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> The VMBus ring buffer code could free decrypted/shared pages if<br /> set_memory_decrypted() fails. Check the decrypted field in the struct<br /> vmbus_gpadl for the ring buffers to decide whether to free the memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio_hv_generic: Don&amp;#39;t free decrypted memory<br /> <br /> In CoCo VMs it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> The VMBus device UIO driver could free decrypted/shared pages if<br /> set_memory_decrypted() fails. Check the decrypted field in the gpadl<br /> to decide whether to free the memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hv_netvsc: Don&amp;#39;t free decrypted memory<br /> <br /> In CoCo VMs it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> The netvsc driver could free decrypted/shared pages if<br /> set_memory_decrypted() fails. Check the decrypted field in the gpadl<br /> to decide whether to free the memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iocost: do not WARN if iocg was already offlined<br /> <br /> In iocg_pay_debt(), warn is triggered if &amp;#39;active_list&amp;#39; is empty, which<br /> is intended to confirm iocg is active when it has debt. However, warn<br /> can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()<br /> is run at that time:<br /> <br /> WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190<br /> Call trace:<br /> iocg_pay_debt+0x14c/0x190<br /> iocg_kick_waitq+0x438/0x4c0<br /> iocg_waitq_timer_fn+0xd8/0x130<br /> __run_hrtimer+0x144/0x45c<br /> __hrtimer_run_queues+0x16c/0x244<br /> hrtimer_interrupt+0x2cc/0x7b0<br /> <br /> The warn in this situation is meaningless. Since this iocg is being<br /> removed, the state of the &amp;#39;active_list&amp;#39; is irrelevant, and &amp;#39;waitq_timer&amp;#39;<br /> is canceled after removing &amp;#39;active_list&amp;#39; in ioc_pd_free(), which ensures<br /> iocg is freed after iocg_waitq_timer_fn() returns.<br /> <br /> Therefore, add the check if iocg was already offlined to avoid warn<br /> when removing a blkcg or disk.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Skip on writeback when it&amp;#39;s not applicable<br /> <br /> [WHY]<br /> dynamic memory safety error detector (KASAN) catches and generates error<br /> messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not<br /> support certain features which are not initialized.<br /> <br /> [HOW]<br /> Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies<br /> <br /> syzbot reported unsafe calls to copy_from_sockptr() [1]<br /> <br /> Use copy_safe_from_sockptr() instead.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255<br /> Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078<br /> <br /> CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255<br /> do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311<br /> __sys_setsockopt+0x1ae/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340<br /> do_syscall_64+0xfd/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> RIP: 0033:0x7f7fac07fd89<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89<br /> RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004<br /> RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000<br /> R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails<br /> <br /> In CoCo VMs it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> VMBus code could free decrypted pages if set_memory_encrypted()/decrypted()<br /> fails. Leak the pages if this happens.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl<br /> <br /> In CoCo VMs it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> In order to make sure callers of vmbus_establish_gpadl() and<br /> vmbus_teardown_gpadl() don&amp;#39;t return decrypted/shared pages to<br /> allocators, add a field in struct vmbus_gpadl to keep track of the<br /> decryption status of the buffers. This will allow the callers to<br /> know if they should free or leak the pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iocost: avoid out of bounds shift<br /> <br /> UBSAN catches undefined behavior in blk-iocost, where sometimes<br /> iocg-&gt;delay is shifted right by a number that is too large,<br /> resulting in undefined behavior on some architectures.<br /> <br /> [ 186.556576] ------------[ cut here ]------------<br /> UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23<br /> shift exponent 64 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka &amp;#39;unsigned long long&amp;#39;)<br /> CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1<br /> Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8f/0xe0<br /> __ubsan_handle_shift_out_of_bounds+0x22c/0x280<br /> iocg_kick_delay+0x30b/0x310<br /> ioc_timer_fn+0x2fb/0x1f80<br /> __run_timer_base+0x1b6/0x250<br /> ...<br /> <br /> Avoid that undefined behavior by simply taking the<br /> "delay = 0" branch if the shift is too large.<br /> <br /> I am not sure what the symptoms of an undefined value<br /> delay will be, but I suspect it could be more than a<br /> little annoying to debug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets<br /> <br /> TCP_SYN_RECV state is really special, it is only used by<br /> cross-syn connections, mostly used by fuzzers.<br /> <br /> In the following crash [1], syzbot managed to trigger a divide<br /> by zero in tcp_rcv_space_adjust()<br /> <br /> A socket makes the following state transitions,<br /> without ever calling tcp_init_transfer(),<br /> meaning tcp_init_buffer_space() is also not called.<br /> <br /> TCP_CLOSE<br /> connect()<br /> TCP_SYN_SENT<br /> TCP_SYN_RECV<br /> shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)<br /> TCP_FIN_WAIT1<br /> <br /> To fix this issue, change tcp_shutdown() to not<br /> perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,<br /> which makes no sense anyway.<br /> <br /> When tcp_rcv_state_process() later changes socket state<br /> from TCP_SYN_RECV to TCP_ESTABLISH, then look at<br /> sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,<br /> and send a FIN packet from a sane socket state.<br /> <br /> This means tcp_send_fin() can now be called from BH<br /> context, and must use GFP_ATOMIC allocations.<br /> <br /> [1]<br /> divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767<br /> Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48<br /> RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246<br /> RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7<br /> R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30<br /> R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da<br /> FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513<br /> tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578<br /> inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x109/0x280 net/socket.c:1068<br /> ____sys_recvmsg+0x1db/0x470 net/socket.c:2803<br /> ___sys_recvmsg net/socket.c:2845 [inline]<br /> do_recvmmsg+0x474/0xae0 net/socket.c:2939<br /> __sys_recvmmsg net/socket.c:3018 [inline]<br /> __do_sys_recvmmsg net/socket.c:3041 [inline]<br /> __se_sys_recvmmsg net/socket.c:3034 [inline]<br /> __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7faeb6363db9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9<br /> RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c<br /> R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001