Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix data-races around sysctl_tcp_slow_start_after_idle.<br /> <br /> While reading sysctl_tcp_slow_start_after_idle, it can be changed<br /> concurrently. Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix a data-race around sysctl_tcp_early_retrans.<br /> <br /> While reading sysctl_tcp_early_retrans, it can be changed concurrently.<br /> Thus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix uninit-value in mpol_rebind_policy()<br /> <br /> mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when<br /> pol-&gt;mode is MPOL_LOCAL. Check pol-&gt;mode before access<br /> pol-&gt;w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).<br /> <br /> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]<br /> BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368<br /> mpol_rebind_policy mm/mempolicy.c:352 [inline]<br /> mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368<br /> cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline]<br /> cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278<br /> cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515<br /> cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline]<br /> cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804<br /> __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520<br /> cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539<br /> cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852<br /> kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296<br /> call_write_iter include/linux/fs.h:2162 [inline]<br /> new_sync_write fs/read_write.c:503 [inline]<br /> vfs_write+0x1318/0x2030 fs/read_write.c:590<br /> ksys_write+0x28b/0x510 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0xdb/0x120 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:524 [inline]<br /> slab_alloc_node mm/slub.c:3251 [inline]<br /> slab_alloc mm/slub.c:3259 [inline]<br /> kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264<br /> mpol_new mm/mempolicy.c:293 [inline]<br /> do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853<br /> kernel_set_mempolicy mm/mempolicy.c:1504 [inline]<br /> __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline]<br /> __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507<br /> __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> KMSAN: uninit-value in mpol_rebind_task (2)<br /> https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc<br /> <br /> This patch seems to fix below bug too.<br /> KMSAN: uninit-value in mpol_rebind_mm (2)<br /> https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b<br /> <br /> The uninit-value is pol-&gt;w.cpuset_mems_allowed in mpol_rebind_policy().<br /> When syzkaller reproducer runs to the beginning of mpol_new(),<br /> <br /> mpol_new() mm/mempolicy.c<br /> do_mbind() mm/mempolicy.c<br /> kernel_mbind() mm/mempolicy.c<br /> <br /> `mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`<br /> is 0. Then<br /> <br /> mode = MPOL_LOCAL;<br /> ...<br /> policy-&gt;mode = mode;<br /> policy-&gt;flags = flags;<br /> <br /> will be executed. So in mpol_set_nodemask(),<br /> <br /> mpol_set_nodemask() mm/mempolicy.c<br /> do_mbind()<br /> kernel_mbind()<br /> <br /> pol-&gt;mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,<br /> which will be accessed in mpol_rebind_policy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix combination of jit blinding and pointers to bpf subprogs.<br /> <br /> The combination of jit blinding and pointers to bpf subprogs causes:<br /> [ 36.989548] BUG: unable to handle page fault for address: 0000000100000001<br /> [ 36.990342] #PF: supervisor instruction fetch in kernel mode<br /> [ 36.990968] #PF: error_code(0x0010) - not-present page<br /> [ 36.994859] RIP: 0010:0x100000001<br /> [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.<br /> [ 37.004091] Call Trace:<br /> [ 37.004351] <br /> [ 37.004576] ? bpf_loop+0x4d/0x70<br /> [ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b<br /> <br /> The jit blinding logic didn&amp;#39;t recognize that ld_imm64 with an address<br /> of bpf subprogram is a special instruction and proceeded to randomize it.<br /> By itself it wouldn&amp;#39;t have been an issue, but jit_subprogs() logic<br /> relies on two step process to JIT all subprogs and then JIT them<br /> again when addresses of all subprogs are known.<br /> Blinding process in the first JIT phase caused second JIT to miss<br /> adjustment of special ld_imm64.<br /> <br /> Fix this issue by ignoring special ld_imm64 instructions that don&amp;#39;t have<br /> user controlled constants and shouldn&amp;#39;t be blinded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: validate BOOT sectors_per_clusters<br /> <br /> When the NTFS BOOT sectors_per_clusters field is &gt; 0x80, it represents a<br /> shift value. Make sure that the shift value is not too large before using<br /> it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.<br /> <br /> This prevents negative shift values and shift values that are larger than<br /> the field size.<br /> <br /> Prevents this UBSAN error:<br /> <br /> UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16<br /> shift exponent -192 is negative

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zsmalloc: fix races between asynchronous zspage free and page migration<br /> <br /> The asynchronous zspage free worker tries to lock a zspage&amp;#39;s entire page<br /> list without defending against page migration. Since pages which haven&amp;#39;t<br /> yet been locked can concurrently migrate off the zspage page list while<br /> lock_zspage() churns away, lock_zspage() can suffer from a few different<br /> lethal races.<br /> <br /> It can lock a page which no longer belongs to the zspage and unsafely<br /> dereference page_private(), it can unsafely dereference a torn pointer to<br /> the next page (since there&amp;#39;s a data race), and it can observe a spurious<br /> NULL pointer to the next page and thus not lock all of the zspage&amp;#39;s pages<br /> (since a single page migration will reconstruct the entire page list, and<br /> create_page_chain() unconditionally zeroes out each list pointer in the<br /> process).<br /> <br /> Fix the races by using migrate_read_lock() in lock_zspage() to synchronize<br /> with page migration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_qca: Use del_timer_sync() before freeing<br /> <br /> While looking at a crash report on a timer list being corrupted, which<br /> usually happens when a timer is freed while still active. This is<br /> commonly triggered by code calling del_timer() instead of<br /> del_timer_sync() just before freeing.<br /> <br /> One possible culprit is the hci_qca driver, which does exactly that.<br /> <br /> Eric mentioned that wake_retrans_timer could be rearmed via the work<br /> queue, so also move the destruction of the work queue before<br /> del_timer_sync().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave)<br /> <br /> Set the starting uABI size of KVM&amp;#39;s guest FPU to &amp;#39;struct kvm_xsave&amp;#39;,<br /> i.e. to KVM&amp;#39;s historical uABI size. When saving FPU state for usersapce,<br /> KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if<br /> the host doesn&amp;#39;t support XSAVE. Setting the XSAVE header allows the VM<br /> to be migrated to a host that does support XSAVE without the new host<br /> having to handle FPU state that may or may not be compatible with XSAVE.<br /> <br /> Setting the uABI size to the host&amp;#39;s default size results in out-of-bounds<br /> writes (setting the FP+SSE bits) and data corruption (that is thankfully<br /> caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs.<br /> <br /> WARN if the default size is larger than KVM&amp;#39;s historical uABI size; all<br /> features that can push the FPU size beyond the historical size must be<br /> opt-in.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130<br /> Read of size 8 at addr ffff888011e33a00 by task qemu-build/681<br /> CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1<br /> Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x45<br /> print_report.cold+0x45/0x575<br /> kasan_report+0x9b/0xd0<br /> fpu_copy_uabi_to_guest_fpstate+0x86/0x130<br /> kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm]<br /> kvm_vcpu_ioctl+0x47f/0x7b0 [kvm]<br /> __x64_sys_ioctl+0x5de/0xc90<br /> do_syscall_64+0x31/0x50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Allocated by task 0:<br /> (stack is not available)<br /> The buggy address belongs to the object at ffff888011e33800<br /> which belongs to the cache kmalloc-512 of size 512<br /> The buggy address is located 0 bytes to the right of<br /> 512-byte region [ffff888011e33800, ffff888011e33a00)<br /> The buggy address belongs to the physical page:<br /> page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30<br /> head:0000000089cd4adb order:2 compound_mapcount:0 compound_pincount:0<br /> flags: 0x4000000000010200(slab|head|zone=1)<br /> raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80<br /> raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> Memory state around the buggy address:<br /> ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ^<br /> ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: double hook unregistration in netns path<br /> <br /> __nft_release_hooks() is called from pre_netns exit path which<br /> unregisters the hooks, then the NETDEV_UNREGISTER event is triggered<br /> which unregisters the hooks again.<br /> <br /> [ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270<br /> [...]<br /> [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27<br /> [ 565.253682] Workqueue: netns cleanup_net<br /> [ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270<br /> [...]<br /> [ 565.297120] Call Trace:<br /> [ 565.300900] <br /> [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables]<br /> [ 565.308518] raw_notifier_call_chain+0x63/0x80<br /> [ 565.312386] unregister_netdevice_many+0x54f/0xb50<br /> <br /> Unregister and destroy netdev hook from netns pre_exit via kfree_rcu<br /> so the NETDEV_UNREGISTER path see unregistered hooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2<br /> <br /> Remove WARNs that sanity check that KVM never lets a triple fault for L2<br /> escape and incorrectly end up in L1. In normal operation, the sanity<br /> check is perfectly valid, but it incorrectly assumes that it&amp;#39;s impossible<br /> for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through<br /> KVM_RUN (which guarantees kvm_check_nested_state() will see and handle<br /> the triple fault).<br /> <br /> The WARN can currently be triggered if userspace injects a machine check<br /> while L2 is active and CR4.MCE=0. And a future fix to allow save/restore<br /> of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn&amp;#39;t<br /> lost on migration, will make it trivially easy for userspace to trigger<br /> the WARN.<br /> <br /> Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is<br /> tempting, but wrong, especially if/when the request is saved/restored,<br /> e.g. if userspace restores events (including a triple fault) and then<br /> restores nested state (which may forcibly leave guest mode). Ignoring<br /> the fact that KVM doesn&amp;#39;t currently provide the necessary APIs, it&amp;#39;s<br /> userspace&amp;#39;s responsibility to manage pending events during save/restore.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Call Trace:<br /> <br /> vmx_leave_nested+0x30/0x40 [kvm_intel]<br /> vmx_set_nested_state+0xca/0x3e0 [kvm_intel]<br /> kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm]<br /> kvm_vcpu_ioctl+0x4b9/0x660 [kvm]<br /> __x64_sys_ioctl+0x83/0xb0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: check if cluster num is valid<br /> <br /> Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap.<br /> This was triggered by reproducer calling truncute with size 0,<br /> which causes the following trace:<br /> <br /> BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174<br /> Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365<br /> <br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118<br /> print_address_description+0x81/0x3c0 mm/kasan/report.c:233<br /> __kasan_report mm/kasan/report.c:419 [inline]<br /> kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436<br /> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309<br /> exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174<br /> exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181<br /> __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217<br /> exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243<br /> exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339<br /> notify_change+0xb76/0xe10 fs/attr.c:336<br /> do_truncate+0x1ea/0x2d0 fs/open.c:65<br /> <br /> Move the is_valid_cluster() helper from fatent.c to a common<br /> header to make it reusable in other *.c files. And add is_valid_cluster()<br /> to validate if cluster number is within valid range in exfat_clear_bitmap()<br /> and exfat_set_bitmap().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: re-fetch conntrack after insertion<br /> <br /> In case the conntrack is clashing, insertion can free skb-&gt;_nfct and<br /> set skb-&gt;_nfct to the already-confirmed entry.<br /> <br /> This wasn&amp;#39;t found before because the conntrack entry and the extension<br /> space used to free&amp;#39;d after an rcu grace period, plus the race needs<br /> events enabled to trigger.