Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm: Fix null-pointer dereference in pgtable_cache_add<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in diNewExt<br /> <br /> [Syz report]<br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2<br /> index -878706688 is out of range for type &amp;#39;struct iagctl[128]&amp;#39;<br /> CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:217 [inline]<br /> __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348<br /> diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360<br /> diAllocExt fs/jfs/jfs_imap.c:1949 [inline]<br /> diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666<br /> diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587<br /> ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56<br /> jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225<br /> vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106<br /> do_mkdirat+0x264/0x3a0 fs/namei.c:4129<br /> __do_sys_mkdir fs/namei.c:4149 [inline]<br /> __se_sys_mkdir fs/namei.c:4147 [inline]<br /> __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7fcb7e6a0b57<br /> Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 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:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053<br /> RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57<br /> RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140<br /> RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> [Analysis]<br /> When the agstart is too large, it can cause agno overflow.<br /> <br /> [Fix]<br /> After obtaining agno, if the value is invalid, exit the subsequent process.<br /> <br /> <br /> Modified the test from agno &gt; MAXAG to agno &gt;= MAXAG based on linux-next<br /> report by kernel test robot (Dan Carpenter).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix uaf in jfs_evict_inode<br /> <br /> When the execution of diMount(ipimap) fails, the object ipimap that has been<br /> released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs<br /> when rcu_core() calls jfs_free_node().<br /> <br /> Therefore, when diMount(ipimap) fails, sbi-&gt;ipimap should not be initialized as<br /> ipimap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in dbAdjTree<br /> <br /> Currently there is a bound check missing in the dbAdjTree while<br /> accessing the dmt_stree. To add the required check added the bool is_ctl<br /> which is required to determine the size as suggest in the following<br /> commit.<br /> https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix slab-out-of-bounds Read in dtSearch<br /> <br /> Currently while searching for current page in the sorted entry table<br /> of the page there is a out of bound access. Added a bound check to fix<br /> the error.<br /> <br /> Dave:<br /> Set return code to -EIO

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()<br /> <br /> Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug<br /> occurs when txs-&gt;cnt, data from a URB provided by a USB device, is<br /> bigger than the size of the array txs-&gt;txstatus, which is<br /> HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug<br /> handling code after the check. Make the function return if that is the<br /> case.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> UBSAN: array-index-out-of-bounds in htc_drv_txrx.c<br /> index 13 is out of range for type &amp;#39;__wmi_event_txstatus [12]&amp;#39;<br /> Call Trace:<br /> ath9k_htc_txstatus<br /> ath9k_wmi_event_tasklet<br /> tasklet_action_common<br /> __do_softirq<br /> irq_exit_rxu<br /> sysvec_apic_timer_interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rt2x00: restart beacon queue when hardware reset<br /> <br /> When a hardware reset is triggered, all registers are reset, so all<br /> queues are forced to stop in hardware interface. However, mac80211<br /> will not automatically stop the queue. If we don&amp;#39;t manually stop the<br /> beacon queue, the queue will be deadlocked and unable to start again.<br /> This patch fixes the issue where Apple devices cannot connect to the<br /> AP after calling ieee80211_restart_hw().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysctl: Fix out of bounds access for empty sysctl registers<br /> <br /> When registering tables to the sysctl subsystem there is a check to see<br /> if header is a permanently empty directory (used for mounts). This check<br /> evaluates the first element of the ctl_table. This results in an out of<br /> bounds evaluation when registering empty directories.<br /> <br /> The function register_sysctl_mount_point now passes a ctl_table of size<br /> 1 instead of size 0. It now relies solely on the type to identify<br /> a permanently empty register.<br /> <br /> Make sure that the ctl_table has at least one element before testing for<br /> permanent emptiness.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: fix setting of fpc register<br /> <br /> kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control<br /> (fpc) register of a guest cpu. The new value is tested for validity by<br /> temporarily loading it into the fpc register.<br /> <br /> This may lead to corruption of the fpc register of the host process:<br /> if an interrupt happens while the value is temporarily loaded into the fpc<br /> register, and within interrupt context floating point or vector registers<br /> are used, the current fp/vx registers are saved with save_fpu_regs()<br /> assuming they belong to user space and will be loaded into fp/vx registers<br /> when returning to user space.<br /> <br /> test_fp_ctl() restores the original user space / host process fpc register<br /> value, however it will be discarded, when returning to user space.<br /> <br /> In result the host process will incorrectly continue to run with the value<br /> that was supposed to be used for a guest cpu.<br /> <br /> Fix this by simply removing the test. There is another test right before<br /> the SIE context is entered which will handles invalid values.<br /> <br /> This results in a change of behaviour: invalid values will now be accepted<br /> instead of that the ioctl fails with -EINVAL. This seems to be acceptable,<br /> given that this interface is most likely not used anymore, and this is in<br /> addition the same behaviour implemented with the memory mapped interface<br /> (replace invalid values with zero) - see sync_regs() in kvm-s390.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ptrace: handle setting of fpc register correctly<br /> <br /> If the content of the floating point control (fpc) register of a traced<br /> process is modified with the ptrace interface the new value is tested for<br /> validity by temporarily loading it into the fpc register.<br /> <br /> This may lead to corruption of the fpc register of the tracing process:<br /> if an interrupt happens while the value is temporarily loaded into the<br /> fpc register, and within interrupt context floating point or vector<br /> registers are used, the current fp/vx registers are saved with<br /> save_fpu_regs() assuming they belong to user space and will be loaded into<br /> fp/vx registers when returning to user space.<br /> <br /> test_fp_ctl() restores the original user space fpc register value, however<br /> it will be discarded, when returning to user space.<br /> <br /> In result the tracer will incorrectly continue to run with the value that<br /> was supposed to be used for the traced process.<br /> <br /> Fix this by saving fpu register contents with save_fpu_regs() before using<br /> test_fp_ctl().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rkisp1: Fix IRQ disable race issue<br /> <br /> In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the<br /> interrupts and then apparently assumes that the interrupt handler won&amp;#39;t<br /> be running, and proceeds in the stop procedure. This is not the case, as<br /> the interrupt handler can already be running, which would lead to the<br /> ISP being disabled while the interrupt handler handling a captured<br /> frame.<br /> <br /> This brings up two issues: 1) the ISP could be powered off while the<br /> interrupt handler is still running and accessing registers, leading to<br /> board lockup, and 2) the interrupt handler code and the code that<br /> disables the streaming might do things that conflict.<br /> <br /> It is not clear to me if 2) causes a real issue, but 1) can be seen with<br /> a suitable delay (or printk in my case) in the interrupt handler,<br /> leading to board lockup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: Avoid touching renamed directory if parent does not change<br /> <br /> The VFS will not be locking moved directory if its parent does not<br /> change. Change ocfs2 rename code to avoid touching renamed directory if<br /> its parent does not change as without locking that can corrupt the<br /> filesystem.