Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix race condition on enabling fast-xmit<br /> <br /> fast-xmit must only be enabled after the sta has been uploaded to the driver,<br /> otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls<br /> to the driver, leading to potential crashes because of uninitialized drv_priv<br /> data.<br /> Add a missing sta-&gt;uploaded check and re-check fast xmit after inserting a sta.

Kofax Power PDF PNG File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.<br /> <br /> The specific flaw exists within the handling of PNG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22018.

Kofax Power PDF PNG File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.<br /> <br /> The specific flaw exists within the parsing of PNG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22022.

Kofax Power PDF TIF File Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.<br /> <br /> The specific flaw exists within the parsing of TIF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22033.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()<br /> <br /> The gtp_net_ops pernet operations structure for the subsystem must be<br /> registered before registering the generic netlink family.<br /> <br /> Syzkaller hit &amp;#39;general protection fault in gtp_genl_dump_pdp&amp;#39; bug:<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014<br /> RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]<br /> Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86<br /> df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <br /> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74<br /> RSP: 0018:ffff888014107220 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000<br /> FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_regs+0x90/0xa0<br /> ? die_addr+0x50/0xd0<br /> ? exc_general_protection+0x148/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]<br /> ? __alloc_skb+0x1dd/0x350<br /> ? __pfx___alloc_skb+0x10/0x10<br /> genl_dumpit+0x11d/0x230<br /> netlink_dump+0x5b9/0xce0<br /> ? lockdep_hardirqs_on_prepare+0x253/0x430<br /> ? __pfx_netlink_dump+0x10/0x10<br /> ? kasan_save_track+0x10/0x40<br /> ? __kasan_kmalloc+0x9b/0xa0<br /> ? genl_start+0x675/0x970<br /> __netlink_dump_start+0x6fc/0x9f0<br /> genl_family_rcv_msg_dumpit+0x1bb/0x2d0<br /> ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10<br /> ? genl_op_from_small+0x2a/0x440<br /> ? cap_capable+0x1d0/0x240<br /> ? __pfx_genl_start+0x10/0x10<br /> ? __pfx_genl_dumpit+0x10/0x10<br /> ? __pfx_genl_done+0x10/0x10<br /> ? security_capable+0x9d/0xe0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t suspend the array for interrupted reshape<br /> <br /> md_start_sync() will suspend the array if there are spares that can be<br /> added or removed from conf, however, if reshape is still in progress,<br /> this won&amp;#39;t happen at all or data will be corrupted(remove_and_add_spares<br /> won&amp;#39;t be called from md_choose_sync_action for reshape), hence there is<br /> no need to suspend the array if reshape is not done yet.<br /> <br /> Meanwhile, there is a potential deadlock for raid456:<br /> <br /> 1) reshape is interrupted;<br /> <br /> 2) set one of the disk WantReplacement, and add a new disk to the array,<br /> however, recovery won&amp;#39;t start until the reshape is finished;<br /> <br /> 3) then issue an IO across reshpae position, this IO will wait for<br /> reshape to make progress;<br /> <br /> 4) continue to reshape, then md_start_sync() found there is a spare disk<br /> that can be added to conf, mddev_suspend() is called;<br /> <br /> Step 4 and step 3 is waiting for each other, deadlock triggered. Noted<br /> this problem is found by code review, and it&amp;#39;s not reporduced yet.<br /> <br /> Fix this porblem by don&amp;#39;t suspend the array for interrupted reshape,<br /> this is safe because conf won&amp;#39;t be changed until reshape is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t register sync_thread for reshape directly<br /> <br /> Currently, if reshape is interrupted, then reassemble the array will<br /> register sync_thread directly from pers-&gt;run(), in this case<br /> &amp;#39;MD_RECOVERY_RUNNING&amp;#39; is set directly, however, there is no guarantee<br /> that md_do_sync() will be executed, hence stop_sync_thread() will hang<br /> because &amp;#39;MD_RECOVERY_RUNNING&amp;#39; can&amp;#39;t be cleared.<br /> <br /> Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,<br /> however, following hang can still be triggered by dm-raid test<br /> shell/lvconvert-raid-reshape.sh occasionally:<br /> <br /> [root@fedora ~]# cat /proc/1982/stack<br /> [] stop_sync_thread+0x1ab/0x270 [md_mod]<br /> [] md_frozen_sync_thread+0x5c/0xa0 [md_mod]<br /> [] raid_presuspend+0x1e/0x70 [dm_raid]<br /> [] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]<br /> [] __dm_destroy+0x2a5/0x310 [dm_mod]<br /> [] dm_destroy+0x16/0x30 [dm_mod]<br /> [] dev_remove+0x165/0x290 [dm_mod]<br /> [] ctl_ioctl+0x4bb/0x7b0 [dm_mod]<br /> [] dm_ctl_ioctl+0x11/0x20 [dm_mod]<br /> [] vfs_ioctl+0x21/0x60<br /> [] __x64_sys_ioctl+0xb9/0xe0<br /> [] do_syscall_64+0xc6/0x230<br /> [] entry_SYSCALL_64_after_hwframe+0x6c/0x74<br /> <br /> Meanwhile mddev-&gt;recovery is:<br /> MD_RECOVERY_RUNNING |<br /> MD_RECOVERY_INTR |<br /> MD_RECOVERY_RESHAPE |<br /> MD_RECOVERY_FROZEN<br /> <br /> Fix this problem by remove the code to register sync_thread directly<br /> from raid10 and raid5. And let md_check_recovery() to register<br /> sync_thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t ignore read-only array in md_check_recovery()<br /> <br /> Usually if the array is not read-write, md_check_recovery() won&amp;#39;t<br /> register new sync_thread in the first place. And if the array is<br /> read-write and sync_thread is registered, md_set_readonly() will<br /> unregister sync_thread before setting the array read-only. md/raid<br /> follow this behavior hence there is no problem.<br /> <br /> After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following<br /> hang can be triggered by test shell/integrity-caching.sh:<br /> <br /> 1) array is read-only. dm-raid update super block:<br /> rs_update_sbs<br /> ro = mddev-&gt;ro<br /> mddev-&gt;ro = 0<br /> -&gt; set array read-write<br /> md_update_sb<br /> <br /> 2) register new sync thread concurrently.<br /> <br /> 3) dm-raid set array back to read-only:<br /> rs_update_sbs<br /> mddev-&gt;ro = ro<br /> <br /> 4) stop the array:<br /> raid_dtr<br /> md_stop<br /> stop_sync_thread<br /> set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread_directly(mddev-&gt;sync_thread);<br /> wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))<br /> <br /> 5) sync thread done:<br /> md_do_sync<br /> set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread(mddev-&gt;thread);<br /> <br /> 6) daemon thread can&amp;#39;t unregister sync thread:<br /> md_check_recovery<br /> if (!md_is_rdwr(mddev) &amp;&amp;<br /> !test_bit(MD_RECOVERY_NEEDED, &amp;mddev-&gt;recovery))<br /> return;<br /> -&gt; -&gt; MD_RECOVERY_RUNNING can&amp;#39;t be cleared, hence step 4 hang;<br /> <br /> The root cause is that dm-raid manipulate &amp;#39;mddev-&gt;ro&amp;#39; by itself,<br /> however, dm-raid really should stop sync thread before setting the<br /> array read-only. Unfortunately, I need to read more code before I<br /> can refacter the handler of &amp;#39;mddev-&gt;ro&amp;#39; in dm-raid, hence let&amp;#39;s fix<br /> the problem the easy way for now to prevent dm-raid regression.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t ignore suspended array in md_check_recovery()<br /> <br /> mddev_suspend() never stop sync_thread, hence it doesn&amp;#39;t make sense to<br /> ignore suspended array in md_check_recovery(), which might cause<br /> sync_thread can&amp;#39;t be unregistered.<br /> <br /> After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following<br /> hang can be triggered by test shell/integrity-caching.sh:<br /> <br /> 1) suspend the array:<br /> raid_postsuspend<br /> mddev_suspend<br /> <br /> 2) stop the array:<br /> raid_dtr<br /> md_stop<br /> __md_stop_writes<br /> stop_sync_thread<br /> set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread_directly(mddev-&gt;sync_thread);<br /> wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))<br /> <br /> 3) sync thread done:<br /> md_do_sync<br /> set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread(mddev-&gt;thread);<br /> <br /> 4) daemon thread can&amp;#39;t unregister sync thread:<br /> md_check_recovery<br /> if (mddev-&gt;suspended)<br /> return; -&gt; return directly<br /> md_read_sync_thread<br /> clear_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery);<br /> -&gt; MD_RECOVERY_RUNNING can&amp;#39;t be cleared, hence step 2 hang;<br /> <br /> This problem is not just related to dm-raid, fix it by ignoring<br /> suspended array in md_check_recovery(). And follow up patches will<br /> improve dm-raid better to frozen sync thread during suspend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swap: fix race when skipping swapcache<br /> <br /> When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads<br /> swapin the same entry at the same time, they get different pages (A, B). <br /> Before one thread (T0) finishes the swapin and installs page (A) to the<br /> PTE, another thread (T1) could finish swapin of page (B), swap_free the<br /> entry, then swap out the possibly modified page reusing the same entry. <br /> It breaks the pte_same check in (T0) because PTE value is unchanged,<br /> causing ABA problem. Thread (T0) will install a stalled page (A) into the<br /> PTE and cause data corruption.<br /> <br /> One possible callstack is like this:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> do_swap_page() do_swap_page() with same entry<br /> <br /> <br /> swap_read_folio()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: pscsi: Fix bio_put() for error case<br /> <br /> As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc<br /> wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit()<br /> and kfree(). That is not done properly for the error case, hitting WARN and<br /> NULL pointer dereference in bio_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window<br /> <br /> The Linux CXL subsystem is built on the assumption that HPA == SPA.<br /> That is, the host physical address (HPA) the HDM decoder registers are<br /> programmed with are system physical addresses (SPA).<br /> <br /> During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1,<br /> 8.1.3.8) are checked if the memory is enabled and the CXL range is in<br /> a HPA window that is described in a CFMWS structure of the CXL host<br /> bridge (cxl-3.1, 9.18.1.3).<br /> <br /> Now, if the HPA is not an SPA, the CXL range does not match a CFMWS<br /> window and the CXL memory range will be disabled then. The HDM decoder<br /> stops working which causes system memory being disabled and further a<br /> system hang during HDM decoder initialization, typically when a CXL<br /> enabled kernel boots.<br /> <br /> Prevent a system hang and do not disable the HDM decoder if the<br /> decoder&amp;#39;s CXL range is not found in a CFMWS window.<br /> <br /> Note the change only fixes a hardware hang, but does not implement<br /> HPA/SPA translation. Support for this can be added in a follow on<br /> patch series.