Skip to content

[LTS 8.8] arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array - #251

Merged
PlaidCat merged 1 commit into
ctrliq:ciqlts8_8from
pvts-mat:ciqlts8_8-CVE-2025-21785
May 8, 2025
Merged

[LTS 8.8] arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array#251
PlaidCat merged 1 commit into
ctrliq:ciqlts8_8from
pvts-mat:ciqlts8_8-CVE-2025-21785

Conversation

@pvts-mat

@pvts-matpvts-mat commented May 7, 2025

Copy link
Copy Markdown
Contributor

[LTS 8.8]
CVE-2025-21785
VULN-54126

Problem

https://www.cve.org/CVERecord?id=CVE-2025-21785

In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).

Solution

The official fix in the mainline kernel is provided in the 875d742 commit

arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds
check on the array size but does not account for cache levels with
separate data/instructions cache. Fix this by incrementing the index
for any populated leaf (instead of any populated level).

kABI check: passed

DEBUG=1 RELAXED_DEPS=1 CVE=CVE-2025-21785 ./ninja.sh _kabi_checked__aarch64--test--ciqlts8_8-CVE-2025-21785
[0/1] Check ABI of kernel [ciqlts8_8-CVE-2025-21785]
++ uname -m
+ python3 /home/pvts/ctrliq-github/kernel-dist-git-el-8.8/SOURCES/check-kabi -k /home/pvts/ctrliq-github/kernel-dist-git-el-8.8/SOURCES/Module.kabi_aarch64 -s vms/aarch64--build--ciqlts8_8/build_files/kernel-src-tree-ciqlts8_8-CVE-2025-21785/Module.symvers
kABI check passed
+ touch state/kernels/ciqlts8_8-CVE-2025-21785/aarch64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Methodology

The tests were run using the rocky-patching framework (qemu-kvm virtualization of Rocky base cloud aarch64 images) ported to the local WHLE-LS1046A machine, based on the NXP Layerscape LS1046A arm64 processor.

The selftests were source-compiled from the recent ciqlts8_8 branch (commit f10433c).

The tests were run using an explicit list of tests to run which omitted certain tests known to give inconsistent results. Details in https://gitlab.conclusive.pl/devices/rocky-patching/-/blob/master/src/run-kselftests.sh?ref_type=heads

Coverage

android, bpf (except test_progs, test_progs-no_alu32, test_xsk.sh, test_kmod.sh, test_sockmap), breakpoints, capabilities, cgroup, core, cpu-hotplug, cpufreq, drivers/net/bonding, drivers/net/team, efivarfs, exec, firmware, fpu, ftrace, futex, gpio, intel_pstate, ipc, kcmp, kvm, lib, livepatch, membarrier, memfd, memory-hotplug, mount, mqueue, net/forwarding (except sch_tbf_ets.sh, sch_ets.sh, sch_tbf_prio.sh, ipip_hier_gre_keys.sh, sch_tbf_root.sh, tc_actions.sh), net/mptcp (except simult_flows.sh), net (except gro.sh, xfrm_policy.sh, ip_defrag.sh, reuseport_addr_any.sh, txtimestamp.sh, reuseaddr_conflict, udpgso_bench.sh), netfilter (except nft_trans_stress.sh), nsfs, proc, pstore, ptrace, rseq (except basic_test, basic_percpu_ops_test, param_test_compare_twice, param_test_benchmark, param_test), sgx, sigaltstack, size, splice, static_keys, sync, sysctl, tc-testing, tdx, timens, timers (except raw_skew), tpm2, user, vm, zram.

Reference

kselftests–mix–ciqlts8_8–run1.log
kselftests–mix–ciqlts8_8–run2.log
kselftests–mix–ciqlts8_8–run3.log
kselftests–mix–ciqlts8_8–run4.log
kselftests–mix–ciqlts8_8–run5.log

Patch

kselftests–mix–ciqlts8_8-CVE-2025-21785–run1.log
kselftests–mix–ciqlts8_8-CVE-2025-21785–run2.log

Comparison

All test results are the same.

