Skip to content

Km fixes#10357

Open
sameehj wants to merge 3 commits intowolfSSL:masterfrom
sameehj:km-fixes
Open

Km fixes#10357
sameehj wants to merge 3 commits intowolfSSL:masterfrom
sameehj:km-fixes

Conversation

@sameehj
Copy link
Copy Markdown
Contributor

@sameehj sameehj commented Apr 30, 2026

Description

Three minimal, independent fixes in the wolfSSL kernel ports:

  1. bsdkm/wolfkmod.cwolfkdriv_process() now returns 0 after crypto_done(), per opencrypto(9). Errors continue to be reported via crp->crp_etype. Returning the operation error after completion could cause the framework to re-dispatch an already-completed request.

  2. linuxkm/linuxkm_wc_port.hmy_memmove() early-returns when n == 0. The backward-copy branches compute (n - 1) as size_t, wrapping to SIZE_MAX for n == 0; with src < dest the loop walks backward through kernel memory and oopses. Reachable under CONFIG_FORTIFY_SOURCE from ASN.1/PKCS/TLS parsers via XMEMMOVE. Matches glibc, musl, and the kernel's own memmove().

  3. linuxkm/x86_vector_register_glue.c — Plug a struct pid refcount leak in wc_linuxkm_fpu_state_assoc_unlikely(): find_get_pid() bumps the refcount; the live-owner branch now releases it with put_pid(). Orphaned-slot branch unchanged.

Combined diff: 3 files, 11 insertions, 2 deletions.

Testing

  • bsdkm and linuxkm modules build and load; wolfcrypt/test passes.
  • my_memmove(dst, src, 0) is now a no-op (was an oops with low/NULL src).
  • No struct pid refcount growth under repeated contested-slot stress (previously monotonic).

Checklist

  • added tests - N/A (kernel-mode correctness fixes)
  • updated/added doxygen - N/A (no API change)
  • updated appropriate READMEs - N/A
  • Updated manual and documentation - N/A

sameehj added 3 commits April 30, 2026 10:56
cryptodev_process must return 0 once crypto_done() has fired; errors are reported via crp_etype, otherwise the framework may re-dispatch an already-completed request.

Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
…to avoid size_t underflow

The backward-copy branches compute (n - 1) as size_t, which wraps to SIZE_MAX for n == 0 and, with src below dest, drives the loop backward through kernel memory until it oopses; matches glibc / musl / kernel memmove().

Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
… find_get_pid() in wc_linuxkm_fpu_state_assoc_unlikely().

find_get_pid() returns a struct pid * with the refcount bumped via
get_pid(); callers must release it with put_pid().  The probe here is
purely a liveness check on the slot's previous owner, and the returned
pointer was discarded -- leaking one struct pid reference every time
the unlikely contested-slot path was hit with a still-live owner.

Capture the pointer and put_pid() it on the live-owner branch;
behavior on the orphaned-slot branch is unchanged.

Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
@github-actions
Copy link
Copy Markdown

MemBrowse Memory Report

No memory changes detected for:

@sameehj
Copy link
Copy Markdown
Contributor Author

sameehj commented Apr 30, 2026

retest this please

Copy link
Copy Markdown

@wolfSSL-Fenrir-bot wolfSSL-Fenrir-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fenrir Automated Review — PR #10357

Scan targets checked: bsdkm-bugs, bsdkm-src, linuxkm-bugs, linuxkm-src

No new issues found in the changed files. ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants