Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: thead: th1520-ap: set all AXI clocks to CLK_IS_CRITICAL<br /> <br /> The AXI crossbar of TH1520 has no proper timeout handling, which means<br /> gating AXI clocks can easily lead to bus timeout and thus system hang.<br /> <br /> Set all AXI clock gates to CLK_IS_CRITICAL. All these clock gates are<br /> ungated by default on system reset.<br /> <br /> In addition, convert all current CLK_IGNORE_UNUSED usage to<br /> CLK_IS_CRITICAL to prevent unwanted clock gating.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netconsole: Acquire su_mutex before navigating configs hierarchy<br /> <br /> There is a race between operations that iterate over the userdata<br /> cg_children list and concurrent add/remove of userdata items through<br /> configfs. The update_userdata() function iterates over the<br /> nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also<br /> iterates over this same list to count nodes.<br /> <br /> Quoting from Documentation/filesystems/configfs.rst:<br /> &gt; A subsystem can navigate the cg_children list and the ci_parent pointer<br /> &gt; to see the tree created by the subsystem. This can race with configfs&amp;#39;<br /> &gt; management of the hierarchy, so configfs uses the subsystem mutex to<br /> &gt; protect modifications. Whenever a subsystem wants to navigate the<br /> &gt; hierarchy, it must do so under the protection of the subsystem<br /> &gt; mutex.<br /> <br /> Without proper locking, if a userdata item is added or removed<br /> concurrently while these functions are iterating, the list can be<br /> accessed in an inconsistent state. For example, the list_for_each() loop<br /> can reach a node that is being removed from the list by list_del_init()<br /> which sets the nodes&amp;#39; .next pointer to point to itself, so the loop will<br /> never end (or reach the WARN_ON_ONCE in update_userdata() ).<br /> <br /> Fix this by holding the configfs subsystem mutex (su_mutex) during all<br /> operations that iterate over cg_children.<br /> This includes:<br /> - userdatum_value_store() which calls update_userdata() to iterate over<br /> cg_children<br /> - All sysdata_*_enabled_store() functions which call<br /> count_extradata_entries() to iterate over cg_children<br /> <br /> The su_mutex must be acquired before dynamic_netconsole_mutex to avoid<br /> potential lock ordering issues, as configfs operations may already hold<br /> su_mutex when calling into our code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lan966x: Fix sleeping in atomic context<br /> <br /> The following warning was seen when we try to connect using ssh to the device.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear<br /> preempt_count: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE<br /> Tainted: [W]=WARN<br /> Hardware name: Generic DT based system<br /> Call trace:<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x7c/0xac<br /> dump_stack_lvl from __might_resched+0x16c/0x2b0<br /> __might_resched from __mutex_lock+0x64/0xd34<br /> __mutex_lock from mutex_lock_nested+0x1c/0x24<br /> mutex_lock_nested from lan966x_stats_get+0x5c/0x558<br /> lan966x_stats_get from dev_get_stats+0x40/0x43c<br /> dev_get_stats from dev_seq_printf_stats+0x3c/0x184<br /> dev_seq_printf_stats from dev_seq_show+0x10/0x30<br /> dev_seq_show from seq_read_iter+0x350/0x4ec<br /> seq_read_iter from seq_read+0xfc/0x194<br /> seq_read from proc_reg_read+0xac/0x100<br /> proc_reg_read from vfs_read+0xb0/0x2b0<br /> vfs_read from ksys_read+0x6c/0xec<br /> ksys_read from ret_fast_syscall+0x0/0x1c<br /> Exception stack(0xf0b11fa8 to 0xf0b11ff0)<br /> 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001<br /> 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001<br /> 1fe0: 0005404c be9048c0 00018684 b6ec2cd8<br /> <br /> It seems that we are using a mutex in a atomic context which is wrong.<br /> Change the mutex with a spinlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> page_pool: always add GFP_NOWARN for ATOMIC allocations<br /> <br /> Driver authors often forget to add GFP_NOWARN for page allocation<br /> from the datapath. This is annoying to users as OOMs are a fact<br /> of life, and we pretty much expect network Rx to hit page allocation<br /> failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations<br /> by default.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Avoid crash due to unaligned access in unwinder<br /> <br /> Guenter Roeck reported this kernel crash on his emulated B160L machine:<br /> <br /> Starting network: udhcpc: started, v1.36.1<br /> Backtrace:<br /> [] unwind_once+0x1c/0x5c<br /> [] walk_stackframe.isra.0+0x74/0xb8<br /> [] arch_stack_walk+0x28/0x38<br /> [] stack_trace_save+0x48/0x5c<br /> [] set_track_prepare+0x44/0x6c<br /> [] ___slab_alloc+0xfc4/0x1024<br /> [] __slab_alloc.isra.0+0x58/0x90<br /> [] kmem_cache_alloc_noprof+0x2ac/0x4a0<br /> [] __anon_vma_prepare+0x60/0x280<br /> [] __vmf_anon_prepare+0x68/0x94<br /> [] do_wp_page+0x8cc/0xf10<br /> [] handle_mm_fault+0x6c0/0xf08<br /> [] do_page_fault+0x110/0x440<br /> [] handle_interruption+0x184/0x748<br /> [] schedule+0x4c/0x190<br /> BUG: spinlock recursion on CPU#0, ifconfig/2420<br /> lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0<br /> <br /> While creating the stack trace, the unwinder uses the stack pointer to guess<br /> the previous frame to read the previous stack pointer from memory. The crash<br /> happens, because the unwinder tries to read from unaligned memory and as such<br /> triggers the unalignment trap handler which then leads to the spinlock<br /> recursion and finally to a deadlock.<br /> <br /> Fix it by checking the alignment before accessing the memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sock: Prevent race in socket write iter and sock bind<br /> <br /> There is a potential race condition between sock bind and socket write<br /> iter. bind may free the same cmd via mgmt_pending before write iter sends<br /> the cmd, just as syzbot reported in UAF[1].<br /> <br /> Here we use hci_dev_lock to synchronize the two, thereby avoiding the<br /> UAF mentioned in [1].<br /> <br /> [1]<br /> syzbot reported:<br /> BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> Read of size 8 at addr ffff888077164818 by task syz.0.17/5989<br /> Call Trace:<br /> mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Allocated by task 5989:<br /> mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296<br /> set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Freed by task 5991:<br /> mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]<br /> mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257<br /> mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477<br /> hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface<br /> <br /> When performing reset tests and encountering abnormal card drop issues<br /> that lead to a kernel crash, it is necessary to perform a null check<br /> before releasing resources to avoid attempting to release a null pointer.<br /> <br /> [ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)<br /> [ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]<br /> [ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 29.158162] pc : klist_remove+0x90/0x158<br /> [ 29.158174] lr : klist_remove+0x88/0x158<br /> [ 29.158180] sp : ffffffc0846b3c00<br /> [ 29.158185] pmr_save: 000000e0<br /> [ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058<br /> [ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0<br /> [ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290<br /> [ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781<br /> [ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428<br /> [ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018<br /> [ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000<br /> [ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d<br /> [ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e<br /> [ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c<br /> [ 29.158285] Call trace:<br /> [ 29.158290] klist_remove+0x90/0x158<br /> [ 29.158298] device_release_driver_internal+0x20c/0x268<br /> [ 29.158308] device_release_driver+0x1c/0x30<br /> [ 29.158316] usb_driver_release_interface+0x70/0x88<br /> [ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]<br /> [ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]<br /> [ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]<br /> [ 29.158430] process_scheduled_works+0x258/0x4e8<br /> [ 29.158441] worker_thread+0x300/0x428<br /> [ 29.158448] kthread+0x108/0x1d0<br /> [ 29.158455] ret_from_fork+0x10/0x20<br /> [ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)<br /> [ 29.158474] ---[ end trace 0000000000000000 ]---<br /> [ 29.167129] Kernel panic - not syncing: Oops: Fatal exception<br /> [ 29.167144] SMP: stopping secondary CPUs<br /> [ 29.167158] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs<br /> <br /> The driver lacks the cleanup of failed transfers of URBs. This reduces the<br /> number of available URBs per error by 1. This leads to reduced performance<br /> and ultimately to a complete stop of the transmission.<br /> <br /> If the sending of a bulk URB fails do proper cleanup:<br /> - increase netdev stats<br /> - mark the echo_sbk as free<br /> - free the driver&amp;#39;s context and do accounting<br /> - wake the send queue

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.