pam_usb: xfree() does not call explicit_bzero — sensitive cryptographic material may linger in freed heap

An attacker who can trigger a use-after-free condition or who has access to a heap inspection primitive could recover one-time pad values or other authentication material from freed memory regions [ref_id=1]. The advisory notes this is a defence-in-depth issue; no specific network path or payload shape is described, and the precondition is the existence of a separate memory disclosure vulnerability (use-after-free or heap inspection) on the target system [ref_id=1].

The vulnerability is in `src/mem.c` in the `xfree()` memory release helper. `xfree()` calls `free()` without first zeroing the buffer contents, leaving sensitive data — including one-time pad bytes read from disk — in freed heap memory until it happens to be overwritten by a subsequent allocation [ref_id=1].

The patch modifies `xfree()` in `src/mem.c` to call `explicit_bzero(ptr, malloc_usable_size(ptr))` before `free()`, ensuring the buffer contents are cleared before the memory is released [ref_id=1]. `malloc_usable_size()` returns the actual usable allocation size (which may be slightly larger than the requested size due to alignment), making the zeroing complete and safe. The function is also marked `__attribute__((noinline))` to prevent a FORTIFY_SOURCE false positive that would otherwise occur when the compiler sees the allocation size and flags `malloc_usable_size()` as overflowing it [ref_id=1]. No call-site modifications are required.