Vulnerabilities

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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits<br /> <br /> Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D<br /> bits instead of mapping the PTE into kernel address space. The VM_PFNMAP<br /> path is broken as it assumes that vm_pgoff is the base pfn of the mapped<br /> VMA range, which is conceptually wrong as vm_pgoff is the offset relative<br /> to the file and has nothing to do with the pfn. The horrific hack worked<br /> for the original use case (backing guest memory with /dev/mem), but leads<br /> to accessing "random" pfns for pretty much any other VM_PFNMAP case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential double free during failed mount<br /> <br /> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()<br /> <br /> In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard<br /> lockup call trace hangs the system.<br /> <br /> Call Trace:<br /> _raw_spin_lock_irqsave+0x32/0x40<br /> lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]<br /> lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]<br /> lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]<br /> lpfc_els_flush_cmd+0x43c/0x670 [lpfc]<br /> lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]<br /> lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]<br /> lpfc_do_work+0x1485/0x1d70 [lpfc]<br /> kthread+0x112/0x130<br /> ret_from_fork+0x1f/0x40<br /> Kernel panic - not syncing: Hard LOCKUP<br /> <br /> The same CPU tries to claim the phba-&gt;port_list_lock twice.<br /> <br /> Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and<br /> lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need<br /> to take the phba-&gt;port_list_lock within lpfc_dmp_dbg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: fix the warning of dev_wake in mhi_pm_disable_transition()<br /> <br /> When test device recovery with below command, it has warning in message<br /> as below.<br /> echo assert &gt; /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crash<br /> echo assert &gt; /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crash<br /> <br /> warning message:<br /> [ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash<br /> [ 1968.471364] ieee80211 phy0: Hardware restart was requested<br /> [ 1968.511305] ------------[ cut here ]------------<br /> [ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi]<br /> [ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core<br /> [ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579<br /> [ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> [ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi]<br /> [ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi]<br /> [ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89<br /> [ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286<br /> [ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922<br /> [ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24<br /> [ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27<br /> [ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac<br /> [ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24<br /> [ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000<br /> [ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0<br /> [ 1968.512587] Call Trace:<br /> [ 1968.512672] <br /> [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40<br /> [ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi]<br /> [ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi]<br /> [ 1968.513063] process_one_work+0x86a/0x1400<br /> [ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230<br /> [ 1968.513312] ? move_linked_works+0x125/0x290<br /> [ 1968.513416] worker_thread+0x6db/0xf60<br /> [ 1968.513536] ? process_one_work+0x1400/0x1400<br /> [ 1968.513627] kthread+0x241/0x2d0<br /> [ 1968.513733] ? kthread_complete_and_exit+0x20/0x20<br /> [ 1968.513821] ret_from_fork+0x22/0x30<br /> [ 1968.513924] <br /> <br /> Reason is mhi_deassert_dev_wake() from mhi_device_put() is called<br /> but mhi_assert_dev_wake() from __mhi_device_get_sync() is not called<br /> in progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:<br /> Skip device wake in error or shutdown state") add check for the<br /> pm_state of mhi in __mhi_device_get_sync(), and the pm_state is not<br /> the normal state untill recovery is completed, so it leads the<br /> dev_wake is not 0 and above warning print in mhi_pm_disable_transition()<br /> while checking mhi_cntrl-&gt;dev_wake.<br /> <br /> Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip call<br /> mhi_device_put() if mhi_device_get_sync() does not really do wake,<br /> then the warning gone.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipw2x00: Fix potential NULL dereference in libipw_xmit()<br /> <br /> crypt and crypt-&gt;ops could be null, so we need to checking null<br /> before dereference

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: fix memory leak of elf header buffer<br /> <br /> This is reported by kmemleak detector:<br /> <br /> unreferenced object 0xffffc900002a9000 (size 4096):<br /> comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s)<br /> hex dump (first 32 bytes):<br /> 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............<br /> 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..&gt;.............<br /> backtrace:<br /> [] __vmalloc_node_range+0x101/0x170<br /> [] __vmalloc_node+0xb4/0x160<br /> [] crash_prepare_elf64_headers+0x8e/0xcd0<br /> [] crash_load_segments+0x260/0x470<br /> [] bzImage64_load+0x814/0xad0<br /> [] arch_kexec_kernel_image_load+0x1be/0x2a0<br /> [] kimage_file_alloc_init+0x2ec/0x5a0<br /> [] __do_sys_kexec_file_load+0x28d/0x530<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to<br /> store elf headers. While it&amp;#39;s not freed back to system correctly when<br /> kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it<br /> by introducing x86 specific function arch_kimage_file_post_load_cleanup(),<br /> and freeing the buffer there.<br /> <br /> And also remove the incorrect elf header buffer freeing code. Before<br /> calling arch specific kexec_file loading function, the image instance has<br /> been initialized. So &amp;#39;image-&gt;elf_headers&amp;#39; must be NULL. It doesn&amp;#39;t make<br /> sense to free the elf header buffer in the place.<br /> <br /> Three different people have reported three bugs about the memory leak on<br /> x86_64 inside Redhat.