drivers/net/wireless/intel/ipw2x00/libipw_crypto_wep.c
Source file repositories/reference/linux-study-clean/drivers/net/wireless/intel/ipw2x00/libipw_crypto_wep.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/wireless/intel/ipw2x00/libipw_crypto_wep.c- Extension
.c- Size
- 5922 bytes
- Lines
- 248
- Domain
- Driver Families
- Bucket
- drivers/net
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/err.hlinux/fips.hlinux/module.hlinux/init.hlinux/slab.hlinux/random.hlinux/scatterlist.hlinux/skbuff.hlinux/mm.hasm/string.hcrypto/arc4.hlinux/crc32.hlibipw.h
Detected Declarations
struct libipw_wep_datafunction libipw_wep_deinitfunction libipw_wep_build_ivfunction libipw_wep_encryptfunction ICVfunction libipw_wep_set_keyfunction libipw_wep_get_keyfunction libipw_wep_print_statsfunction libipw_crypto_wep_initfunction libipw_crypto_wep_exit
Annotated Snippet
struct libipw_wep_data {
u32 iv;
#define WEP_KEY_LEN 13
u8 key[WEP_KEY_LEN + 1];
u8 key_len;
u8 key_idx;
struct arc4_ctx tx_ctx;
struct arc4_ctx rx_ctx;
};
static void *libipw_wep_init(int keyidx)
{
struct libipw_wep_data *priv;
if (fips_enabled)
return NULL;
priv = kzalloc_obj(*priv, GFP_ATOMIC);
if (priv == NULL)
return NULL;
priv->key_idx = keyidx;
/* start WEP IV from a random value */
get_random_bytes(&priv->iv, 4);
return priv;
}
static void libipw_wep_deinit(void *priv)
{
kfree_sensitive(priv);
}
/* Add WEP IV/key info to a frame that has at least 4 bytes of headroom */
static int libipw_wep_build_iv(struct sk_buff *skb, int hdr_len,
u8 *key, int keylen, void *priv)
{
struct libipw_wep_data *wep = priv;
u32 klen;
u8 *pos;
if (skb_headroom(skb) < 4 || skb->len < hdr_len)
return -1;
pos = skb_push(skb, 4);
memmove(pos, pos + 4, hdr_len);
pos += hdr_len;
klen = 3 + wep->key_len;
wep->iv++;
/* Fluhrer, Mantin, and Shamir have reported weaknesses in the key
* scheduling algorithm of RC4. At least IVs (KeyByte + 3, 0xff, N)
* can be used to speedup attacks, so avoid using them. */
if ((wep->iv & 0xff00) == 0xff00) {
u8 B = (wep->iv >> 16) & 0xff;
if (B >= 3 && B < klen)
wep->iv += 0x0100;
}
/* Prepend 24-bit IV to RC4 key and TX frame */
*pos++ = (wep->iv >> 16) & 0xff;
*pos++ = (wep->iv >> 8) & 0xff;
*pos++ = wep->iv & 0xff;
*pos++ = wep->key_idx << 6;
return 0;
}
/* Perform WEP encryption on given skb that has at least 4 bytes of headroom
* for IV and 4 bytes of tailroom for ICV. Both IV and ICV will be transmitted,
* so the payload length increases with 8 bytes.
*
* WEP frame payload: IV + TX key idx, RC4(data), ICV = RC4(CRC32(data))
*/
static int libipw_wep_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
{
struct libipw_wep_data *wep = priv;
u32 crc, klen, len;
u8 *pos, *icv;
u8 key[WEP_KEY_LEN + 3];
/* other checks are in libipw_wep_build_iv */
if (skb_tailroom(skb) < 4)
return -1;
/* add the IV to the frame */
if (libipw_wep_build_iv(skb, hdr_len, NULL, 0, priv))
return -1;
Annotation
- Immediate include surface: `linux/err.h`, `linux/fips.h`, `linux/module.h`, `linux/init.h`, `linux/slab.h`, `linux/random.h`, `linux/scatterlist.h`, `linux/skbuff.h`.
- Detected declarations: `struct libipw_wep_data`, `function libipw_wep_deinit`, `function libipw_wep_build_iv`, `function libipw_wep_encrypt`, `function ICV`, `function libipw_wep_set_key`, `function libipw_wep_get_key`, `function libipw_wep_print_stats`, `function libipw_crypto_wep_init`, `function libipw_crypto_wep_exit`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.