Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING<br /> <br /> hrtimers are migrated away from the dying CPU to any online target at<br /> the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers<br /> handling tasks involved in the CPU hotplug forward progress.<br /> <br /> However wakeups can still be performed by the outgoing CPU after<br /> CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being<br /> armed. Depending on several considerations (crystal ball power management<br /> based election, earliest timer already enqueued, timer migration enabled or<br /> not), the target may eventually be the current CPU even if offline. If that<br /> happens, the timer is eventually ignored.<br /> <br /> The most notable example is RCU which had to deal with each and every of<br /> those wake-ups by deferring them to an online CPU, along with related<br /> workarounds:<br /> <br /> _ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)<br /> _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)<br /> _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)<br /> <br /> The problem isn&amp;#39;t confined to RCU though as the stop machine kthread<br /> (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end<br /> of its work through cpu_stop_signal_done() and performs a wake up that<br /> eventually arms the deadline server timer:<br /> <br /> WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0<br /> CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted<br /> Stopper: multi_cpu_stop+0x0/0x120

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/amd/display: Use HW lock mgr for PSR1"<br /> <br /> This reverts commit<br /> a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")<br /> <br /> Because it may cause system hang while connect with two edp panel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: xilinx_uartps: split sysrq handling<br /> <br /> lockdep detects the following circular locking dependency:<br /> <br /> CPU 0 CPU 1<br /> ========================== ============================<br /> cdns_uart_isr() printk()<br /> uart_port_lock(port) console_lock()<br /> cdns_uart_console_write()<br /> if (!port-&gt;sysrq)<br /> uart_port_lock(port)<br /> uart_handle_break()<br /> port-&gt;sysrq = ...<br /> uart_handle_sysrq_char()<br /> printk()<br /> console_lock()<br /> <br /> The fixed commit attempts to avoid this situation by only taking the<br /> port lock in cdns_uart_console_write if port-&gt;sysrq unset. However, if<br /> (as shown above) cdns_uart_console_write runs before port-&gt;sysrq is set,<br /> then it will try to take the port lock anyway. This may result in a<br /> deadlock.<br /> <br /> Fix this by splitting sysrq handling into two parts. We use the prepare<br /> helper under the port lock and defer handling until we release the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: omap: use threaded IRQ for LCD DMA<br /> <br /> When using touchscreen and framebuffer, Nokia 770 crashes easily with:<br /> <br /> BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000<br /> Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd<br /> CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2<br /> Hardware name: Nokia 770<br /> Call trace:<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x54/0x5c<br /> dump_stack_lvl from __schedule_bug+0x50/0x70<br /> __schedule_bug from __schedule+0x4d4/0x5bc<br /> __schedule from schedule+0x34/0xa0<br /> schedule from schedule_preempt_disabled+0xc/0x10<br /> schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4<br /> __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4<br /> clk_prepare_lock from clk_set_rate+0x18/0x154<br /> clk_set_rate from sossi_read_data+0x4c/0x168<br /> sossi_read_data from hwa742_read_reg+0x5c/0x8c<br /> hwa742_read_reg from send_frame_handler+0xfc/0x300<br /> send_frame_handler from process_pending_requests+0x74/0xd0<br /> process_pending_requests from lcd_dma_irq_handler+0x50/0x74<br /> lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130<br /> __handle_irq_event_percpu from handle_irq_event+0x28/0x68<br /> handle_irq_event from handle_level_irq+0x9c/0x170<br /> handle_level_irq from generic_handle_domain_irq+0x2c/0x3c<br /> generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c<br /> omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c<br /> generic_handle_arch_irq from call_with_stack+0x1c/0x24<br /> call_with_stack from __irq_svc+0x94/0xa8<br /> Exception stack(0xc5255da0 to 0xc5255de8)<br /> 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248<br /> 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94<br /> 5de0: 60000013 ffffffff<br /> __irq_svc from clk_prepare_lock+0x4c/0xe4<br /> clk_prepare_lock from clk_get_rate+0x10/0x74<br /> clk_get_rate from uwire_setup_transfer+0x40/0x180<br /> uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c<br /> spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664<br /> spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498<br /> __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8<br /> __spi_sync from spi_sync+0x24/0x40<br /> spi_sync from ads7846_halfd_read_state+0x5c/0x1c0<br /> ads7846_halfd_read_state from ads7846_irq+0x58/0x348<br /> ads7846_irq from irq_thread_fn+0x1c/0x78<br /> irq_thread_fn from irq_thread+0x120/0x228<br /> irq_thread from kthread+0xc8/0xe8<br /> kthread from ret_from_fork+0x14/0x28<br /> <br /> As a quick fix, switch to a threaded IRQ which provides a stable system.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Drop unmanaged ELP metric worker<br /> <br /> The ELP worker needs to calculate new metric values for all neighbors<br /> "reachable" over an interface. Some of the used metric sources require<br /> locks which might need to sleep. This sleep is incompatible with the RCU<br /> list iterator used for the recorded neighbors. The initial approach to work<br /> around of this problem was to queue another work item per neighbor and then<br /> run this in a new context.<br /> <br /> Even when this solved the RCU vs might_sleep() conflict, it has a major<br /> problems: Nothing was stopping the work item in case it is not needed<br /> anymore - for example because one of the related interfaces was removed or<br /> the batman-adv module was unloaded - resulting in potential invalid memory<br /> accesses.<br /> <br /> Directly canceling the metric worker also has various problems:<br /> <br /> * cancel_work_sync for a to-be-deactivated interface is called with<br /> rtnl_lock held. But the code in the ELP metric worker also tries to use<br /> rtnl_lock() - which will never return in this case. This also means that<br /> cancel_work_sync would never return because it is waiting for the worker<br /> to finish.<br /> * iterating over the neighbor list for the to-be-deactivated interface is<br /> currently done using the RCU specific methods. Which means that it is<br /> possible to miss items when iterating over it without the associated<br /> spinlock - a behaviour which is acceptable for a periodic metric check<br /> but not for a cleanup routine (which must "stop" all still running<br /> workers)<br /> <br /> The better approch is to get rid of the per interface neighbor metric<br /> worker and handle everything in the interface worker. The original problems<br /> are solved by:<br /> <br /> * creating a list of neighbors which require new metric information inside<br /> the RCU protected context, gathering the metric according to the new list<br /> outside the RCU protected context<br /> * only use rcu_trylock inside metric gathering code to avoid a deadlock<br /> when the cancel_delayed_work_sync is called in the interface removal code<br /> (which is called with the rtnl_lock held)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> timers/migration: Fix off-by-one root mis-connection<br /> <br /> Before attaching a new root to the old root, the children counter of the<br /> new root is checked to verify that only the upcoming CPU&amp;#39;s top group have<br /> been connected to it. However since the recently added commit b729cc1ec21a<br /> ("timers/migration: Fix another race between hotplug and idle entry/exit")<br /> this check is not valid anymore because the old root is pre-accounted<br /> as a child to the new root. Therefore after connecting the upcoming<br /> CPU&amp;#39;s top group to the new root, the children count to be expected must<br /> be 2 and not 1 anymore.<br /> <br /> This omission results in the old root to not be connected to the new<br /> root. Then eventually the system may run with more than one top level,<br /> which defeats the purpose of a single idle migrator.<br /> <br /> Also the old root is pre-accounted but not connected upon the new root<br /> creation. But it can be connected to the new root later on. Therefore<br /> the old root may be accounted twice to the new root. The propagation of<br /> such overcommit can end up creating a double final top-level root with a<br /> groupmask incorrectly initialized. Although harmless given that the final<br /> top level roots will never have a parent to walk up to, this oddity<br /> opportunistically reported the core issue:<br /> <br /> WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote<br /> CPU: 8 UID: 0 PID: 0 Comm: swapper/8<br /> RIP: 0010:tmigr_requires_handle_remote<br /> Call Trace:<br /> <br /> ? tmigr_requires_handle_remote<br /> ? hrtimer_run_queues<br /> update_process_times<br /> tick_periodic<br /> tick_handle_periodic<br /> __sysvec_apic_timer_interrupt<br /> sysvec_apic_timer_interrupt<br /> <br /> <br /> Fix the problem by taking the old root into account in the children count<br /> of the new root so the connection is not omitted.<br /> <br /> Also warn when more than one top level group exists to better detect<br /> similar issues in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()<br /> <br /> There are a potential wild pointer dereferences issue regarding APIs<br /> class_dev_iter_(init|next|exit)(), as explained by below typical usage:<br /> <br /> // All members of @iter are wild pointers.<br /> struct class_dev_iter iter;<br /> <br /> // class_dev_iter_init(@iter, @class, ...) checks parameter @class for<br /> // potential class_to_subsys() error, and it returns void type and does<br /> // not initialize its output parameter @iter, so caller can not detect<br /> // the error and continues to invoke class_dev_iter_next(@iter) even if<br /> // @iter still contains wild pointers.<br /> class_dev_iter_init(&amp;iter, ...);<br /> <br /> // Dereference these wild pointers in @iter here once suffer the error.<br /> while (dev = class_dev_iter_next(&amp;iter)) { ... };<br /> <br /> // Also dereference these wild pointers here.<br /> class_dev_iter_exit(&amp;iter);<br /> <br /> Actually, all callers of these APIs have such usage pattern in kernel tree.<br /> Fix by:<br /> - Initialize output parameter @iter by memset() in class_dev_iter_init()<br /> and give callers prompt by pr_crit() for the error.<br /> - Check if @iter is valid in class_dev_iter_next().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xdp: Disallow attaching device-bound programs in generic mode<br /> <br /> Device-bound programs are used to support RX metadata kfuncs. These<br /> kfuncs are driver-specific and rely on the driver context to read the<br /> metadata. This means they can&amp;#39;t work in generic XDP mode. However, there<br /> is no check to disallow such programs from being attached in generic<br /> mode, in which case the metadata kfuncs will be called in an invalid<br /> context, leading to crashes.<br /> <br /> Fix this by adding a check to disallow attaching device-bound programs<br /> in generic mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix queue freeze vs limits lock order in sysfs store methods<br /> <br /> queue_attr_store() always freezes a device queue before calling the<br /> attribute store operation. For attributes that control queue limits, the<br /> store operation will also lock the queue limits with a call to<br /> queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may<br /> need to issue commands to a device to obtain limit values from the<br /> hardware with the queue limits locked. This creates a potential ABBA<br /> deadlock situation if a user attempts to modify a limit (thus freezing<br /> the device queue) while the device driver starts a revalidation of the<br /> device queue limits.<br /> <br /> Avoid such deadlock by not freezing the queue before calling the<br /> -&gt;store_limit() method in struct queue_sysfs_entry and instead use the<br /> queue_limits_commit_update_frozen helper to freeze the queue after taking<br /> the limits lock.<br /> <br /> This also removes taking the sysfs lock for the store_limit method as<br /> it doesn&amp;#39;t protect anything here, but creates even more nesting.<br /> Hopefully it will go away from the actual sysfs methods entirely soon.<br /> <br /> (commit log adapted from a similar patch from Damien Le Moal)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs: Add missing deinit() call<br /> <br /> A warning is triggered when repeatedly connecting and disconnecting the<br /> rnbd:<br /> list_add corruption. prev-&gt;next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).<br /> WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0<br /> Workqueue: ib_cm cm_work_handler [ib_cm]<br /> RIP: 0010:__list_add_valid_or_report+0x7f/0xa0<br /> ? __list_add_valid_or_report+0x7f/0xa0<br /> ib_register_event_handler+0x65/0x93 [ib_core]<br /> rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]<br /> rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]<br /> __alloc_path+0x46c/0x680 [rtrs_server]<br /> ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]<br /> ? rcu_is_watching+0xd/0x40<br /> ? __mutex_lock+0x312/0xcf0<br /> ? get_or_create_srv+0xad/0x310 [rtrs_server]<br /> ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]<br /> rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]<br /> ? __lock_release+0x1b1/0x2d0<br /> cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]<br /> cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]<br /> cm_process_work+0x28/0x1a0 [ib_cm]<br /> ? _raw_spin_unlock_irq+0x2f/0x50<br /> cm_req_handler+0x618/0xa60 [ib_cm]<br /> cm_work_handler+0x71/0x520 [ib_cm]<br /> <br /> Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a<br /> new element .deinit but never used it at all. Fix it by invoking the<br /> `deinit()` to appropriately unregister the IB event handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc, afs: Fix peer hash locking vs RCU callback<br /> <br /> In its address list, afs now retains pointers to and refs on one or more<br /> rxrpc_peer objects. The address list is freed under RCU and at this time,<br /> it puts the refs on those peers.<br /> <br /> Now, when an rxrpc_peer object runs out of refs, it gets removed from the<br /> peer hash table and, for that, rxrpc has to take a spinlock. However, it<br /> is now being called from afs&amp;#39;s RCU cleanup, which takes place in BH<br /> context - but it is just taking an ordinary spinlock.<br /> <br /> The put may also be called from non-BH context, and so there exists the<br /> possibility of deadlock if the BH-based RCU cleanup happens whilst the hash<br /> spinlock is held. This led to the attached lockdep complaint.<br /> <br /> Fix this by changing spinlocks of rxnet-&gt;peer_hash_lock back to<br /> BH-disabling locks.<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.13.0-rc5-build2+ #1223 Tainted: G E<br /> --------------------------------<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:<br /> ffff88810babe228 (&amp;rxnet-&gt;peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180<br /> {SOFTIRQ-ON-W} state was registered at:<br /> mark_usage+0x164/0x180<br /> __lock_acquire+0x544/0x990<br /> lock_acquire.part.0+0x103/0x280<br /> _raw_spin_lock+0x2f/0x40<br /> rxrpc_peer_keepalive_worker+0x144/0x440<br /> process_one_work+0x486/0x7c0<br /> process_scheduled_works+0x73/0x90<br /> worker_thread+0x1c8/0x2a0<br /> kthread+0x19b/0x1b0<br /> ret_from_fork+0x24/0x40<br /> ret_from_fork_asm+0x1a/0x30<br /> irq event stamp: 972402<br /> hardirqs last enabled at (972402): [] _raw_spin_unlock_irqrestore+0x2e/0x50<br /> hardirqs last disabled at (972401): [] _raw_spin_lock_irqsave+0x18/0x60<br /> softirqs last enabled at (972300): [] handle_softirqs+0x3ee/0x430<br /> softirqs last disabled at (972313): [] __irq_exit_rcu+0x44/0x110<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0<br /> ----<br /> lock(&amp;rxnet-&gt;peer_hash_lock);<br /> <br /> lock(&amp;rxnet-&gt;peer_hash_lock);<br /> <br /> *** DEADLOCK ***<br /> 1 lock held by swapper/1/0:<br /> #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x80<br /> print_usage_bug.part.0+0x227/0x240<br /> valid_state+0x53/0x70<br /> mark_lock_irq+0xa5/0x2f0<br /> mark_lock+0xf7/0x170<br /> mark_usage+0xe1/0x180<br /> __lock_acquire+0x544/0x990<br /> lock_acquire.part.0+0x103/0x280<br /> _raw_spin_lock+0x2f/0x40<br /> rxrpc_put_peer+0xcb/0x180<br /> afs_free_addrlist+0x46/0x90 [kafs]<br /> rcu_do_batch+0x2d2/0x640<br /> rcu_core+0x2f7/0x350<br /> handle_softirqs+0x1ee/0x430<br /> __irq_exit_rcu+0x44/0x110<br /> irq_exit_rcu+0xa/0x30<br /> sysvec_apic_timer_interrupt+0x7f/0xa0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()<br /> <br /> The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()<br /> macro to request a needed resource. A string variable that lives on the<br /> stack is then used to store a dynamically computed resource name, which<br /> is then passed on as one of the macro arguments. This can lead to<br /> undefined behavior.<br /> <br /> Depending on the current contents of the memory, the manifestations of<br /> errors may vary. One possible output may be as follows:<br /> <br /> $ cat /proc/iomem<br /> 30000000-37ffffff :<br /> 38000000-3fffffff :<br /> <br /> Sometimes, garbage may appear after the colon.<br /> <br /> In very rare cases, if no NULL-terminator is found in memory, the system<br /> might crash because the string iterator will overrun which can lead to<br /> access of unmapped memory above the stack.<br /> <br /> Thus, fix this by replacing outbound_name with the name of the previously<br /> requested resource. With the changes applied, the output will be as<br /> follows:<br /> <br /> $ cat /proc/iomem<br /> 30000000-37ffffff : memory2<br /> 38000000-3fffffff : memory3<br /> <br /> [kwilczynski: commit log]