Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: zynqmp_dpsub: Always register bridge<br /> <br /> We must always register the DRM bridge, since zynqmp_dp_hpd_work_func<br /> calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be<br /> initialized. We do this before zynqmp_dpsub_drm_init since that calls<br /> drm_bridge_attach. This fixes the following lockdep warning:<br /> <br /> [ 19.217084] ------------[ cut here ]------------<br /> [ 19.227530] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550<br /> [ 19.241696] Modules linked in:<br /> [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96<br /> [ 19.252046] Hardware name: xlnx,zynqmp (DT)<br /> [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func<br /> [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 19.269104] pc : __mutex_lock+0x4bc/0x550<br /> [ 19.273364] lr : __mutex_lock+0x4bc/0x550<br /> [ 19.277592] sp : ffffffc085c5bbe0<br /> [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8<br /> [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000<br /> [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000<br /> [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000<br /> [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720<br /> [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001<br /> [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888<br /> [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000<br /> [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880<br /> [ 19.356581] Call trace:<br /> [ 19.359160] __mutex_lock+0x4bc/0x550<br /> [ 19.363032] mutex_lock_nested+0x24/0x30<br /> [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c<br /> [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54<br /> [ 19.376364] process_one_work+0x3ac/0x988<br /> [ 19.380660] worker_thread+0x398/0x694<br /> [ 19.384736] kthread+0x1bc/0x1c0<br /> [ 19.388241] ret_from_fork+0x10/0x20<br /> [ 19.392031] irq event stamp: 183<br /> [ 19.395450] hardirqs last enabled at (183): [] finish_task_switch.isra.0+0xa8/0x2d4<br /> [ 19.405140] hardirqs last disabled at (182): [] __schedule+0x714/0xd04<br /> [ 19.413612] softirqs last enabled at (114): [] srcu_invoke_callbacks+0x158/0x23c<br /> [ 19.423128] softirqs last disabled at (110): [] srcu_invoke_callbacks+0x158/0x23c<br /> [ 19.432614] ---[ end trace 0000000000000000 ]---<br /> <br /> (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: prevent pt_regs corruption for secondary idle threads<br /> <br /> Top of the kernel thread stack should be reserved for pt_regs. However<br /> this is not the case for the idle threads of the secondary boot harts.<br /> Their stacks overlap with their pt_regs, so both may get corrupted.<br /> <br /> Similar issue has been fixed for the primary hart, see c7cdd96eca28<br /> ("riscv: prevent stack corruption by reserving task_pt_regs(p) early").<br /> However that fix was not propagated to the secondary harts. The problem<br /> has been noticed in some CPU hotplug tests with V enabled. The function<br /> smp_callin stored several registers on stack, corrupting top of pt_regs<br /> structure including status field. As a result, kernel attempted to save<br /> or restore inexistent V context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()<br /> <br /> The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating<br /> about potential truncation of output when using the snprintf function.<br /> The issue was due to the size of the buffer &amp;#39;ucode_prefix&amp;#39; being too<br /> small to accommodate the maximum possible length of the string being<br /> written into it.<br /> <br /> The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin",<br /> where %s is replaced by the value of &amp;#39;chip_name&amp;#39;. The length of this<br /> string without the %s is 16 characters. The warning message indicated<br /> that &amp;#39;chip_name&amp;#39; could be up to 29 characters long, resulting in a total<br /> of 45 characters, which exceeds the buffer size of 30 characters.<br /> <br /> To resolve this issue, the size of the &amp;#39;ucode_prefix&amp;#39; buffer has been<br /> reduced from 30 to 15. This ensures that the maximum possible length of<br /> the string being written into the buffer will not exceed its size, thus<br /> preventing potential buffer overflow and truncation issues.<br /> <br /> Fixes the below with gcc W=1:<br /> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’:<br /> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=]<br /> 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);<br /> | ^~<br /> ......<br /> 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix);<br /> | ~~~~~~~~~~~~<br /> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30<br /> 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);<br /> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=]<br /> 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);<br /> | ^~<br /> ......<br /> 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix);<br /> | ~~~~~~~~~~~~<br /> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30<br /> 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);<br /> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: region: add owner module and take its refcount<br /> <br /> The current implementation of the fpga region 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 region<br /> during programming if the parent device does not have a driver.<br /> <br /> To address this problem, add a module owner pointer to the fpga_region<br /> struct and use it to take the module&amp;#39;s refcount. Modify the functions for<br /> registering a region 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 region as the<br /> owner. This ensures compatibility with existing low-level control modules<br /> and reduces the chances of registering a region without setting the owner.<br /> <br /> Also, update the documentation to keep it consistent with the new interface<br /> for registering an fpga region.

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.