Skip to contentSkip to conversation

UBSAN array-index-out-of-bounds in ath5k driver

DISCUSSION Salvatore Bonaccorso 3 participants 4 messages Nov 1, 2025 – Nov 3, 2025 Atheros ATH5K wireless driver

lore
Share & tools
lore

Salvatore Bonaccorso

author
#0 lore raw

Hi

In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported the following:

Quoted 39 lines

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?)

Quoted 2 lines

Regards,
Vincent

Does that ring any bell?

Regards,
Salvatore

maintainer
#1 lore raw

Hi,

Quoted 39 lines · Salvatore Bonaccorso

In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported the following:

Quoted 29 lines

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 ]---
Quoted 7 lines

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?)

Quoted 1 line

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,

Signature · 2 lines
js
suse labs
maintainer
#2 lore raw
Quoted 52 lines · Jiri Slaby

Hi,

Quoted 39 lines · Salvatore Bonaccorso

In Debian, https://bugs.debian.org/1119093, Vincent Danjean reported the following:

Quoted 29 lines

   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 ]---

Quoted 7 lines

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?)

Quoted 1 line

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.

Quoted 1 line

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™:

drivers/net/wireless/ath/ath5k/base.c +2 -1
@@ -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?

Quoted 3 lines

FWIW, the effect of the UB is it just overwrites the next member of info->status, i.e. ack_signal.

thanks,

Signature · 2 lines
js
suse labs
#3 lore raw

Le 03/11/2025 à 08:04, Jiri Slaby a écrit :

Quoted 14 lines

This™:

drivers/net/wireless/ath/ath5k/base.c +2 -1
@@ -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++;
Quoted 1 line

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

Quoted 4 lines
Quoted 3 lines

FWIW, the effect of the UB is it just overwrites the next member of info->status, i.e. ack_signal.

thanks,