Security Vulnerabilities - CVEs Published In February 2025
In the Linux kernel, the following vulnerability has been resolved:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1
========================== ============================
cdns_uart_isr() printk()
uart_port_lock(port) console_lock()
cdns_uart_console_write()
if (!port->sysrq)
uart_port_lock(port)
uart_handle_break()
port->sysrq = ...
uart_handle_sysrq_char()
printk()
console_lock()
The fixed commit attempts to avoid this situation by only taking the
port lock in cdns_uart_console_write if port->sysrq unset. However, if
(as shown above) cdns_uart_console_write runs before port->sysrq is set,
then it will try to take the port lock anyway. This may result in a
deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare
helper under the port lock and defer handling until we release the lock.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
fbdev: omap: use threaded IRQ for LCD DMA
When using touchscreen and framebuffer, Nokia 770 crashes easily with:
BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000
Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd
CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2
Hardware name: Nokia 770
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x54/0x5c
dump_stack_lvl from __schedule_bug+0x50/0x70
__schedule_bug from __schedule+0x4d4/0x5bc
__schedule from schedule+0x34/0xa0
schedule from schedule_preempt_disabled+0xc/0x10
schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4
__mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4
clk_prepare_lock from clk_set_rate+0x18/0x154
clk_set_rate from sossi_read_data+0x4c/0x168
sossi_read_data from hwa742_read_reg+0x5c/0x8c
hwa742_read_reg from send_frame_handler+0xfc/0x300
send_frame_handler from process_pending_requests+0x74/0xd0
process_pending_requests from lcd_dma_irq_handler+0x50/0x74
lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130
__handle_irq_event_percpu from handle_irq_event+0x28/0x68
handle_irq_event from handle_level_irq+0x9c/0x170
handle_level_irq from generic_handle_domain_irq+0x2c/0x3c
generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c
omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c
generic_handle_arch_irq from call_with_stack+0x1c/0x24
call_with_stack from __irq_svc+0x94/0xa8
Exception stack(0xc5255da0 to 0xc5255de8)
5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248
5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94
5de0: 60000013 ffffffff
__irq_svc from clk_prepare_lock+0x4c/0xe4
clk_prepare_lock from clk_get_rate+0x10/0x74
clk_get_rate from uwire_setup_transfer+0x40/0x180
uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c
spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664
spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498
__spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8
__spi_sync from spi_sync+0x24/0x40
spi_sync from ads7846_halfd_read_state+0x5c/0x1c0
ads7846_halfd_read_state from ads7846_irq+0x58/0x348
ads7846_irq from irq_thread_fn+0x1c/0x78
irq_thread_fn from irq_thread+0x120/0x228
irq_thread from kthread+0xc8/0xe8
kthread from ret_from_fork+0x14/0x28
As a quick fix, switch to a threaded IRQ which provides a stable system.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
ptp: vmclock: Set driver data before its usage
If vmclock_ptp_register() fails during probing, vmclock_remove() is
called to clean up the ptp clock and misc device.
It uses dev_get_drvdata() to access the vmclock state.
However the driver data is not yet set at this point.
Assign the driver data earlier.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Drop unmanaged ELP metric worker
The ELP worker needs to calculate new metric values for all neighbors
"reachable" over an interface. Some of the used metric sources require
locks which might need to sleep. This sleep is incompatible with the RCU
list iterator used for the recorded neighbors. The initial approach to work
around of this problem was to queue another work item per neighbor and then
run this in a new context.
Even when this solved the RCU vs might_sleep() conflict, it has a major
problems: Nothing was stopping the work item in case it is not needed
anymore - for example because one of the related interfaces was removed or
the batman-adv module was unloaded - resulting in potential invalid memory
accesses.
Directly canceling the metric worker also has various problems:
* cancel_work_sync for a to-be-deactivated interface is called with
rtnl_lock held. But the code in the ELP metric worker also tries to use
rtnl_lock() - which will never return in this case. This also means that
cancel_work_sync would never return because it is waiting for the worker
to finish.
* iterating over the neighbor list for the to-be-deactivated interface is
currently done using the RCU specific methods. Which means that it is
possible to miss items when iterating over it without the associated
spinlock - a behaviour which is acceptable for a periodic metric check
but not for a cleanup routine (which must "stop" all still running
workers)
The better approch is to get rid of the per interface neighbor metric
worker and handle everything in the interface worker. The original problems
are solved by:
* creating a list of neighbors which require new metric information inside
the RCU protected context, gathering the metric according to the new list
outside the RCU protected context
* only use rcu_trylock inside metric gathering code to avoid a deadlock
when the cancel_delayed_work_sync is called in the interface removal code
(which is called with the rtnl_lock held)
CVSS Score
5.5
EPSS Score
0.001
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix a use of uninitialized mutex
commit c8347f915e67 ("gpu: host1x: Fix boot regression for Tegra")
caused a use of uninitialized mutex leading to below warning when
CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC are enabled.
[ 41.662843] ------------[ cut here ]------------
[ 41.663012] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878
[ 41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod
[ 41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1
[ 41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024
[ 41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 41.679636] pc : __mutex_lock+0x670/0x878
[ 41.683834] lr : __mutex_lock+0x670/0x878
[ 41.688035] sp : ffff800084b77090
[ 41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000
[ 41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000
[ 41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0
[ 41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000
[ 41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720
[ 41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3
[ 41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc
[ 41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001
[ 41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000
[ 41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000
[ 41.764251] Call trace:
[ 41.766695] __mutex_lock+0x670/0x878
[ 41.770373] mutex_lock_nested+0x2c/0x40
[ 41.774134] host1x_intr_start+0x54/0xf8 [host1x]
[ 41.778863] host1x_runtime_resume+0x150/0x228 [host1x]
[ 41.783935] pm_generic_runtime_resume+0x84/0xc8
[ 41.788485] __rpm_callback+0xa0/0x478
[ 41.792422] rpm_callback+0x15c/0x1a8
[ 41.795922] rpm_resume+0x698/0xc08
[ 41.799597] __pm_runtime_resume+0xa8/0x140
[ 41.803621] host1x_probe+0x810/0xbc0 [host1x]
[ 41.807909] platform_probe+0xcc/0x1a8
[ 41.811845] really_probe+0x188/0x800
[ 41.815347] __driver_probe_device+0x164/0x360
[ 41.819810] driver_probe_device+0x64/0x1a8
[ 41.823834] __driver_attach+0x180/0x490
[ 41.827773] bus_for_each_dev+0x104/0x1a0
[ 41.831797] driver_attach+0x44/0x68
[ 41.835296] bus_add_driver+0x23c/0x4e8
[ 41.839235] driver_register+0x15c/0x3a8
[ 41.843170] __platform_register_drivers+0xa4/0x208
[ 41.848159] tegra_host1x_init+0x4c/0xff8 [host1x]
[ 41.853147] do_one_initcall+0xd4/0x380
[ 41.856997] do_init_module+0x1dc/0x698
[ 41.860758] load_module+0xc70/0x1300
[ 41.864435] __do_sys_init_module+0x1a8/0x1d0
[ 41.868721] __arm64_sys_init_module+0x74/0xb0
[ 41.873183] invoke_syscall.constprop.0+0xdc/0x1e8
[ 41.877997] do_el0_svc+0x154/0x1d0
[ 41.881671] el0_svc+0x54/0x140
[ 41.884820] el0t_64_sync_handler+0x120/0x130
[ 41.889285] el0t_64_sync+0x1a4/0x1a8
[ 41.892960] irq event stamp: 69737
[ 41.896370] hardirqs last enabled at (69737): [<ffffdd4be6d7768c>] _raw_spin_unlock_irqrestore+0x44/0xe8
[ 41.905739] hardirqs last disabled at (69736):
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
elestio memos v0.23.0 is vulnerable to Server-Side Request Forgery (SSRF) due to insufficient validation of user-supplied URLs, which can be exploited to perform SSRF attacks.
CVSS Score
9.8
EPSS Score
0.35
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()
macro to request a needed resource. A string variable that lives on the
stack is then used to store a dynamically computed resource name, which
is then passed on as one of the macro arguments. This can lead to
undefined behavior.
Depending on the current contents of the memory, the manifestations of
errors may vary. One possible output may be as follows:
$ cat /proc/iomem
30000000-37ffffff :
38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system
might crash because the string iterator will overrun which can lead to
access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously
requested resource. With the changes applied, the output will be as
follows:
$ cat /proc/iomem
30000000-37ffffff : memory2
38000000-3fffffff : memory3
[kwilczynski: commit log]
CVSS Score
5.5
EPSS Score
0.001
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Add missing deinit() call
A warning is triggered when repeatedly connecting and disconnecting the
rnbd:
list_add corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).
WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0
Workqueue: ib_cm cm_work_handler [ib_cm]
RIP: 0010:__list_add_valid_or_report+0x7f/0xa0
? __list_add_valid_or_report+0x7f/0xa0
ib_register_event_handler+0x65/0x93 [ib_core]
rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]
rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]
__alloc_path+0x46c/0x680 [rtrs_server]
? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
? rcu_is_watching+0xd/0x40
? __mutex_lock+0x312/0xcf0
? get_or_create_srv+0xad/0x310 [rtrs_server]
? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]
? __lock_release+0x1b1/0x2d0
cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]
cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]
cm_process_work+0x28/0x1a0 [ib_cm]
? _raw_spin_unlock_irq+0x2f/0x50
cm_req_handler+0x618/0xa60 [ib_cm]
cm_work_handler+0x71/0x520 [ib_cm]
Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a
new element .deinit but never used it at all. Fix it by invoking the
`deinit()` to appropriately unregister the IB event handler.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
net: let net.core.dev_weight always be non-zero
The following problem was encountered during stability test:
(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \
returned 1, exceeding its budget of 0.
------------[ cut here ]------------
list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \
next=ffff88905f746e40.
WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \
__list_add_valid_or_report+0xf3/0x130
CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+
RIP: 0010:__list_add_valid_or_report+0xf3/0x130
Call Trace:
? __warn+0xcd/0x250
? __list_add_valid_or_report+0xf3/0x130
enqueue_to_backlog+0x923/0x1070
netif_rx_internal+0x92/0x2b0
__netif_rx+0x15/0x170
loopback_xmit+0x2ef/0x450
dev_hard_start_xmit+0x103/0x490
__dev_queue_xmit+0xeac/0x1950
ip_finish_output2+0x6cc/0x1620
ip_output+0x161/0x270
ip_push_pending_frames+0x155/0x1a0
raw_sendmsg+0xe13/0x1550
__sys_sendto+0x3bf/0x4e0
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x5b/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The reproduction command is as follows:
sysctl -w net.core.dev_weight=0
ping 127.0.0.1
This is because when the napi's weight is set to 0, process_backlog() may
return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this
napi to be re-polled in net_rx_action() until __do_softirq() times out.
Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can
be retriggered in enqueue_to_backlog(), causing this issue.
Making the napi's weight always non-zero solves this problem.
Triggering this issue requires system-wide admin (setting is
not namespaced).
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27
In the Linux kernel, the following vulnerability has been resolved:
block: fix queue freeze vs limits lock order in sysfs store methods
queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.
Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.
This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.
(commit log adapted from a similar patch from Damien Le Moal)
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-27