| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: ocb: skip rx_no_sta when interface is not joined
ieee80211_ocb_rx_no_sta() assumes a valid channel context, which is only
present after JOIN_OCB.
RX may run before JOIN_OCB is executed, in which case the OCB interface
is not operational. Skip RX peer handling when the interface is not
joined to avoid warnings in the RX path. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check in __bpf_get_stackid()
Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()
when copying stack trace data. The issue occurs when the perf trace
contains more stack entries than the stack map bucket can hold,
leading to an out-of-bounds write in the bucket's data array. |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: ETR: Fix ETR buffer use-after-free issue
When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed
and enabled again, currently sysfs_buf will point to the newly
allocated memory(buf_new) and free the old memory(buf_old). But the
etr_buf that is being used by the ETR remains pointed to buf_old, not
updated to buf_new. In this case, it will result in a memory
use-after-free issue.
Fix this by checking ETR's mode before updating and releasing buf_old,
if the mode is CS_MODE_SYSFS, then skip updating and releasing it. |
| In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix race in syncpt alloc/free
Fix race condition between host1x_syncpt_alloc()
and host1x_syncpt_put() by using kref_put_mutex()
instead of kref_put() + manual mutex locking.
This ensures no thread can acquire the
syncpt_mutex after the refcount drops to zero
but before syncpt_release acquires it.
This prevents races where syncpoints could
be allocated while still being cleaned up
from a previous release.
Remove explicit mutex locking in syncpt_release
as kref_put_mutex() handles this atomically. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()
During mpt3sas_transport_port_remove(), messages were logged with
dev_printk() against &mpt3sas_port->port->dev. At this point the SAS
transport device may already be partially unregistered or freed, leading
to a crash when accessing its struct device.
Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),
guaranteed to remain valid until driver removal.
[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI
[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)
[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024
[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70
[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff
[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206
[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32
[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845
[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8
[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000
[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30
[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000
[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0
[83428.295844] PKRU: 55555554
[83428.295846] Call Trace:
[83428.295848] <TASK>
[83428.295850] _dev_printk+0x5c/0x80
[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5
[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas]
[83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas]
[83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas]
[83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5
[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas]
[83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas]
[83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas]
[83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas]
[83428.295957] pci_device_remove+0x3b/0xb0
[83428.295962] device_release_driver_internal+0x193/0x200
[83428.295968] driver_detach+0x44/0x90
[83428.295971] bus_remove_driver+0x69/0xf0
[83428.295975] pci_unregister_driver+0x2a/0xb0
[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas]
[83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310
[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296000] ? __x64_sys_getdents64+0x9a/0x110
[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296009] ? syscall_trace_enter+0xf6/0x1b0
[83428.296014] do_syscall_64+0x7b/0x2c0
[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/qm - request reserved interrupt for virtual function
The device interrupt vector 3 is an error interrupt for
physical function and a reserved interrupt for virtual function.
However, the driver has not registered the reserved interrupt for
virtual function. When allocating interrupts, the number of interrupts
is allocated based on powers of two, which includes this interrupt.
When the system enables GICv4 and the virtual function passthrough
to the virtual machine, releasing the interrupt in the driver
triggers a warning.
The WARNING report is:
WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4
Therefore, register a reserved interrupt for VF and set the
IRQF_NO_AUTOEN flag to avoid that warning. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array()
The unpublished smatch static checker reported a warning.
drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array()
warn: potential user controlled sizeof overflow
'args->num_element * args->element_size' '1-u32max(user) * 1-u32max(user)'
Even this will not cause a real issue, it is better to put a reasonable
limitation for element_size and num_element. Add condition to make sure
the input element_size <= 4K and num_element <= 1K. |
| In the Linux kernel, the following vulnerability has been resolved:
media: iris: fix module removal if firmware download failed
Fix remove if firmware failed to load:
qcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2
qcom-iris aa00000.video-codec: firmware download failed
qcom-iris aa00000.video-codec: core init failed
then:
$ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind
Triggers:
genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow!
------------[ cut here ]------------
video_cc_mvs0_clk already disabled
WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542
<snip>
pc : clk_core_disable+0xa4/0xac
lr : clk_core_disable+0xa4/0xac
<snip>
Call trace:
clk_core_disable+0xa4/0xac (P)
clk_disable+0x30/0x4c
iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]
iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]
iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]
iris_vpu_power_off+0x34/0x84 [qcom_iris]
iris_core_deinit+0x44/0xc8 [qcom_iris]
iris_remove+0x20/0x48 [qcom_iris]
platform_remove+0x20/0x30
device_remove+0x4c/0x80
<snip>
---[ end trace 0000000000000000 ]---
------------[ cut here ]------------
video_cc_mvs0_clk already unprepared
WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542
<snip>
pc : clk_core_unprepare+0xf0/0x110
lr : clk_core_unprepare+0xf0/0x110
<snip>
Call trace:
clk_core_unprepare+0xf0/0x110 (P)
clk_unprepare+0x2c/0x44
iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]
iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]
iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]
iris_vpu_power_off+0x34/0x84 [qcom_iris]
iris_core_deinit+0x44/0xc8 [qcom_iris]
iris_remove+0x20/0x48 [qcom_iris]
platform_remove+0x20/0x30
device_remove+0x4c/0x80
<snip>
---[ end trace 0000000000000000 ]---
genpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow!
------------[ cut here ]------------
gcc_video_axi0_clk already disabled
WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542
<snip>
pc : clk_core_disable+0xa4/0xac
lr : clk_core_disable+0xa4/0xac
<snip>
Call trace:
clk_core_disable+0xa4/0xac (P)
clk_disable+0x30/0x4c
iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]
iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]
iris_vpu_power_off+0x48/0x84 [qcom_iris]
iris_core_deinit+0x44/0xc8 [qcom_iris]
iris_remove+0x20/0x48 [qcom_iris]
platform_remove+0x20/0x30
device_remove+0x4c/0x80
<snip>
------------[ cut here ]------------
gcc_video_axi0_clk already unprepared
WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542
<snip>
pc : clk_core_unprepare+0xf0/0x110
lr : clk_core_unprepare+0xf0/0x110
<snip>
Call trace:
clk_core_unprepare+0xf0/0x110 (P)
clk_unprepare+0x2c/0x44
iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]
iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]
iris_vpu_power_off+0x48/0x84 [qcom_iris]
iris_core_deinit+0x44/0xc8 [qcom_iris]
iris_remove+0x20/0x48 [qcom_iris]
platform_remove+0x20/0x30
device_remove+0x4c/0x80
<snip>
---[ end trace 0000000000000000 ]---
Skip deinit if initialization never succeeded. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential null deref in ext4_mb_init()
In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called
when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo
slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()
lacks null pointer checking, this leads to a null pointer dereference.
==================================================================
EXT4-fs: no memory for groupinfo slab cache
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0002 [#1] SMP PTI
CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)
RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40
Call Trace:
<TASK>
xa_destroy+0x61/0x130
ext4_mb_init+0x483/0x540
__ext4_fill_super+0x116d/0x17b0
ext4_fill_super+0xd3/0x280
get_tree_bdev_flags+0x132/0x1d0
vfs_get_tree+0x29/0xd0
do_new_mount+0x197/0x300
__x64_sys_mount+0x116/0x150
do_syscall_64+0x50/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
==================================================================
Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()
to prevent this issue. The same fix is also applied to
ext4_mb_largest_free_orders_destroy(). |
| In the Linux kernel, the following vulnerability has been resolved:
misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic
The dma_map_single() doesn't permit zero length mapping. It causes a follow
panic.
A panic was reported on arm64:
[ 60.137988] ------------[ cut here ]------------
[ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624!
[ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l
2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn
c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl
[ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237
[ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
[ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590
[ 60.213149] lr : swiotlb_map+0x88/0x1f0
[ 60.216982] sp : ffff80000a883bc0
[ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000
[ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0
[ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000
[ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000
[ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180
[ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000
[ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000
[ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001
[ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010
[ 60.291658] Call trace:
[ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590
[ 60.298629] swiotlb_map+0x88/0x1f0
[ 60.302115] dma_map_page_attrs+0x188/0x230
[ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]
[ 60.312660] __arm64_sys_ioctl+0xa8/0xf0
[ 60.316583] invoke_syscall+0x44/0x108
[ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0
[ 60.325038] do_el0_svc+0x2c/0xb8
[ 60.328351] el0_svc+0x2c/0x88
[ 60.331406] el0t_64_sync_handler+0xb8/0xc0
[ 60.335587] el0t_64_sync+0x18c/0x190
[ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)
[ 60.345344] ---[ end trace 0000000000000000 ]---
To fix it, this patch adds a checking the payload length if it is zero. |
| In the Linux kernel, the following vulnerability has been resolved:
media: usb: siano: Fix use after free bugs caused by do_submit_urb
There are UAF bugs caused by do_submit_urb(). One of the KASan reports
is shown below:
[ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890
[ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49
[ 36.408316]
[ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8
[ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[ 36.416157] Workqueue: 0x0 (events)
[ 36.417654] Call Trace:
[ 36.418546] <TASK>
[ 36.419320] dump_stack_lvl+0x96/0xd0
[ 36.420522] print_address_description+0x75/0x350
[ 36.421992] print_report+0x11b/0x250
[ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0
[ 36.424806] ? __virt_addr_valid+0xcf/0x170
[ 36.426069] ? worker_thread+0x4a2/0x890
[ 36.427355] kasan_report+0x131/0x160
[ 36.428556] ? worker_thread+0x4a2/0x890
[ 36.430053] worker_thread+0x4a2/0x890
[ 36.431297] ? worker_clr_flags+0x90/0x90
[ 36.432479] kthread+0x166/0x190
[ 36.433493] ? kthread_blkcg+0x50/0x50
[ 36.434669] ret_from_fork+0x22/0x30
[ 36.435923] </TASK>
[ 36.436684]
[ 36.437215] Allocated by task 24:
[ 36.438289] kasan_set_track+0x50/0x80
[ 36.439436] __kasan_kmalloc+0x89/0xa0
[ 36.440566] smsusb_probe+0x374/0xc90
[ 36.441920] usb_probe_interface+0x2d1/0x4c0
[ 36.443253] really_probe+0x1d5/0x580
[ 36.444539] __driver_probe_device+0xe3/0x130
[ 36.446085] driver_probe_device+0x49/0x220
[ 36.447423] __device_attach_driver+0x19e/0x1b0
[ 36.448931] bus_for_each_drv+0xcb/0x110
[ 36.450217] __device_attach+0x132/0x1f0
[ 36.451470] bus_probe_device+0x59/0xf0
[ 36.452563] device_add+0x4ec/0x7b0
[ 36.453830] usb_set_configuration+0xc63/0xe10
[ 36.455230] usb_generic_driver_probe+0x3b/0x80
[ 36.456166] printk: console [ttyGS0] disabled
[ 36.456569] usb_probe_device+0x90/0x110
[ 36.459523] really_probe+0x1d5/0x580
[ 36.461027] __driver_probe_device+0xe3/0x130
[ 36.462465] driver_probe_device+0x49/0x220
[ 36.463847] __device_attach_driver+0x19e/0x1b0
[ 36.465229] bus_for_each_drv+0xcb/0x110
[ 36.466466] __device_attach+0x132/0x1f0
[ 36.467799] bus_probe_device+0x59/0xf0
[ 36.469010] device_add+0x4ec/0x7b0
[ 36.470125] usb_new_device+0x863/0xa00
[ 36.471374] hub_event+0x18c7/0x2220
[ 36.472746] process_one_work+0x34c/0x5b0
[ 36.474041] worker_thread+0x4b7/0x890
[ 36.475216] kthread+0x166/0x190
[ 36.476267] ret_from_fork+0x22/0x30
[ 36.477447]
[ 36.478160] Freed by task 24:
[ 36.479239] kasan_set_track+0x50/0x80
[ 36.480512] kasan_save_free_info+0x2b/0x40
[ 36.481808] ____kasan_slab_free+0x122/0x1a0
[ 36.483173] __kmem_cache_free+0xc4/0x200
[ 36.484563] smsusb_term_device+0xcd/0xf0
[ 36.485896] smsusb_probe+0xc85/0xc90
[ 36.486976] usb_probe_interface+0x2d1/0x4c0
[ 36.488303] really_probe+0x1d5/0x580
[ 36.489498] __driver_probe_device+0xe3/0x130
[ 36.491140] driver_probe_device+0x49/0x220
[ 36.492475] __device_attach_driver+0x19e/0x1b0
[ 36.493988] bus_for_each_drv+0xcb/0x110
[ 36.495171] __device_attach+0x132/0x1f0
[ 36.496617] bus_probe_device+0x59/0xf0
[ 36.497875] device_add+0x4ec/0x7b0
[ 36.498972] usb_set_configuration+0xc63/0xe10
[ 36.500264] usb_generic_driver_probe+0x3b/0x80
[ 36.501740] usb_probe_device+0x90/0x110
[ 36.503084] really_probe+0x1d5/0x580
[ 36.504241] __driver_probe_device+0xe3/0x130
[ 36.505548] driver_probe_device+0x49/0x220
[ 36.506766] __device_attach_driver+0x19e/0x1b0
[ 36.508368] bus_for_each_drv+0xcb/0x110
[ 36.509646] __device_attach+0x132/0x1f0
[ 36.510911] bus_probe_device+0x59/0xf0
[ 36.512103] device_add+0x4ec/0x7b0
[ 36.513215] usb_new_device+0x863/0xa00
[ 36.514736] hub_event+0x18c7/0x2220
[ 36.516130] process_one_work+
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode
Currently, whenever there is a need to transmit an Action frame,
the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to
firmware. The P2P interfaces were available when wpa_supplicant is managing
the wlan interface.
However, the P2P interfaces are not created/initialized when only hostapd
is managing the wlan interface. And if hostapd receives an ANQP Query REQ
Action frame even from an un-associated STA, the brcmfmac driver tries
to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.
This NULL pointer dereferencing triggers a driver crash.
[ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000000
[...]
[ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[...]
[ 1417.075653] Call trace:
[ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]
[ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]
[ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]
[ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211]
[ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158
[ 1417.076302] genl_rcv_msg+0x220/0x2a0
[ 1417.076317] netlink_rcv_skb+0x68/0x140
[ 1417.076330] genl_rcv+0x40/0x60
[ 1417.076343] netlink_unicast+0x330/0x3b8
[ 1417.076357] netlink_sendmsg+0x19c/0x3f8
[ 1417.076370] __sock_sendmsg+0x64/0xc0
[ 1417.076391] ____sys_sendmsg+0x268/0x2a0
[ 1417.076408] ___sys_sendmsg+0xb8/0x118
[ 1417.076427] __sys_sendmsg+0x90/0xf8
[ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40
[ 1417.076465] invoke_syscall+0x50/0x120
[ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0
[ 1417.076506] do_el0_svc+0x24/0x38
[ 1417.076525] el0_svc+0x30/0x100
[ 1417.076548] el0t_64_sync_handler+0x100/0x130
[ 1417.076569] el0t_64_sync+0x190/0x198
[ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)
Fix this, by always using the vif corresponding to the wdev on which the
Action frame Transmission request was initiated by the userspace. This way,
even if P2P vif is not available, the IOVAR is sent to firmware on AP vif
and the ANQP Query RESP Action frame is transmitted without crashing the
driver.
Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()
to brcmf_p2p_attach(). Because the former function would not get executed
when only hostapd is managing wlan interface, and it is not safe to do
reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior
init_completion().
And in the brcmf_p2p_tx_action_frame() function, the condition check for
P2P Presence response frame is not needed, since the wpa_supplicant is
properly sending the P2P Presense Response frame on the P2P-GO vif instead
of the P2P-Device vif.
[Cc stable] |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fortify the spinlock against deadlock by interrupt
In the function ieee80211_tx_dequeue() there is a particular locking
sequence:
begin:
spin_lock(&local->queue_stop_reason_lock);
q_stopped = local->queue_stop_reasons[q];
spin_unlock(&local->queue_stop_reason_lock);
However small the chance (increased by ftracetest), an asynchronous
interrupt can occur in between of spin_lock() and spin_unlock(),
and the interrupt routine will attempt to lock the same
&local->queue_stop_reason_lock again.
This will cause a costly reset of the CPU and the wifi device or an
altogether hang in the single CPU and single core scenario.
The only remaining spin_lock(&local->queue_stop_reason_lock) that
did not disable interrupts was patched, which should prevent any
deadlocks on the same CPU/core and the same wifi device.
This is the probable trace of the deadlock:
kernel: ================================
kernel: WARNING: inconsistent lock state
kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W
kernel: --------------------------------
kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40
kernel: {IN-SOFTIRQ-W} state was registered at:
kernel: lock_acquire+0xc7/0x2d0
kernel: _raw_spin_lock+0x36/0x50
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]
kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]
kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]
kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]
kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]
kernel: dev_hard_start_xmit+0xb5/0x260
kernel: __dev_queue_xmit+0xdbe/0x1200
kernel: neigh_resolve_output+0x166/0x260
kernel: ip_finish_output2+0x216/0xb80
kernel: __ip_finish_output+0x2a4/0x4d0
kernel: ip_finish_output+0x2d/0xd0
kernel: ip_output+0x82/0x2b0
kernel: ip_local_out+0xec/0x110
kernel: igmpv3_sendpack+0x5c/0x90
kernel: igmp_ifc_timer_expire+0x26e/0x4e0
kernel: call_timer_fn+0xa5/0x230
kernel: run_timer_softirq+0x27f/0x550
kernel: __do_softirq+0xb4/0x3a4
kernel: irq_exit_rcu+0x9b/0xc0
kernel: sysvec_apic_timer_interrupt+0x80/0xa0
kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30
kernel: _raw_spin_unlock_irqrestore+0x3f/0x70
kernel: free_to_partial_list+0x3d6/0x590
kernel: __slab_free+0x1b7/0x310
kernel: kmem_cache_free+0x52d/0x550
kernel: putname+0x5d/0x70
kernel: do_sys_openat2+0x1d7/0x310
kernel: do_sys_open+0x51/0x80
kernel: __x64_sys_openat+0x24/0x30
kernel: do_syscall_64+0x5c/0x90
kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc
kernel: irq event stamp: 5120729
kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120
kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120
kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel:
other info that might help us debug this:
kernel: Possible unsafe locking scenario:
kernel: CPU0
kernel: ----
kernel: lock(&local->queue_stop_reason_lock);
kernel: <Interrupt>
kernel: lock(&local->queue_stop_reason_lock);
kernel:
*** DEADLOCK ***
kernel: 8 locks held by kworker/5:0/25656:
kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530
kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530
kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #3: ffff9d619
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_bcm7271: fix leak in `brcmuart_probe`
Smatch reports:
drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() warn:
'baud_mux_clk' from clk_prepare_enable() not released on lines: 1032.
The issue is fixed by using a managed clock. |
| In the Linux kernel, the following vulnerability has been resolved:
MIPS: KVM: Fix NULL pointer dereference
After commit 45c7e8af4a5e3f0bea4ac209 ("MIPS: Remove KVM_TE support") we
get a NULL pointer dereference when creating a KVM guest:
[ 146.243409] Starting KVM with MIPS VZ extensions
[ 149.849151] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000300, epc == ffffffffc06356ec, ra == ffffffffc063568c
[ 149.849177] Oops[#1]:
[ 149.849182] CPU: 3 PID: 2265 Comm: qemu-system-mip Not tainted 6.4.0-rc3+ #1671
[ 149.849188] Hardware name: THTF CX TL630 Series/THTF-LS3A4000-7A1000-ML4A, BIOS KL4.1F.TF.D.166.201225.R 12/25/2020
[ 149.849192] $ 0 : 0000000000000000 000000007400cce0 0000000000400004 ffffffff8119c740
[ 149.849209] $ 4 : 000000007400cce1 000000007400cce1 0000000000000000 0000000000000000
[ 149.849221] $ 8 : 000000240058bb36 ffffffff81421ac0 0000000000000000 0000000000400dc0
[ 149.849233] $12 : 9800000102a07cc8 ffffffff80e40e38 0000000000000001 0000000000400dc0
[ 149.849245] $16 : 0000000000000000 9800000106cd0000 9800000106cd0000 9800000100cce000
[ 149.849257] $20 : ffffffffc0632b28 ffffffffc05b31b0 9800000100ccca00 0000000000400000
[ 149.849269] $24 : 9800000106cd09ce ffffffff802f69d0
[ 149.849281] $28 : 9800000102a04000 9800000102a07cd0 98000001106a8000 ffffffffc063568c
[ 149.849293] Hi : 00000335b2111e66
[ 149.849295] Lo : 6668d90061ae0ae9
[ 149.849298] epc : ffffffffc06356ec kvm_vz_vcpu_setup+0xc4/0x328 [kvm]
[ 149.849324] ra : ffffffffc063568c kvm_vz_vcpu_setup+0x64/0x328 [kvm]
[ 149.849336] Status: 7400cce3 KX SX UX KERNEL EXL IE
[ 149.849351] Cause : 1000000c (ExcCode 03)
[ 149.849354] BadVA : 0000000000000300
[ 149.849357] PrId : 0014c004 (ICT Loongson-3)
[ 149.849360] Modules linked in: kvm nfnetlink_queue nfnetlink_log nfnetlink fuse sha256_generic libsha256 cfg80211 rfkill binfmt_misc vfat fat snd_hda_codec_hdmi input_leds led_class snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_pcm snd_timer snd serio_raw xhci_pci radeon drm_suballoc_helper drm_display_helper xhci_hcd ip_tables x_tables
[ 149.849432] Process qemu-system-mip (pid: 2265, threadinfo=00000000ae2982d2, task=0000000038e09ad4, tls=000000ffeba16030)
[ 149.849439] Stack : 9800000000000003 9800000100ccca00 9800000100ccc000 ffffffffc062cef4
[ 149.849453] 9800000102a07d18 c89b63a7ab338e00 0000000000000000 ffffffff811a0000
[ 149.849465] 0000000000000000 9800000106cd0000 ffffffff80e59938 98000001106a8920
[ 149.849476] ffffffff80e57f30 ffffffffc062854c ffffffff811a0000 9800000102bf4240
[ 149.849488] ffffffffc05b0000 ffffffff80e3a798 000000ff78000000 000000ff78000010
[ 149.849500] 0000000000000255 98000001021f7de0 98000001023f0078 ffffffff81434000
[ 149.849511] 0000000000000000 0000000000000000 9800000102ae0000 980000025e92ae28
[ 149.849523] 0000000000000000 c89b63a7ab338e00 0000000000000001 ffffffff8119dce0
[ 149.849535] 000000ff78000010 ffffffff804f3d3c 9800000102a07eb0 0000000000000255
[ 149.849546] 0000000000000000 ffffffff8049460c 000000ff78000010 0000000000000255
[ 149.849558] ...
[ 149.849565] Call Trace:
[ 149.849567] [<ffffffffc06356ec>] kvm_vz_vcpu_setup+0xc4/0x328 [kvm]
[ 149.849586] [<ffffffffc062cef4>] kvm_arch_vcpu_create+0x184/0x228 [kvm]
[ 149.849605] [<ffffffffc062854c>] kvm_vm_ioctl+0x64c/0xf28 [kvm]
[ 149.849623] [<ffffffff805209c0>] sys_ioctl+0xc8/0x118
[ 149.849631] [<ffffffff80219eb0>] syscall_common+0x34/0x58
The root cause is the deletion of kvm_mips_commpage_init() leaves vcpu
->arch.cop0 NULL. So fix it by making cop0 from a pointer to an embedded
object. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr: do not repeat pte_offset_map_lock() until success
DAMON's virtual address space operation set implementation (vaddr) calls
pte_offset_map_lock() inside the page table walk callback function. This
is for reading and writing page table accessed bits. If
pte_offset_map_lock() fails, it retries by returning the page table walk
callback function with ACTION_AGAIN.
pte_offset_map_lock() can continuously fail if the target is a pmd
migration entry, though. Hence it could cause an infinite page table walk
if the migration cannot be done until the page table walk is finished.
This indeed caused a soft lockup when CPU hotplugging and DAMON were
running in parallel.
Avoid the infinite loop by simply not retrying the page table walk. DAMON
is promising only a best-effort accuracy, so missing access to such pages
is no problem. |
| In the Linux kernel, the following vulnerability has been resolved:
cpufreq/longhaul: handle NULL policy in longhaul_exit
longhaul_exit() was calling cpufreq_cpu_get(0) without checking
for a NULL policy pointer. On some systems, this could lead to a
NULL dereference and a kernel warning or panic.
This patch adds a check using unlikely() and returns early if the
policy is NULL.
Bugzilla: #219962 |
| In the Linux kernel, the following vulnerability has been resolved:
media: pci: mg4b: fix uninitialized iio scan data
Fix potential leak of uninitialized stack data to userspace by ensuring
that the `scan` structure is zeroed before use. |
| Integer overflow or wraparound in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| In the Linux kernel, the following vulnerability has been resolved:
most: usb: Fix use-after-free in hdm_disconnect
hdm_disconnect() calls most_deregister_interface(), which eventually
unregisters the MOST interface device with device_unregister(iface->dev).
If that drops the last reference, the device core may call release_mdev()
immediately while hdm_disconnect() is still executing.
The old code also freed several mdev-owned allocations in
hdm_disconnect() and then performed additional put_device() calls.
Depending on refcount order, this could lead to use-after-free or
double-free when release_mdev() ran (or when unregister paths also
performed puts).
Fix by moving the frees of mdev-owned allocations into release_mdev(),
so they happen exactly once when the device is truly released, and by
dropping the extra put_device() calls in hdm_disconnect() that are
redundant after device_unregister() and most_deregister_interface().
This addresses the KASAN slab-use-after-free reported by syzbot in
hdm_disconnect(). See report and stack traces in the bug link below. |
