Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Only use reserved BCS instances for usm migrate exec queue<br /> <br /> The GuC context scheduling queue is 2 entires deep, thus it is possible<br /> for a migration job to be stuck behind a fault if migration exec queue<br /> shares engines with user jobs. This can deadlock as the migrate exec<br /> queue is required to service page faults. Avoid deadlock by only using<br /> reserved BCS instances for usm migrate exec queue.<br /> <br /> (cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: bridge: add owner module and take its refcount<br /> <br /> The current implementation of the fpga bridge assumes that the low-level<br /> module registers a driver for the parent device and uses its owner pointer<br /> to take the module&amp;#39;s refcount. This approach is problematic since it can<br /> lead to a null pointer dereference while attempting to get the bridge if<br /> the parent device does not have a driver.<br /> <br /> To address this problem, add a module owner pointer to the fpga_bridge<br /> struct and use it to take the module&amp;#39;s refcount. Modify the function for<br /> registering a bridge to take an additional owner module parameter and<br /> rename it to avoid conflicts. Use the old function name for a helper macro<br /> that automatically sets the module that registers the bridge as the owner.<br /> This ensures compatibility with existing low-level control modules and<br /> reduces the chances of registering a bridge without setting the owner.<br /> <br /> Also, update the documentation to keep it consistent with the new interface<br /> for registering an fpga bridge.<br /> <br /> Other changes: opportunistically move put_device() from __fpga_bridge_get()<br /> to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since<br /> the bridge device is taken in these functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: manager: add owner module and take its refcount<br /> <br /> The current implementation of the fpga manager assumes that the low-level<br /> module registers a driver for the parent device and uses its owner pointer<br /> to take the module&amp;#39;s refcount. This approach is problematic since it can<br /> lead to a null pointer dereference while attempting to get the manager if<br /> the parent device does not have a driver.<br /> <br /> To address this problem, add a module owner pointer to the fpga_manager<br /> struct and use it to take the module&amp;#39;s refcount. Modify the functions for<br /> registering the manager to take an additional owner module parameter and<br /> rename them to avoid conflicts. Use the old function names for helper<br /> macros that automatically set the module that registers the manager as the<br /> owner. This ensures compatibility with existing low-level control modules<br /> and reduces the chances of registering a manager without setting the owner.<br /> <br /> Also, update the documentation to keep it consistent with the new interface<br /> for registering an fpga manager.<br /> <br /> Other changes: opportunistically move put_device() from __fpga_mgr_get() to<br /> fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the<br /> manager device is taken in these functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Add winch to winch_handlers before registering winch IRQ<br /> <br /> Registering a winch IRQ is racy, an interrupt may occur before the winch is<br /> added to the winch_handlers list.<br /> <br /> If that happens, register_winch_irq() adds to that list a winch that is<br /> scheduled to be (or has already been) freed, causing a panic later in<br /> winch_cleanup().<br /> <br /> Avoid the race by adding the winch to the winch_handlers list before<br /> registering the IRQ, and rolling back if um_request_irq() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ti: j721e-csi2rx: Fix races while restarting DMA<br /> <br /> After the frame is submitted to DMA, it may happen that the submitted<br /> list is not updated soon enough, and the DMA callback is triggered<br /> before that.<br /> <br /> This can lead to kernel crashes, so move everything in a single<br /> lock/unlock section to prevent such races.

Buffer Overflow vulnerability in ASUS router RT-AX88U with firmware versions v3.0.0.4.388_24198 allows a remote attacker to execute arbitrary code via the connection_state_machine due to improper length validation for the cookie field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: don&amp;#39;t allow unaligned truncation on released compress inode<br /> <br /> f2fs image may be corrupted after below testcase:<br /> - mkfs.f2fs -O extra_attr,compression -f /dev/vdb<br /> - mount /dev/vdb /mnt/f2fs<br /> - touch /mnt/f2fs/file<br /> - f2fs_io setflags compression /mnt/f2fs/file<br /> - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4<br /> - f2fs_io release_cblocks /mnt/f2fs/file<br /> - truncate -s 8192 /mnt/f2fs/file<br /> - umount /mnt/f2fs<br /> - fsck.f2fs /dev/vdb<br /> <br /> [ASSERT] (fsck_chk_inode_blk:1256) --&gt; ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks<br /> [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5]<br /> [FSCK] other corrupted bugs [Fail]<br /> <br /> The reason is: partial truncation assume compressed inode has reserved<br /> blocks, after partial truncation, valid block count may change w/o<br /> .i_blocks and .total_valid_block_count update, result in corruption.<br /> <br /> This patch only allow cluster size aligned truncation on released<br /> compress inode for fixing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock<br /> <br /> It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock<br /> to avoid racing with checkpoint, otherwise, filesystem metadata including<br /> blkaddr in dnode, inode fields and .total_valid_block_count may be<br /> corrupted after SPO case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: of_property: Return error for int_map allocation failure<br /> <br /> Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a<br /> NULL pointer dereference in this case.<br /> <br /> [bhelgaas: commit log]

Improper Restriction of Excessive Authentication Attempts vulnerability in Mia Technology Inc. Mia-Med Health Aplication allows Interface Manipulation.This issue affects Mia-Med Health Aplication: before 1.0.14.

Improper Limitation of a Pathname to a Restricted Directory (&amp;#39;Path Traversal&amp;#39;) vulnerability in Salon Booking System Salon booking system allows File Manipulation.This issue affects Salon booking system: from n/a through 9.9.

Improper Authentication vulnerability in Play.Ht allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Play.Ht: from n/a through 3.6.4.