Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reiserfs: 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 reiserfs rename code to avoid touching renamed directory<br /> if its parent does not change as without locking that can corrupt the<br /> filesystem.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()<br /> <br /> Since &amp;#39;ieee80211_beacon_get()&amp;#39; can return NULL, &amp;#39;wfx_set_mfp_ap()&amp;#39;<br /> should check the return value before examining skb data. So convert<br /> the latter to return an appropriate error code and propagate it to<br /> return from &amp;#39;wfx_start_ap()&amp;#39; as well. Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spmi: mediatek: Fix UAF on device remove<br /> <br /> The pmif driver data that contains the clocks is allocated along with<br /> spmi_controller.<br /> On device remove, spmi_controller will be freed first, and then devres<br /> , including the clocks, will be cleanup.<br /> This leads to UAF because putting the clocks will access the clocks in<br /> the pmif driver data, which is already freed along with spmi_controller.<br /> <br /> This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and<br /> building the kernel with KASAN.<br /> <br /> Fix the UAF issue by using unmanaged clk_bulk_get() and putting the<br /> clocks before freeing spmi_controller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()<br /> <br /> Return invalid error code -EINVAL for invalid block id.<br /> <br /> Fixes the below:<br /> <br /> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed &amp;#39;info&amp;#39; could be null (see line 1176)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add mutex lock in control vblank irq<br /> <br /> Add a mutex lock to control vblank irq to synchronize vblank<br /> enable/disable operations happening from different threads to prevent<br /> race conditions while registering/unregistering the vblank irq callback.<br /> <br /> v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a<br /> parameter of dpu_encoder_phys.<br /> -Switch from atomic refcnt to a simple int counter as mutex has<br /> now been added<br /> v3: Mistakenly did not change wording in last version. It is done now.<br /> v2: Slightly changed wording of commit message<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/571854/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/ipoib: Fix mcast list locking<br /> <br /> Releasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in<br /> `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to<br /> remove the items while in the middle of iteration. If the mcast is removed<br /> while the lock was dropped, the for loop spins forever resulting in a hard<br /> lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):<br /> <br /> Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)<br /> -----------------------------------+-----------------------------------<br /> ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)<br /> spin_lock_irq(&amp;priv-&gt;lock) | __ipoib_ib_dev_flush(priv, ...)<br /> list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv-&gt;dev)<br /> &amp;priv-&gt;multicast_list, list) |<br /> ipoib_mcast_join(dev, mcast) |<br /> spin_unlock_irq(&amp;priv-&gt;lock) |<br /> | spin_lock_irqsave(&amp;priv-&gt;lock, flags)<br /> | list_for_each_entry_safe(mcast, tmcast,<br /> | &amp;priv-&gt;multicast_list, list)<br /> | list_del(&amp;mcast-&gt;list);<br /> | list_add_tail(&amp;mcast-&gt;list, &amp;remove_list)<br /> | spin_unlock_irqrestore(&amp;priv-&gt;lock, flags)<br /> spin_lock_irq(&amp;priv-&gt;lock) |<br /> | ipoib_mcast_remove_list(&amp;remove_list)<br /> (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,<br /> `priv-&gt;multicast_list` and we keep | remove_list, list)<br /> spinning on the `remove_list` of | &gt;&gt;&gt; wait_for_completion(&amp;mcast-&gt;done)<br /> the other thread which is blocked |<br /> and the list is still valid on |<br /> it&amp;#39;s stack.)<br /> <br /> Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent<br /> eventual sleeps.<br /> Unfortunately we could not reproduce the lockup and confirm this fix but<br /> based on the code review I think this fix should address such lockups.<br /> <br /> crash&gt; bc 31<br /> PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"<br /> --<br /> [exception RIP: ipoib_mcast_join_task+0x1b1]<br /> RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002<br /> RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000<br /> work (&amp;priv-&gt;mcast_task{,.work})<br /> RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000<br /> &amp;mcast-&gt;list<br /> RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000<br /> R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00<br /> mcast<br /> R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8<br /> dev priv (&amp;priv-&gt;lock) &amp;priv-&gt;multicast_list (aka head)<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> --- ---<br /> #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]<br /> #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967<br /> <br /> crash&gt; rx ff646f199a8c7e68<br /> ff646f199a8c7e68: ff1c6a1a04dc82f8 ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000<br /> mcast_task.work.func = 0xffffffffc0944910 ,<br /> mcast_mutex.owner.counter = 0xff1c69998efec000<br /> <br /> crash&gt; b 8<br /> PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"<br /> --<br /> #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646<br /> #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]<br /> #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]<br /> #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]<br /> #7 [ff<br /> ---truncated---