Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_usb: leaf: Fix potential infinite loop in command parsers<br /> <br /> The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`<br /> functions contain logic to zero-length commands. These commands are used<br /> to align data to the USB endpoint&amp;#39;s wMaxPacketSize boundary.<br /> <br /> The driver attempts to skip these placeholders by aligning the buffer<br /> position `pos` to the next packet boundary using `round_up()` function.<br /> <br /> However, if zero-length command is found exactly on a packet boundary<br /> (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`<br /> function will return the unchanged value of `pos`. This prevents `pos`<br /> to be increased, causing an infinite loop in the parsing logic.<br /> <br /> This patch fixes this in the function by using `pos + 1` instead.<br /> This ensures that even if `pos` is on a boundary, the calculation is<br /> based on `pos + 1`, forcing `round_up()` to always return the next<br /> aligned boundary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/AER: Fix NULL pointer access by aer_info<br /> <br /> The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-&gt;xxx<br /> will result in kernel panic. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump<br /> <br /> Do not block PCI config accesses through pci_cfg_access_lock() when<br /> executing the s390 variant of PCI error recovery: Acquire just<br /> device_lock() instead of pci_dev_lock() as powerpc&amp;#39;s EEH and<br /> generig PCI AER processing do.<br /> <br /> During error recovery testing a pair of tasks was reported to be hung:<br /> <br /> mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working<br /> INFO: task kmcheck:72 blocked for more than 122 seconds.<br /> Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000<br /> Call Trace:<br /> [] __schedule+0x2a0/0x590<br /> [] schedule+0x36/0xe0<br /> [] schedule_preempt_disabled+0x22/0x30<br /> [] __mutex_lock.constprop.0+0x484/0x8a8<br /> [] mlx5_unload_one+0x34/0x58 [mlx5_core]<br /> [] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]<br /> [] zpci_event_attempt_error_recovery+0xf2/0x398<br /> [] __zpci_event_error+0x23a/0x2c0<br /> INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.<br /> Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000<br /> Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]<br /> Call Trace:<br /> [] __schedule+0x2a0/0x590<br /> [] schedule+0x36/0xe0<br /> [] pci_wait_cfg+0x80/0xe8<br /> [] pci_cfg_access_lock+0x74/0x88<br /> [] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]<br /> [] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]<br /> [] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]<br /> [] devlink_health_do_dump.part.0+0x82/0x168<br /> [] devlink_health_report+0x19a/0x230<br /> [] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]<br /> <br /> No kernel log of the exact same error with an upstream kernel is<br /> available - but the very same deadlock situation can be constructed there,<br /> too:<br /> <br /> - task: kmcheck<br /> mlx5_unload_one() tries to acquire devlink lock while the PCI error<br /> recovery code has set pdev-&gt;block_cfg_access by way of<br /> pci_cfg_access_lock()<br /> - task: kworker<br /> mlx5_crdump_collect() tries to set block_cfg_access through<br /> pci_cfg_access_lock() while devlink_health_report() had acquired<br /> the devlink lock.<br /> <br /> A similar deadlock situation can be reproduced by requesting a<br /> crdump with<br /> &gt; devlink health dump show pci/ reporter fw_fatal<br /> <br /> while PCI error recovery is executed on the same physical function<br /> by mlx5_core&amp;#39;s pci_error_handlers. On s390 this can be injected with<br /> &gt; zpcictl --reset-fw <br /> <br /> Tests with this patch failed to reproduce that second deadlock situation,<br /> the devlink command is rejected with "kernel answers: Permission denied" -<br /> and we get a kernel log message of:<br /> <br /> mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5<br /> <br /> because the config read of VSC_SEMAPHORE is rejected by the underlying<br /> hardware.<br /> <br /> Two prior attempts to address this issue have been discussed and<br /> ultimately rejected [see link], with the primary argument that s390&amp;#39;s<br /> implementation of PCI error recovery is imposing restrictions that<br /> neither powerpc&amp;#39;s EEH nor PCI AER handling need. Tests show that PCI<br /> error recovery on s390 is running to completion even without blocking<br /> access to PCI config space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: ip22zilog: Use platform device for probing<br /> <br /> After commit 84a9582fd203 ("serial: core: Start managing serial controllers<br /> to enable runtime PM") serial drivers need to provide a device in<br /> struct uart_port.dev otherwise an oops happens. To fix this issue<br /> for ip22zilog driver switch driver to a platform driver and setup<br /> the serial device in sgi-ip22 code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: Prevents free active kevent<br /> <br /> The root cause of this issue are:<br /> 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);<br /> put the kevent work in global workqueue. However, the kevent has not yet<br /> been scheduled when the usbnet device is unregistered. Therefore, executing<br /> free_netdev() results in the "free active object (kevent)" error reported<br /> here.<br /> <br /> 2. Another factor is that when calling usbnet_disconnect()-&gt;unregister_netdev(),<br /> if the usbnet device is up, ndo_stop() is executed to cancel the kevent.<br /> However, because the device is not up, ndo_stop() is not executed.<br /> <br /> The solution to this problem is to cancel the kevent before executing<br /> free_netdev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Add RDSEED fix for Zen5<br /> <br /> There&amp;#39;s an issue with RDSEED&amp;#39;s 16-bit and 32-bit register output<br /> variants on Zen5 which return a random value of 0 "at a rate inconsistent<br /> with randomness while incorrectly signaling success (CF=1)". Search the<br /> web for AMD-SB-7055 for more detail.<br /> <br /> Add a fix glue which checks microcode revisions.<br /> <br /> [ bp: Add microcode revisions checking, rewrite. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: make sure last_fence is always updated<br /> <br /> Update last_fence in the vm-bind path instead of kernel managed path.<br /> <br /> last_fence is used to wait for work to finish in vm_bind contexts but not<br /> used for kernel managed contexts.<br /> <br /> This fixes a bug where last_fence is not waited on context close leading<br /> to faults as resources are freed while in use.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/680080/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix delayed allocation of a cell&amp;#39;s anonymous key<br /> <br /> The allocation of a cell&amp;#39;s anonymous key is done in a background thread<br /> along with other cell setup such as doing a DNS upcall. In the reported<br /> bug, this is triggered by afs_parse_source() parsing the device name given<br /> to mount() and calling afs_lookup_cell() with the name of the cell.<br /> <br /> The normal key lookup then tries to use the key description on the<br /> anonymous authentication key as the reference for request_key() - but it<br /> may not yet be set and so an oops can happen.<br /> <br /> This has been made more likely to happen by the fix for dynamic lookup<br /> failure.<br /> <br /> Fix this by firstly allocating a reference name and attaching it to the<br /> afs_cell record when the record is created. It can share the memory<br /> allocation with the cell name (unfortunately it can&amp;#39;t just overlap the cell<br /> name by prepending it with "afs@" as the cell name already has a &amp;#39;.&amp;#39;<br /> prepended for other purposes). This reference name is then passed to<br /> request_key().<br /> <br /> Secondly, the anon key is now allocated on demand at the point a key is<br /> requested in afs_request_key() if it is not already allocated. A mutex is<br /> used to prevent multiple allocation for a cell.<br /> <br /> Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn&amp;#39;t<br /> yet allocated (if we need it) and then the caller can return -ECHILD to<br /> drop out of RCU-mode and afs_request_key() can be called.<br /> <br /> Note that the anonymous key is kind of necessary to make the key lookup<br /> cache work as that doesn&amp;#39;t currently cache a negative lookup, but it&amp;#39;s<br /> probably worth some investigation to see if NULL can be used instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/namespace: fix reference leak in grab_requested_mnt_ns<br /> <br /> lookup_mnt_ns() already takes a reference on mnt_ns.<br /> grab_requested_mnt_ns() doesn&amp;#39;t need to take an extra reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atlantic: fix fragment overflow handling in RX path<br /> <br /> The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)<br /> fragments when handling large multi-descriptor packets. This causes an<br /> out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.<br /> <br /> The issue occurs because the driver doesn&amp;#39;t check the total number of<br /> fragments before calling skb_add_rx_frag(). When a packet requires more<br /> than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.<br /> <br /> Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,<br /> then all fragments are accounted for. And reusing the existing check to<br /> prevent the overflow earlier in the code path.<br /> <br /> This crash occurred in production with an Aquantia AQC113 10G NIC.<br /> <br /> Stack trace from production environment:<br /> ```<br /> RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0<br /> Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89<br /> ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90<br /> c8 00 00 00 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48<br /> 89 fa 83<br /> RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287<br /> RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:<br /> fffffffe0a0c8000<br /> RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:<br /> 0000000000037a40<br /> RBP: 0000000000000024 R08: 0000000000000000 R09:<br /> 0000000000000021<br /> R10: 0000000000000848 R11: 0000000000000000 R12:<br /> ffffa9bec02a8e24<br /> R13: ffff925ad8615570 R14: 0000000000000000 R15:<br /> ffff925b22e80a00<br /> FS: 0000000000000000(0000)<br /> GS:ffff925e47880000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:<br /> 0000000000f72ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> aq_ring_rx_clean+0x175/0xe60 [atlantic]<br /> ? aq_ring_rx_clean+0x14d/0xe60 [atlantic]<br /> ? aq_ring_tx_clean+0xdf/0x190 [atlantic]<br /> ? kmem_cache_free+0x348/0x450<br /> ? aq_vec_poll+0x81/0x1d0 [atlantic]<br /> ? __napi_poll+0x28/0x1c0<br /> ? net_rx_action+0x337/0x420<br /> ```<br /> <br /> Changes in v4:<br /> - Add Fixes: tag to satisfy patch validation requirements.<br /> <br /> Changes in v3:<br /> - Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,<br /> then all fragments are accounted for.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sxgbe: fix potential NULL dereference in sxgbe_rx()<br /> <br /> Currently, when skb is null, the driver prints an error and then<br /> dereferences skb on the next line.<br /> <br /> To fix this, let&amp;#39;s add a &amp;#39;break&amp;#39; after the error message to switch<br /> to sxgbe_rx_refill(), which is similar to the approach taken by the<br /> other drivers in this particular case, e.g. calxeda with xgmac_rx().<br /> <br /> Found during a code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel: punit_ipc: fix memory corruption<br /> <br /> This passes the address of the pointer "&amp;punit_ipcdev" when the intent<br /> was to pass the pointer itself "punit_ipcdev" (without the ampersand).<br /> This means that the:<br /> <br /> complete(&amp;ipcdev-&gt;cmd_complete);<br /> <br /> in intel_punit_ioc() will write to a wrong memory address corrupting it.