wolfcrypt_glue.c: non-BANKREF DRBG context uses contiguous kmalloc — switch to kvzalloc

[cpsource]

Summary

A kernel-module best-practices follow-up review (see README-kernel-module-review.md on master) turned up one novel Major allocator-choice finding, reported here for tracking.

Finding

File/lines: kernel-src/wolfcrypt_glue.c:1070 in wc_linuxkm_drbg_init_ctx (#else /* !WC_DRBG_BANKREF */ branch), paired with the free at :1054 in wc_linuxkm_drbg_ctx_clear.

ctx->n_rngs = max(4, (int)nr_cpu_ids);
ctx->rngs = (struct wc_rng_inst *)malloc(sizeof(*ctx->rngs) * ctx->n_rngs);

struct wc_rng_inst (defined at wolfcrypt_glue.h:233-239) contains a wolfSSL_Atomic_Int lock, a WC_RNG rng (~300–800 B depending on FIPS mode), a 1024-byte rnd_pool, a word32 rnd_pool_offset, and int disabled_vec_ops — conservatively ≈1.3–2 KB per element.

On a 96-CPU host, n_rngs = 100 → a single contiguous request of roughly 130–200 KB. That is within KMALLOC_MAX_SIZE on every supported arch, but corresponds to an order-5/6 page allocation, which fails readily under memory fragmentation. A failure here aborts module load with -ENOMEM.

The WC_DRBG_BANKREF branch delegates allocation to wolfSSL's wc_rng_bank_new, so it is not affected by this finding.

Severity

Major — affects module loadability on high-core-count systems under memory pressure. Not a security issue.

Suggested fix

Switch the non-BANKREF allocation to kvzalloc (which transparently falls back to vmalloc for large requests), and pair it with kvfree:

--- a/kernel-src/wolfcrypt_glue.c
+++ b/kernel-src/wolfcrypt_glue.c
@@ wc_linuxkm_drbg_init_ctx
-    ctx->rngs = (struct wc_rng_inst *)malloc(sizeof(*ctx->rngs) * ctx->n_rngs);
+    ctx->rngs = (struct wc_rng_inst *)kvzalloc(sizeof(*ctx->rngs) * ctx->n_rngs, GFP_KERNEL);
     if (! ctx->rngs) {
         ctx->n_rngs = 0;
         WC_DEBUG_PR_NEG_RET(-ENOMEM);
     }
-    XMEMSET(ctx->rngs, 0, sizeof(*ctx->rngs) * ctx->n_rngs);
@@ wc_linuxkm_drbg_ctx_clear
-        free(ctx->rngs);
+        kvfree(ctx->rngs);

The explicit XMEMSET becomes redundant with kvzalloc's zero-init and can be dropped.

Verification

• struct wc_rng_inst layout confirmed in wolfcrypt_glue.h:233-239 (1024-byte rnd_pool alone exceeds one page is not the issue, but aggregated-per-CPU contiguity is).
• nr_cpu_ids can reach CONFIG_NR_CPUS, which defaults to 8192 on modern defconfigs (realistically bounded by the running box).
• kmalloc comfort zone on most arches is ≈order-3 (32 KB); higher-order allocations are the first to fail under fragmentation.

[douzzer]

Wrong analysis -- kernel-src/wolfcrypt_glue.c gets its malloc() definition from wolfssl/linuxkm/linuxkm_wc_port.h, which by default is a macro wrapper around kvmalloc_node() on kernels >= 4.12.0 (further back than we currently support for the WolfGuard kernel module). Moreover the allocations are done opportunistically with GFP_KERNEL semantics, which is what will be used during WolfGuard module initialization, including wc_linuxkm_drbg_init_ctx().