ktests.xsh diff -d kselftests-*.log
Column File
-------- ---------------------------------------------------
Status0 kselftests--mix--ciqlts8_8--run1.log
Status1 kselftests--mix--ciqlts8_8--run2.log
Status2 kselftests--mix--ciqlts8_8--run3.log
Status3 kselftests--mix--ciqlts8_8--run4.log
Status4 kselftests--mix--ciqlts8_8--run5.log
Status5 kselftests--mix--ciqlts8_8-CVE-2025-21785--run1.log
Status6 kselftests--mix--ciqlts8_8-CVE-2025-21785--run2.log

Specific tests: skipped

To be done on demand

@pvts-mat
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
93441b7
jira VULN-54126
cve CVE-2025-21785
commit-author Radu Rendec <rrendec@redhat.com>
commit 875d742
The loop that detects/populates cache information already has a bounds
check on the array size but does not account for cache levels with
separate data/instructions cache. Fix this by incrementing the index
for any populated leaf (instead of any populated level).
Fixes: 5d425c1 ("arm64: kernel: add support for cpu cache information")
Signed-off-by: Radu Rendec <rrendec@redhat.com>
Link: https://lore.kernel.org/r/20250206174420.2178724-1-rrendec@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 875d742)
Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
thefossguy-ciq
thefossguy-ciq approved these changes May 8, 2025
View reviewed changes

@thefossguy-ciqthefossguy-ciq left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚤

bmastbergen
bmastbergen approved these changes May 8, 2025
View reviewed changes

@bmastbergenbmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@PlaidCat
PlaidCat merged commit bfd2f51 into ctrliq:ciqlts8_8May 8, 2025
bmastbergen pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Aug 29, 2025
@PlaidCat
selftests/bpf: Add mprog API tests for BPF tcx opts
78b9f42
jira LE-1907
Rebuild_History Non-Buildable kernel-5.14.0-427.18.1.el9_4
commit-author Daniel Borkmann <daniel@iogearbox.net>
commit cd13c91
Add a big batch of test coverage to assert all aspects of the tcx opts
attach, detach and query API:
# ./vmtest.sh -- ./test_progs -t tc_opts
[...]
ctrliq#238 tc_opts_after:OK
ctrliq#239 tc_opts_append:OK
ctrliq#240 tc_opts_basic:OK
ctrliq#241 tc_opts_before:OK
ctrliq#242 tc_opts_chain_classic:OK
ctrliq#243 tc_opts_demixed:OK
ctrliq#244 tc_opts_detach:OK
ctrliq#245 tc_opts_detach_after:OK
ctrliq#246 tc_opts_detach_before:OK
ctrliq#247 tc_opts_dev_cleanup:OK
ctrliq#248 tc_opts_invalid:OK
ctrliq#249 tc_opts_mixed:OK
ctrliq#250 tc_opts_prepend:OK
ctrliq#251 tc_opts_replace:OK
ctrliq#252 tc_opts_revision:OK
Summary: 15/0 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20230719140858.13224-8-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
(cherry picked from commit cd13c91)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
bmastbergen pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Aug 29, 2025
@PlaidCat
selftests/bpf: Add test for detachment on empty mprog entry
c21ca44
jira LE-1907
Rebuild_History Non-Buildable kernel-5.14.0-427.18.1.el9_4
commit-author Daniel Borkmann <daniel@iogearbox.net>
commit 21ce6ab
Add a detachment test case with miniq present to assert that with and
without the miniq we get the same error.
# ./test_progs -t tc_opts
ctrliq#244 tc_opts_after:OK
ctrliq#245 tc_opts_append:OK
ctrliq#246 tc_opts_basic:OK
ctrliq#247 tc_opts_before:OK
ctrliq#248 tc_opts_chain_classic:OK
ctrliq#249 tc_opts_delete_empty:OK
ctrliq#250 tc_opts_demixed:OK
ctrliq#251 tc_opts_detach:OK
ctrliq#252 tc_opts_detach_after:OK
ctrliq#253 tc_opts_detach_before:OK
ctrliq#254 tc_opts_dev_cleanup:OK
ctrliq#255 tc_opts_invalid:OK
ctrliq#256 tc_opts_mixed:OK
ctrliq#257 tc_opts_prepend:OK
ctrliq#258 tc_opts_replace:OK
ctrliq#259 tc_opts_revision:OK
Summary: 16/0 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20230804131112.11012-2-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
(cherry picked from commit 21ce6ab)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
bmastbergen pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Aug 29, 2025
@PlaidCat
selftests/bpf: Add various more tcx test cases
1bd1f2d
jira LE-1907
Rebuild_History Non-Buildable kernel-5.14.0-427.18.1.el9_4
commit-author Daniel Borkmann <daniel@iogearbox.net>
commit ccd9a8b
Add several new tcx test cases to improve test coverage. This also includes
a few new tests with ingress instead of clsact qdisc, to cover the fix from
commit dc644b5 ("tcx: Fix splat in ingress_destroy upon tcx_entry_free").
# ./test_progs -t tc
[...]
ctrliq#234 tc_links_after:OK
ctrliq#235 tc_links_append:OK
ctrliq#236 tc_links_basic:OK
ctrliq#237 tc_links_before:OK
ctrliq#238 tc_links_chain_classic:OK
ctrliq#239 tc_links_chain_mixed:OK
ctrliq#240 tc_links_dev_cleanup:OK
ctrliq#241 tc_links_dev_mixed:OK
ctrliq#242 tc_links_ingress:OK
ctrliq#243 tc_links_invalid:OK
ctrliq#244 tc_links_prepend:OK
ctrliq#245 tc_links_replace:OK
ctrliq#246 tc_links_revision:OK
ctrliq#247 tc_opts_after:OK
ctrliq#248 tc_opts_append:OK
ctrliq#249 tc_opts_basic:OK
ctrliq#250 tc_opts_before:OK
ctrliq#251 tc_opts_chain_classic:OK
ctrliq#252 tc_opts_chain_mixed:OK
ctrliq#253 tc_opts_delete_empty:OK
ctrliq#254 tc_opts_demixed:OK
ctrliq#255 tc_opts_detach:OK
ctrliq#256 tc_opts_detach_after:OK
ctrliq#257 tc_opts_detach_before:OK
ctrliq#258 tc_opts_dev_cleanup:OK
ctrliq#259 tc_opts_invalid:OK
ctrliq#260 tc_opts_mixed:OK
ctrliq#261 tc_opts_prepend:OK
ctrliq#262 tc_opts_replace:OK
ctrliq#263 tc_opts_revision:OK
[...]
Summary: 44/38 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/8699efc284b75ccdc51ddf7062fa2370330dc6c0.1692029283.git.daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
(cherry picked from commit ccd9a8b)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
github-actionsBot pushed a commit that referenced this pull request Oct 13, 2025
@pchelkin91@gregkh
wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
895cccf
[ Upstream commit 3e31a6b ]
There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to
access already freed skb_data:
BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
Use-after-free write at 0x0000000020309d9d (in kfence-#251):
rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache
allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):
__alloc_skb net/core/skbuff.c:659
__netdev_alloc_skb net/core/skbuff.c:734
ieee80211_nullfunc_get net/mac80211/tx.c:5844
rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):
ieee80211_tx_status_skb net/mac80211/status.c:1117
rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564
rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651
rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676
rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238
__napi_poll net/core/dev.c:7495
net_rx_action net/core/dev.c:7557 net/core/dev.c:7684
handle_softirqs kernel/softirq.c:580
do_softirq.part.0 kernel/softirq.c:480
__local_bh_enable_ip kernel/softirq.c:407
rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927
irq_thread_fn kernel/irq/manage.c:1133
irq_thread kernel/irq/manage.c:1257
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
It is a consequence of a race between the waiting and the signaling side
of the completion:
Waiting thread Completing thread
rtw89_core_tx_kick_off_and_wait()
rcu_assign_pointer(skb_data->wait, wait)
/* start waiting */
wait_for_completion_timeout()
rtw89_pci_tx_status()
rtw89_core_tx_wait_complete()
rcu_read_lock()
/* signals completion and
* proceeds further
*/
complete(&wait->completion)
rcu_read_unlock()
...
/* frees skb_data */
ieee80211_tx_status_ni()
/* returns (exit status doesn't matter) */
wait_for_completion_timeout()
...
/* accesses the already freed skb_data */
rcu_assign_pointer(skb_data->wait, NULL)
The completing side might proceed and free the underlying skb even before
the waiting side is fully awoken and run to execution. Actually the race
happens regardless of wait_for_completion_timeout() exit status, e.g.
the waiting side may hit a timeout and the concurrent completing side is
still able to free the skb.
Skbs which are sent by rtw89_core_tx_kick_off_and_wait() are owned by the
driver. They don't come from core ieee80211 stack so no need to pass them
to ieee80211_tx_status_ni() on completing side.
Introduce a work function which will act as a garbage collector for
rtw89_tx_wait_info objects and the associated skbs. Thus no potentially
heavy locks are required on the completing side.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 1ae5ca6 ("wifi: rtw89: add function to wait for completion of TX skbs")
Cc: stable@vger.kernel.org
Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250919210852.823912-2-pchelkin@ispras.ru
[ added wiphy variable declarations ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
github-actionsBot pushed a commit that referenced this pull request Dec 3, 2025
@jtornosm
wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
0373512
JIRA: https://issues.redhat.com/browse/RHEL-114889
commit 3e31a6b
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date: Sat Sep 20 00:08:47 2025 +0300
wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to
access already freed skb_data:
BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
Use-after-free write at 0x0000000020309d9d (in kfence-#251):
rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache
allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):
__alloc_skb net/core/skbuff.c:659
__netdev_alloc_skb net/core/skbuff.c:734
ieee80211_nullfunc_get net/mac80211/tx.c:5844
rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):
ieee80211_tx_status_skb net/mac80211/status.c:1117
rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564
rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651
rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676
rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238
__napi_poll net/core/dev.c:7495
net_rx_action net/core/dev.c:7557 net/core/dev.c:7684
handle_softirqs kernel/softirq.c:580
do_softirq.part.0 kernel/softirq.c:480
__local_bh_enable_ip kernel/softirq.c:407
rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927
irq_thread_fn kernel/irq/manage.c:1133
irq_thread kernel/irq/manage.c:1257
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
It is a consequence of a race between the waiting and the signaling side
of the completion:
Waiting thread Completing thread
rtw89_core_tx_kick_off_and_wait()
rcu_assign_pointer(skb_data->wait, wait)
/* start waiting */
wait_for_completion_timeout()
rtw89_pci_tx_status()
rtw89_core_tx_wait_complete()
rcu_read_lock()
/* signals completion and
* proceeds further
*/
complete(&wait->completion)
rcu_read_unlock()
...
/* frees skb_data */
ieee80211_tx_status_ni()
/* returns (exit status doesn't matter) */
wait_for_completion_timeout()
...
/* accesses the already freed skb_data */
rcu_assign_pointer(skb_data->wait, NULL)
The completing side might proceed and free the underlying skb even before
the waiting side is fully awoken and run to execution. Actually the race
happens regardless of wait_for_completion_timeout() exit status, e.g.
the waiting side may hit a timeout and the concurrent completing side is
still able to free the skb.
Skbs which are sent by rtw89_core_tx_kick_off_and_wait() are owned by the
driver. They don't come from core ieee80211 stack so no need to pass them
to ieee80211_tx_status_ni() on completing side.
Introduce a work function which will act as a garbage collector for
rtw89_tx_wait_info objects and the associated skbs. Thus no potentially
heavy locks are required on the completing side.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 1ae5ca6 ("wifi: rtw89: add function to wait for completion of TX skbs")
Cc: stable@vger.kernel.org
Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250919210852.823912-2-pchelkin@ispras.ru
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
github-actionsBot pushed a commit that referenced this pull request Dec 17, 2025
@jtornosm
wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
456810f
JIRA: https://issues.redhat.com/browse/RHEL-114891
commit 3e31a6b
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date: Sat Sep 20 00:08:47 2025 +0300
wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()
There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to
access already freed skb_data:
BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
Use-after-free write at 0x0000000020309d9d (in kfence-#251):
rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache
allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):
__alloc_skb net/core/skbuff.c:659
__netdev_alloc_skb net/core/skbuff.c:734
ieee80211_nullfunc_get net/mac80211/tx.c:5844
rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431
rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194
rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
process_one_work kernel/workqueue.c:3241
worker_thread kernel/workqueue.c:3400
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):
ieee80211_tx_status_skb net/mac80211/status.c:1117
rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564
rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651
rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676
rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238
__napi_poll net/core/dev.c:7495
net_rx_action net/core/dev.c:7557 net/core/dev.c:7684
handle_softirqs kernel/softirq.c:580
do_softirq.part.0 kernel/softirq.c:480
__local_bh_enable_ip kernel/softirq.c:407
rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927
irq_thread_fn kernel/irq/manage.c:1133
irq_thread kernel/irq/manage.c:1257
kthread kernel/kthread.c:463
ret_from_fork arch/x86/kernel/process.c:154
ret_from_fork_asm arch/x86/entry/entry_64.S:258
It is a consequence of a race between the waiting and the signaling side
of the completion:
Waiting thread Completing thread
rtw89_core_tx_kick_off_and_wait()
rcu_assign_pointer(skb_data->wait, wait)
/* start waiting */
wait_for_completion_timeout()
rtw89_pci_tx_status()
rtw89_core_tx_wait_complete()
rcu_read_lock()
/* signals completion and
* proceeds further
*/
complete(&wait->completion)
rcu_read_unlock()
...
/* frees skb_data */
ieee80211_tx_status_ni()
/* returns (exit status doesn't matter) */
wait_for_completion_timeout()
...
/* accesses the already freed skb_data */
rcu_assign_pointer(skb_data->wait, NULL)
The completing side might proceed and free the underlying skb even before
the waiting side is fully awoken and run to execution. Actually the race
happens regardless of wait_for_completion_timeout() exit status, e.g.
the waiting side may hit a timeout and the concurrent completing side is
still able to free the skb.
Skbs which are sent by rtw89_core_tx_kick_off_and_wait() are owned by the
driver. They don't come from core ieee80211 stack so no need to pass them
to ieee80211_tx_status_ni() on completing side.
Introduce a work function which will act as a garbage collector for
rtw89_tx_wait_info objects and the associated skbs. Thus no potentially
heavy locks are required on the completing side.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 1ae5ca6 ("wifi: rtw89: add function to wait for completion of TX skbs")
Cc: stable@vger.kernel.org
Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250919210852.823912-2-pchelkin@ispras.ru
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
github-actionsBot pushed a commit that referenced this pull request May 29, 2026
@mrpreFlorian Westphal
netfilter: nft_fib_ipv6: handle routes via external nexthop
f81b0c2
fib6_info has a union:
union {
struct list_head fib6_siblings;
struct list_head nh_list;
};
Old-style multipath (ip -6 route add ... nexthop ... nexthop ...) uses
fib6_siblings. External nexthop (ip -6 route add ... nhid N) uses
nh_list, linked into &nh->f6i_list.
nft_fib6_info_nh_uses_dev() blindly walks &rt->fib6_siblings, causing
an OOB read past the struct nexthop slab when rt->nh is set:
==================================================================
BUG: KASAN: slab-out-of-bounds in nft_fib6_eval+0x1362/0x16c0
Read of size 8 at addr ffff888103a099d0 by task ping/386
CPU: 2 UID: 0 PID: 386 Comm: ping Not tainted 7.1.0-rc3+ #251 PREEMPT
Call Trace:
<IRQ>
dump_stack_lvl+0x76/0xa0
print_report+0xd1/0x5f0
kasan_report+0xe7/0x130
__asan_report_load8_noabort+0x14/0x30
nft_fib6_eval+0x1362/0x16c0
nft_do_chain+0x279/0x18c0
nft_do_chain_ipv6+0x1a8/0x230
nf_hook_slow+0xad/0x200
ipv6_rcv+0x152/0x380
__netif_receive_skb_one_core+0x118/0x1c0
==================================================================
Branch by route shape: when rt->nh is set, walk via
nexthop_for_each_fib6_nh() (also covers nh groups, which the original
code missed); otherwise walk fib6_siblings, guarded by READ_ONCE() of
rt->fib6_nsiblings as required by commit 31d7d67 ("ipv6: annotate
data-races around rt->fib6_nsiblings").
Fixes: 1c32b24 ("netfilter: nft_fib_ipv6: switch to fib6_lookup")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Florian Westphal <fw@strlen.de>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bmastbergenbmastbergenbmastbergen approved these changes
@thefossguy-ciqthefossguy-ciqthefossguy-ciq approved these changes
@kerneltoastkerneltoastAwaiting requested review from kerneltoast
@PlaidCatPlaidCatAwaiting requested review from PlaidCat

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@pvts-mat@bmastbergen@thefossguy-ciq@PlaidCat