Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()<br /> <br /> Places the logic for checking if the group&amp;#39;s block bitmap is corrupt under<br /> the protection of the group lock to avoid allocating blocks from the group<br /> with a corrupted block bitmap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()<br /> <br /> Determine if the group block bitmap is corrupted before using ac_b_ex in<br /> ext4_mb_try_best_found() to avoid allocating blocks from a group with a<br /> corrupted block bitmap in the following concurrency and making the<br /> situation worse.<br /> <br /> ext4_mb_regular_allocator<br /> ext4_lock_group(sb, group)<br /> ext4_mb_good_group<br /> // check if the group bbitmap is corrupted<br /> ext4_mb_complex_scan_group<br /> // Scan group gets ac_b_ex but doesn&amp;#39;t use it<br /> ext4_unlock_group(sb, group)<br /> ext4_mark_group_bitmap_corrupted(group)<br /> // The block bitmap was corrupted during<br /> // the group unlock gap.<br /> ext4_mb_try_best_found<br /> ext4_lock_group(ac-&gt;ac_sb, group)<br /> ext4_mb_use_best_found<br /> mb_mark_used<br /> // Allocating blocks in block bitmap corrupted group

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt<br /> <br /> Determine if bb_fragments is 0 instead of determining bb_free to eliminate<br /> the risk of dividing by zero when the block bitmap is corrupted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: avoid potential deadlock at set_capacity<br /> <br /> Move set_capacity() outside of the section procected by (&amp;d-&gt;lock).<br /> To avoid possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> [1] lock(&amp;bdev-&gt;bd_size_lock);<br /> local_irq_disable();<br /> [2] lock(&amp;d-&gt;lock);<br /> [3] lock(&amp;bdev-&gt;bd_size_lock);<br /> <br /> [4] lock(&amp;d-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> Where [1](&amp;bdev-&gt;bd_size_lock) hold by zram_add()-&gt;set_capacity().<br /> [2]lock(&amp;d-&gt;lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()<br /> is trying to acquire [3](&amp;bdev-&gt;bd_size_lock) at set_capacity() call.<br /> In this situation an attempt to acquire [4]lock(&amp;d-&gt;lock) from<br /> aoecmd_cfg_rsp() will lead to deadlock.<br /> <br /> So the simplest solution is breaking lock dependency<br /> [2](&amp;d-&gt;lock) -&gt; [3](&amp;bdev-&gt;bd_size_lock) by moving set_capacity()<br /> outside.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected<br /> <br /> Return IRQ_NONE from the interrupt handler when no interrupt was<br /> detected. Because an empty interrupt will cause a null pointer error:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000008<br /> Call trace:<br /> complete+0x54/0x100<br /> hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]<br /> __handle_irq_event_percpu+0x64/0x1e0<br /> handle_irq_event+0x7c/0x1cc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: sis: Error out if pixclock equals zero<br /> <br /> The userspace program could pass any values to the driver through<br /> ioctl() interface. If the driver doesn&amp;#39;t check the value of pixclock,<br /> it may cause divide-by-zero error.<br /> <br /> In sisfb_check_var(), var-&gt;pixclock is used as a divisor to caculate<br /> drate before it is checked against zero. Fix this by checking it<br /> at the beginning.<br /> <br /> This is similar to CVE-2022-3061 in i740fb which was fixed by<br /> commit 15cf0b8.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: savage: Error out if pixclock equals zero<br /> <br /> The userspace program could pass any values to the driver through<br /> ioctl() interface. If the driver doesn&amp;#39;t check the value of pixclock,<br /> it may cause divide-by-zero error.<br /> <br /> Although pixclock is checked in savagefb_decode_var(), but it is not<br /> checked properly in savagefb_probe(). Fix this by checking whether<br /> pixclock is zero in the function savagefb_check_var() before<br /> info-&gt;var.pixclock is used as the divisor.<br /> <br /> This is similar to CVE-2022-3061 in i740fb which was fixed by<br /> commit 15cf0b8.

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