crypt and crypt->ops could be null, so we need to checking null
before dereference

Previously the commit
e8366bbabe1d ("ipw2x00: Fix potential NULL dereference in libipw_xmit()")
partially fixed that same issue in libipw_xmit().
This is similar to CVE-2022-49544.

Found by Svace static analysis tool.

Cc: stable@vger.kernel.org
Fixes: 1264fc0498e1e ("[PATCH] ieee80211: Fix TKIP, repeated fragmentation problem, and payload_size reporting")
Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
---
 drivers/net/wireless/intel/ipw2x00/libipw_tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_tx.c b/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
index 6e16060834b8..ec455e680030 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
+++ b/drivers/net/wireless/intel/ipw2x00/libipw_tx.c
@@ -450,7 +450,7 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
 	for (; i < nr_frags; i++) {
 		skb_frag = txb->fragments[i];
 
-		if (host_encrypt)
+		if (host_encrypt && crypt && crypt->ops)
 			skb_reserve(skb_frag,
 				    crypt->ops->extra_mpdu_prefix_len);
 
-- 
2.34.1

On Wed, 2026-05-27 at 12:08 +0300, Nikolay Kuratov wrote:
> crypt and crypt->ops could be null, so we need to checking null
> before dereference
> 
> Previously the commit
> e8366bbabe1d ("ipw2x00: Fix potential NULL dereference in libipw_xmit()")
> partially fixed that same issue in libipw_xmit().
> This is similar to CVE-2022-49544.
> 
> Found by Svace static analysis tool.

Might want to fix your tool to look deeper than just pattern-matching
the surrounding code :) The prior commit was also already wrong.

We already have

	host_encrypt = ieee->host_encrypt && encrypt && crypt;

so "host_encrypt && crypt" is equivalent to checking just
"host_encrypt".

And the only way to set the crypt[] array where a non-NULL 'crypt' comes
from will always have ops, so "crypt && crypt->ops" is equivalent to
checking just "crypt".

johannes

> Might want to fix your tool to look deeper than just pattern-matching
> the surrounding code :) The prior commit was also already wrong.

That was me who blindly believed in existing commit correctness!

> so "host_encrypt && crypt" is equivalent to checking just
> "host_encrypt".

Thank you, missed that.

> And the only way to set the crypt[] array where a non-NULL 'crypt' comes
> from will always have ops, so "crypt && crypt->ops" is equivalent to
> checking just "crypt".

To make it more clear, this logic belongs to libipw_wx_set_encode
and libipw_wx_set_encodeext. If there is no libipw_crypt_wep module
available, then it fails with NULL crypt as you said.
Some parts of code still check for non-NULL crypt->ops separately,
but at least it should not cause problems.

Lets just drop that patch.