Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix access violation during port device removal<br /> <br /> Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():<br /> usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to<br /> is concurrently removed, but the function does not check for this<br /> possibility before dereferencing the returned value.<br /> <br /> It turns out that the first dereference is unnecessary, since hub-&gt;intfdev<br /> is the parent of the port device, so it can be changed easily. Adding a<br /> check for hub == NULL prevents further problems.<br /> <br /> The same bug exists in the disable_show() routine, and it can be fixed the<br /> same way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Atom Integrated System Info v2_2 for DCN35<br /> <br /> New request from KMD/VBIOS in order to support new UMA carveout<br /> model. This fixes a null dereference from accessing<br /> Ctx-&gt;dc_bios-&gt;integrated_info while it was NULL.<br /> <br /> DAL parses through the BIOS and extracts the necessary<br /> integrated_info but was missing a case for the new BIOS<br /> version 2.3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: fix uninitialised kfifo<br /> <br /> If a line is requested with debounce, and that results in debouncing<br /> in software, and the line is subsequently reconfigured to enable edge<br /> detection then the allocation of the kfifo to contain edge events is<br /> overlooked. This results in events being written to and read from an<br /> uninitialised kfifo. Read events are returned to userspace.<br /> <br /> Initialise the kfifo in the case where the software debounce is<br /> already active.