* UBSAN array-index-out-of-bounds in ath5k driver
@ 2025-11-01 14:09 Salvatore Bonaccorso
2025-11-03 7:00 ` Jiri Slaby
0 siblings, 1 reply; 4+ messages in thread
From: Salvatore Bonaccorso @ 2025-11-01 14:09 UTC (permalink / raw)
To: Jiri Slaby, Nick Kossifidis, Luis Chamberlain
Cc: linux-wireless, linux-kernel, Vincent Danjean, 1119093
Hi
In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported
the following:
> Hi,
>
> The ath5k driver seems to do an array-index-out-of-bounds access
> as shown by the UBSAN kernel message.
> [ 17.954484] ------------[ cut here ]------------
> [ 17.954487] UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.16.3/drivers/net/wireless/ath/ath5k/base.c:1741:20
> [ 17.955289] index 4 is out of range for type 'ieee80211_tx_rate [4]'
> [ 17.956134] CPU: 1 UID: 0 PID: 1745 Comm: 16 Not tainted 6.16.3+deb13-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1~bpo13+1
> [ 17.956137] Hardware name: Gigabyte Technology Co., Ltd. H67A-UD3H-B3/H67A-UD3H-B3, BIOS F8 03/27/2012
> [ 17.956139] Call Trace:
> [ 17.956142] <TASK>
> [ 17.956145] dump_stack_lvl+0x5d/0x80
> [ 17.956154] ubsan_epilogue+0x5/0x2b
> [ 17.956158] __ubsan_handle_out_of_bounds.cold+0x46/0x4b
> [ 17.956162] ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
> [ 17.956173] tasklet_action_common+0xb5/0x1c0
> [ 17.956178] handle_softirqs+0xdf/0x320
> [ 17.956181] __irq_exit_rcu+0xbc/0xe0
> [ 17.956184] common_interrupt+0x47/0xa0
> [ 17.956188] asm_common_interrupt+0x26/0x40
> [ 17.956191] RIP: 0033:0x7f4fa439067d
> [ 17.956204] Code: 0f b6 14 16 45 85 c0 74 01 92 29 d0 c3 48 8d 3c 07 48 8d 34 0e 45 85 c0 74 03 48 87 f7 48 0f bc d2 49 29 d3 76 0b 0f b6 0c 16 <0f> b6 04 17 29 c8 c3 31 c0 c3 66 0f 1f 84 00 00 00 00 00 0f b6 0e
> [ 17.956206] RSP: 002b:00007ffd8cc32f08 EFLAGS: 00000212
> [ 17.956209] RAX: 0000000000000020 RBX: 0000556dfab414a0 RCX: 0000000000000070
> [ 17.956210] RDX: 000000000000000d RSI: 00007f4fa4b7a05f RDI: 0000556dfab414a0
> [ 17.956211] RBP: 00007f4fa4b7a05f R08: 0000000000000400 R09: 0000000000000008
> [ 17.956213] R10: fffffffffffff4b8 R11: 000000000000000e R12: 000000000000001b
> [ 17.956214] R13: 0000556dfab412c0 R14: 00007ffd8cc32f80 R15: 00007f4fa4b79eaf
> [ 17.956217] </TASK>
> [ 17.956217] ---[ end trace ]---
>
> It occurs once at each boot.
> According to
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/master/drivers/net/wireless/ath/ath5k/base.c
> the line of code has not changed for about 15 years.
> And I'm using this driver for more than 10 years.
> So, the array-index-out-of-bounds does not seem to
> have hard consequences for now (by luck?)
>
> Regards,
> Vincent
Does that ring any bell?
Regards,
Salvatore
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBSAN array-index-out-of-bounds in ath5k driver
2025-11-01 14:09 UBSAN array-index-out-of-bounds in ath5k driver Salvatore Bonaccorso
@ 2025-11-03 7:00 ` Jiri Slaby
2025-11-03 7:04 ` Jiri Slaby
0 siblings, 1 reply; 4+ messages in thread
From: Jiri Slaby @ 2025-11-03 7:00 UTC (permalink / raw)
To: Salvatore Bonaccorso, Nick Kossifidis, Luis Chamberlain
Cc: linux-wireless, linux-kernel, Vincent Danjean, 1119093
Hi,
On 01. 11. 25, 15:09, Salvatore Bonaccorso wrote:
> In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported
> the following:
>> The ath5k driver seems to do an array-index-out-of-bounds access
>> as shown by the UBSAN kernel message.
>> [ 17.954484] ------------[ cut here ]------------
>> [ 17.954487] UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.16.3/drivers/net/wireless/ath/ath5k/base.c:1741:20
>> [ 17.955289] index 4 is out of range for type 'ieee80211_tx_rate [4]'
>> [ 17.956134] CPU: 1 UID: 0 PID: 1745 Comm: 16 Not tainted 6.16.3+deb13-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1~bpo13+1
>> [ 17.956137] Hardware name: Gigabyte Technology Co., Ltd. H67A-UD3H-B3/H67A-UD3H-B3, BIOS F8 03/27/2012
>> [ 17.956139] Call Trace:
>> [ 17.956142] <TASK>
>> [ 17.956145] dump_stack_lvl+0x5d/0x80
>> [ 17.956154] ubsan_epilogue+0x5/0x2b
>> [ 17.956158] __ubsan_handle_out_of_bounds.cold+0x46/0x4b
>> [ 17.956162] ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
>> [ 17.956173] tasklet_action_common+0xb5/0x1c0
>> [ 17.956178] handle_softirqs+0xdf/0x320
>> [ 17.956181] __irq_exit_rcu+0xbc/0xe0
>> [ 17.956184] common_interrupt+0x47/0xa0
>> [ 17.956188] asm_common_interrupt+0x26/0x40
>> [ 17.956191] RIP: 0033:0x7f4fa439067d
>> [ 17.956204] Code: 0f b6 14 16 45 85 c0 74 01 92 29 d0 c3 48 8d 3c 07 48 8d 34 0e 45 85 c0 74 03 48 87 f7 48 0f bc d2 49 29 d3 76 0b 0f b6 0c 16 <0f> b6 04 17 29 c8 c3 31 c0 c3 66 0f 1f 84 00 00 00 00 00 0f b6 0e
>> [ 17.956206] RSP: 002b:00007ffd8cc32f08 EFLAGS: 00000212
>> [ 17.956209] RAX: 0000000000000020 RBX: 0000556dfab414a0 RCX: 0000000000000070
>> [ 17.956210] RDX: 000000000000000d RSI: 00007f4fa4b7a05f RDI: 0000556dfab414a0
>> [ 17.956211] RBP: 00007f4fa4b7a05f R08: 0000000000000400 R09: 0000000000000008
>> [ 17.956213] R10: fffffffffffff4b8 R11: 000000000000000e R12: 000000000000001b
>> [ 17.956214] R13: 0000556dfab412c0 R14: 00007ffd8cc32f80 R15: 00007f4fa4b79eaf
>> [ 17.956217] </TASK>
>> [ 17.956217] ---[ end trace ]---
>>
>> It occurs once at each boot.
>> According to
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/master/drivers/net/wireless/ath/ath5k/base.c
>> the line of code has not changed for about 15 years.
>> And I'm using this driver for more than 10 years.
>> So, the array-index-out-of-bounds does not seem to
>> have hard consequences for now (by luck?)
>
> Does that ring any bell?
No, but it is real. ts_final_idx is at most 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx = -1;
with:
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
and:
#define IEEE80211_TX_MAX_RATES 4
is indeed bogus.
IMO we should just *not* set idx = -1 if ts->ts_final_idx is >= 3. As
mac80211 won't look at rates beyond IEEE80211_TX_MAX_RATES.
FWIW, the effect of the UB is it just overwrites the next member of
info->status, i.e. ack_signal.
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBSAN array-index-out-of-bounds in ath5k driver
2025-11-03 7:00 ` Jiri Slaby
@ 2025-11-03 7:04 ` Jiri Slaby
2025-11-03 7:26 ` Vincent Danjean
0 siblings, 1 reply; 4+ messages in thread
From: Jiri Slaby @ 2025-11-03 7:04 UTC (permalink / raw)
To: Salvatore Bonaccorso, Nick Kossifidis, Luis Chamberlain
Cc: linux-wireless, linux-kernel, Vincent Danjean, 1119093
On 03. 11. 25, 8:00, Jiri Slaby wrote:
> Hi,
>
> On 01. 11. 25, 15:09, Salvatore Bonaccorso wrote:
>> In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported
>> the following:
>>> The ath5k driver seems to do an array-index-out-of-bounds access
>>> as shown by the UBSAN kernel message.
>>> [ 17.954484] ------------[ cut here ]------------
>>> [ 17.954487] UBSAN: array-index-out-of-bounds in /build/
>>> reproducible-path/linux-6.16.3/drivers/net/wireless/ath/ath5k/
>>> base.c:1741:20
>>> [ 17.955289] index 4 is out of range for type 'ieee80211_tx_rate [4]'
>>> [ 17.956134] CPU: 1 UID: 0 PID: 1745 Comm: 16 Not tainted
>>> 6.16.3+deb13-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1~bpo13+1
>>> [ 17.956137] Hardware name: Gigabyte Technology Co., Ltd. H67A-
>>> UD3H-B3/H67A-UD3H-B3, BIOS F8 03/27/2012
>>> [ 17.956139] Call Trace:
>>> [ 17.956142] <TASK>
>>> [ 17.956145] dump_stack_lvl+0x5d/0x80
>>> [ 17.956154] ubsan_epilogue+0x5/0x2b
>>> [ 17.956158] __ubsan_handle_out_of_bounds.cold+0x46/0x4b
>>> [ 17.956162] ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
>>> [ 17.956173] tasklet_action_common+0xb5/0x1c0
>>> [ 17.956178] handle_softirqs+0xdf/0x320
>>> [ 17.956181] __irq_exit_rcu+0xbc/0xe0
>>> [ 17.956184] common_interrupt+0x47/0xa0
>>> [ 17.956188] asm_common_interrupt+0x26/0x40
>>> [ 17.956191] RIP: 0033:0x7f4fa439067d
>>> [ 17.956204] Code: 0f b6 14 16 45 85 c0 74 01 92 29 d0 c3 48 8d 3c
>>> 07 48 8d 34 0e 45 85 c0 74 03 48 87 f7 48 0f bc d2 49 29 d3 76 0b 0f
>>> b6 0c 16 <0f> b6 04 17 29 c8 c3 31 c0 c3 66 0f 1f 84 00 00 00 00 00
>>> 0f b6 0e
>>> [ 17.956206] RSP: 002b:00007ffd8cc32f08 EFLAGS: 00000212
>>> [ 17.956209] RAX: 0000000000000020 RBX: 0000556dfab414a0 RCX:
>>> 0000000000000070
>>> [ 17.956210] RDX: 000000000000000d RSI: 00007f4fa4b7a05f RDI:
>>> 0000556dfab414a0
>>> [ 17.956211] RBP: 00007f4fa4b7a05f R08: 0000000000000400 R09:
>>> 0000000000000008
>>> [ 17.956213] R10: fffffffffffff4b8 R11: 000000000000000e R12:
>>> 000000000000001b
>>> [ 17.956214] R13: 0000556dfab412c0 R14: 00007ffd8cc32f80 R15:
>>> 00007f4fa4b79eaf
>>> [ 17.956217] </TASK>
>>> [ 17.956217] ---[ end trace ]---
>>>
>>> It occurs once at each boot.
>>> According to
>>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/
>>> linux-stable/+blame/master/drivers/net/wireless/ath/ath5k/base.c
>>> the line of code has not changed for about 15 years.
>>> And I'm using this driver for more than 10 years.
>>> So, the array-index-out-of-bounds does not seem to
>>> have hard consequences for now (by luck?)
>>
>> Does that ring any bell?
>
> No, but it is real. ts_final_idx is at most 3 on 5212, so:
> info->status.rates[ts->ts_final_idx + 1].idx = -1;
> with:
> struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
> and:
> #define IEEE80211_TX_MAX_RATES 4
> is indeed bogus.
>
> IMO we should just *not* set idx = -1 if ts->ts_final_idx is >= 3. As
> mac80211 won't look at rates beyond IEEE80211_TX_MAX_RATES.
This™:
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1738,7 +1738,8 @@ ath5k_tx_frame_completed(struct ath5k_hw *ah,
struct sk_buff *skb,
}
info->status.rates[ts->ts_final_idx].count = ts->ts_final_retry;
- info->status.rates[ts->ts_final_idx + 1].idx = -1;
+ if (ts->ts_final_idx + 1 < IEEE80211_TX_MAX_RATES)
+ info->status.rates[ts->ts_final_idx + 1].idx = -1;
if (unlikely(ts->ts_status)) {
ah->stats.ack_fail++;
Vincent, can you test this?
> FWIW, the effect of the UB is it just overwrites the next member of
> info->status, i.e. ack_signal.
>
> thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBSAN array-index-out-of-bounds in ath5k driver
2025-11-03 7:04 ` Jiri Slaby
@ 2025-11-03 7:26 ` Vincent Danjean
0 siblings, 0 replies; 4+ messages in thread
From: Vincent Danjean @ 2025-11-03 7:26 UTC (permalink / raw)
To: Jiri Slaby, Salvatore Bonaccorso, Nick Kossifidis,
Luis Chamberlain
Cc: linux-wireless, linux-kernel, 1119093
Le 03/11/2025 à 08:04, Jiri Slaby a écrit :
> This™:
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -1738,7 +1738,8 @@ ath5k_tx_frame_completed(struct ath5k_hw *ah, struct sk_buff *skb,
> }
>
> info->status.rates[ts->ts_final_idx].count = ts->ts_final_retry;
> - info->status.rates[ts->ts_final_idx + 1].idx = -1;
> + if (ts->ts_final_idx + 1 < IEEE80211_TX_MAX_RATES)
> + info->status.rates[ts->ts_final_idx + 1].idx = -1;
>
> if (unlikely(ts->ts_status)) {
> ah->stats.ack_fail++;
>
> Vincent, can you test this?
It is not easy for me: the computer with this wifi card is in my parent's home.
I won't go back there until Christmas.
I will see if I can test remotely.
Regards,
Vincent
>> FWIW, the effect of the UB is it just overwrites the next member of info->status, i.e. ack_signal.
>>
>> thanks,
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-11-03 7:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-01 14:09 UBSAN array-index-out-of-bounds in ath5k driver Salvatore Bonaccorso
2025-11-03 7:00 ` Jiri Slaby
2025-11-03 7:04 ` Jiri Slaby
2025-11-03 7:26 ` Vincent Danjean
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox