CVE-2024-35938

wifi: ath11k: decrease MHI channel buffer length to 8KB

published May 19, 2024

CVSS
—
EPSS
0%
Percentile
10.9
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: decrease MHI channel buffer length to 8KB

Currently buf_len field of ath11k_mhi_config_qca6390 is assigned

with 0, making MHI use a default size, 64KB, to allocate channel

buffers. This is likely to fail in some scenarios where system

memory is highly fragmented and memory compaction or reclaim is

not allowed.

There is a fail report which is caused by it:

kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0

CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb

Workqueue: events_unbound async_run_entry_fn

Call Trace:

<TASK>

dump_stack_lvl+0x47/0x60

warn_alloc+0x13a/0x1b0

? srso_alias_return_thunk+0x5/0xfbef5

? __alloc_pages_direct_compact+0xab/0x210

__alloc_pages_slowpath.constprop.0+0xd3e/0xda0

__alloc_pages+0x32d/0x350

? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

__kmalloc_large_node+0x72/0x110

__kmalloc+0x37c/0x480

? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

__mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]

device_for_each_child+0x5c/0xa0

? __pfx_pci_pm_resume+0x10/0x10

ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]

? srso_alias_return_thunk+0x5/0xfbef5

ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]

? srso_alias_return_thunk+0x5/0xfbef5

dpm_run_callback+0x8c/0x1e0

device_resume+0x104/0x340

? __pfx_dpm_watchdog_handler+0x10/0x10

async_resume+0x1d/0x30

async_run_entry_fn+0x32/0x120

process_one_work+0x168/0x330

worker_thread+0x2f5/0x410

? __pfx_worker_thread+0x10/0x10

kthread+0xe8/0x120

? __pfx_kthread+0x10/0x10

ret_from_fork+0x34/0x50

? __pfx_kthread+0x10/0x10

ret_from_fork_asm+0x1b/0x30

</TASK>

Actually those buffers are used only by QMI target -> host communication.

And for WCN6855 and QCA6390, the largest packet size for that is less

than 6KB. So change buf_len field to 8KB, which results in order 1

allocation if page size is 4KB. In this way, we can at least save some

memory, and as well as decrease the possibility of allocation failure

in those scenarios.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00211 · 10.9th percentile
Published
2024-05-19T10:10Z
EPSS history
Timeline
  • 19 MAY 10:10Z
    wifi: ath11k: decrease MHI channel buffer length to 8KB
    cvelistv5