skb_cb corruption in ath10k

skb_cb corruption in ath10k

[Ben Greear]

Hello,

I'm trying to figure out what changed in the last few kernels that is making:

struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
	/* why is code here all of a sudden */

in data frames in ath10k,
when, to the best of my knowledge, nothing should be setting that up in the stack.

My guess is that something is stepping on the cb field somewhere in ath10k,
but I am not sure where that might be at this point.

And it also appears mac80211 or maybe supplicant is setting the rate-inject flag on some mgt frames,
but I think that is a separate concern at this point.

If anyone has any ideas of likely points, please let me know.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

skb_cb corruption in ath10k

[Ben Greear]

Hello,

I'm trying to figure out what changed in the last few kernels that is making:

struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
	/* why is code here all of a sudden */

in data frames in ath10k,
when, to the best of my knowledge, nothing should be setting that up in the stack.

My guess is that something is stepping on the cb field somewhere in ath10k,
but I am not sure where that might be at this point.

And it also appears mac80211 or maybe supplicant is setting the rate-inject flag on some mgt frames,
but I think that is a separate concern at this point.

If anyone has any ideas of likely points, please let me know.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: skb_cb corruption in ath10k

[Ben Greear]

On 12/21/20 3:55 PM, Ben Greear wrote:
> Hello,
> 
> I'm trying to figure out what changed in the last few kernels that is making:
> 
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
>      /* why is code here all of a sudden */
> 
> in data frames in ath10k,
> when, to the best of my knowledge, nothing should be setting that up in the stack.
> 
> My guess is that something is stepping on the cb field somewhere in ath10k,
> but I am not sure where that might be at this point.
> 
> And it also appears mac80211 or maybe supplicant is setting the rate-inject flag on some mgt frames,
> but I think that is a separate concern at this point.
> 
> If anyone has any ideas of likely points, please let me know.

This issue was me being confused about how the ath10k skb_cb sits in
the same memory as the iee skb_cb.  I just needed to reorder the
ath10k-skb-cb struct a bit to not clobber the control.flags area.

I also see no reason not to natually pack that stuct so that the
pointers are 8-byte aligned.  Any idea why it is force-packed
currently instead of using proper padding?

Thanks,
Ben

Re: skb_cb corruption in ath10k

[Ben Greear]

On 12/21/20 3:55 PM, Ben Greear wrote:
> Hello,
> 
> I'm trying to figure out what changed in the last few kernels that is making:
> 
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
>      /* why is code here all of a sudden */
> 
> in data frames in ath10k,
> when, to the best of my knowledge, nothing should be setting that up in the stack.
> 
> My guess is that something is stepping on the cb field somewhere in ath10k,
> but I am not sure where that might be at this point.
> 
> And it also appears mac80211 or maybe supplicant is setting the rate-inject flag on some mgt frames,
> but I think that is a separate concern at this point.
> 
> If anyone has any ideas of likely points, please let me know.

This issue was me being confused about how the ath10k skb_cb sits in
the same memory as the iee skb_cb.  I just needed to reorder the
ath10k-skb-cb struct a bit to not clobber the control.flags area.

I also see no reason not to natually pack that stuct so that the
pointers are 8-byte aligned.  Any idea why it is force-packed
currently instead of using proper padding?

Thanks,
Ben



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k