Security Vulnerabilities
- CVEs Published In February 2025
In the Linux kernel, the following vulnerability has been resolved:
rtw89: cfo: check mac_id to avoid out-of-bounds
Somehow, hardware reports incorrect mac_id and pollute memory. Check index
before we access the array.
UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23
index 188 is out of range for type 's32 [64]'
CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE
Call Trace:
<IRQ>
show_stack+0x52/0x58
dump_stack_lvl+0x4c/0x63
dump_stack+0x10/0x12
ubsan_epilogue+0x9/0x45
__ubsan_handle_out_of_bounds.cold+0x44/0x49
? __alloc_skb+0x92/0x1d0
rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core]
rtw89_core_rx+0x261/0x871 [rtw89_core]
? __alloc_skb+0xee/0x1d0
rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci]
__napi_poll+0x33/0x1a0
net_rx_action+0x126/0x260
? __queue_work+0x217/0x4c0
__do_softirq+0xd9/0x315
? disable_irq_nosync+0x10/0x10
do_softirq.part.0+0x6d/0x90
</IRQ>
<TASK>
__local_bh_enable_ip+0x62/0x70
rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci]
irq_thread_fn+0x28/0x60
irq_thread+0xc8/0x190
? irq_thread_fn+0x60/0x60
kthread+0x16b/0x190
? irq_thread_check_affinity+0xe0/0xe0
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK>
In the Linux kernel, the following vulnerability has been resolved:
net: phy: micrel: Allow probing without .driver_data
Currently, if the .probe element is present in the phy_driver structure
and the .driver_data is not, a NULL pointer dereference happens.
Allow passing .probe without .driver_data by inserting NULL checks
for priv->type.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_*
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout
Connecting the same socket twice consecutively in sco_sock_connect()
could lead to a race condition where two sco_conn objects are created
but only one is associated with the socket. If the socket is closed
before the SCO connection is established, the timer associated with the
dangling sco_conn object won't be canceled. As the sock object is being
freed, the use-after-free problem happens when the timer callback
function sco_sock_timeout() accesses the socket. Here's the call trace:
dump_stack+0x107/0x163
? refcount_inc+0x1c/
print_address_description.constprop.0+0x1c/0x47e
? refcount_inc+0x1c/0x7b
kasan_report+0x13a/0x173
? refcount_inc+0x1c/0x7b
check_memory_region+0x132/0x139
refcount_inc+0x1c/0x7b
sco_sock_timeout+0xb2/0x1ba
process_one_work+0x739/0xbd1
? cancel_delayed_work+0x13f/0x13f
? __raw_spin_lock_init+0xf0/0xf0
? to_kthread+0x59/0x85
worker_thread+0x593/0x70e
kthread+0x346/0x35a
? drain_workqueue+0x31a/0x31a
? kthread_bind+0x4b/0x4b
ret_from_fork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix kernel crash at mt7921_pci_remove
The crash log shown it is possible that mt7921_irq_handler is called while
devm_free_irq is being handled so mt76_free_device need to be postponed
until devm_free_irq is completed to solve the crash we free the mt76 device
too early.
[ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 9299.339705] #PF: supervisor read access in kernel mode
[ 9299.339735] #PF: error_code(0x0000) - not-present page
[ 9299.339768] PGD 0 P4D 0
[ 9299.339786] Oops: 0000 [#1] SMP PTI
[ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1
[ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022
[ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e]
[ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082
[ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5
[ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020
[ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011
[ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080
[ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228
[ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000
[ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0
[ 9299.340432] PKRU: 55555554
[ 9299.340449] Call Trace:
[ 9299.340467] <TASK>
[ 9299.340485] __free_irq+0x221/0x350
[ 9299.340527] free_irq+0x30/0x70
[ 9299.340553] devm_free_irq+0x55/0x80
[ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e]
[ 9299.340616] pci_device_remove+0x3b/0xa0
[ 9299.340651] __device_release_driver+0x17a/0x240
[ 9299.340686] device_driver_detach+0x3c/0xa0
[ 9299.340714] unbind_store+0x113/0x130
[ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0
[ 9299.340775] new_sync_write+0x15c/0x1f0
[ 9299.340806] vfs_write+0x1d2/0x270
[ 9299.340831] ksys_write+0x67/0xe0
[ 9299.340857] do_syscall_64+0x3b/0x90
[ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae
In the Linux kernel, the following vulnerability has been resolved:
ASoC: samsung: Fix refcount leak in aries_audio_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
If extcon_find_edev_by_node() fails, it doesn't call of_node_put()
Calling of_node_put() after extcon_find_edev_by_node() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
ARM: versatile: Add missing of_node_put in dcscb_init
The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: don't free the IRQ if it was not requested
As msm_drm_uninit() is called from the msm_drm_init() error path,
additional care should be necessary as not to call the free_irq() for
the IRQ that was not requested before (because an error occured earlier
than the request_irq() call).
This fixed the issue reported with the following backtrace:
[ 8.571329] Trying to free already-free IRQ 187
[ 8.571339] WARNING: CPU: 0 PID: 76 at kernel/irq/manage.c:1895 free_irq+0x1e0/0x35c
[ 8.588746] Modules linked in: pmic_glink pdr_interface fastrpc qrtr_smd snd_soc_hdmi_codec msm fsa4480 gpu_sched drm_dp_aux_bus qrtr i2c_qcom_geni crct10dif_ce qcom_stats qcom_q6v5_pas drm_display_helper gpi qcom_pil_info drm_kms_helper qcom_q6v5 qcom_sysmon qcom_common qcom_glink_smem qcom_rng mdt_loader qmi_helpers phy_qcom_qmp ufs_qcom typec qnoc_sm8350 socinfo rmtfs_mem fuse drm ipv6
[ 8.624154] CPU: 0 PID: 76 Comm: kworker/u16:2 Not tainted 5.18.0-rc5-next-20220506-00033-g6cee8cab6089-dirty #419
[ 8.624161] Hardware name: Qualcomm Technologies, Inc. SM8350 HDK (DT)
[ 8.641496] Workqueue: events_unbound deferred_probe_work_func
[ 8.647510] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 8.654681] pc : free_irq+0x1e0/0x35c
[ 8.658454] lr : free_irq+0x1e0/0x35c
[ 8.662228] sp : ffff800008ab3950
[ 8.665642] x29: ffff800008ab3950 x28: 0000000000000000 x27: ffff16350f56a700
[ 8.672994] x26: ffff1635025df080 x25: ffff16350251badc x24: ffff16350251bb90
[ 8.680343] x23: 0000000000000000 x22: 00000000000000bb x21: ffff16350e8f9800
[ 8.687690] x20: ffff16350251ba00 x19: ffff16350cbd5880 x18: ffffffffffffffff
[ 8.695039] x17: 0000000000000000 x16: ffffa2dd12179434 x15: ffffa2dd1431d02d
[ 8.702391] x14: 0000000000000000 x13: ffffa2dd1431d028 x12: 662d79646165726c
[ 8.709740] x11: ffffa2dd13fd2438 x10: 000000000000000a x9 : 00000000000000bb
[ 8.717111] x8 : ffffa2dd13fd23f0 x7 : ffff800008ab3750 x6 : 00000000fffff202
[ 8.724487] x5 : ffff16377e870a18 x4 : 00000000fffff202 x3 : ffff735a6ae1b000
[ 8.731851] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff1635015f8000
[ 8.739217] Call trace:
[ 8.741755] free_irq+0x1e0/0x35c
[ 8.745198] msm_drm_uninit.isra.0+0x14c/0x294 [msm]
[ 8.750548] msm_drm_bind+0x28c/0x5d0 [msm]
[ 8.755081] try_to_bring_up_aggregate_device+0x164/0x1d0
[ 8.760657] __component_add+0xa0/0x170
[ 8.764626] component_add+0x14/0x20
[ 8.768337] dp_display_probe+0x2a4/0x464 [msm]
[ 8.773242] platform_probe+0x68/0xe0
[ 8.777043] really_probe.part.0+0x9c/0x28c
[ 8.781368] __driver_probe_device+0x98/0x144
[ 8.785871] driver_probe_device+0x40/0x140
[ 8.790191] __device_attach_driver+0xb4/0x120
[ 8.794788] bus_for_each_drv+0x78/0xd0
[ 8.798751] __device_attach+0xdc/0x184
[ 8.802713] device_initial_probe+0x14/0x20
[ 8.807031] bus_probe_device+0x9c/0xa4
[ 8.810991] deferred_probe_work_func+0x88/0xc0
[ 8.815667] process_one_work+0x1d0/0x320
[ 8.819809] worker_thread+0x14c/0x444
[ 8.823688] kthread+0x10c/0x110
[ 8.827036] ret_from_fork+0x10/0x20
Patchwork: https://patchwork.freedesktop.org/patch/485422/
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe
platform_get_resource() may return NULL, add proper check to
avoid potential NULL dereferencing.