What dnf needs-restarting actually tells you after Linux patching
dnf needs-restarting is useful after Linux patching, but its output is only one signal. Here is how to turn it into better remediation evidence.
Field Notes
Linux security notes for the people closing the tickets.
Patch windows, CVE queues, service restarts, reboot debt, exposed ports, compliance evidence, and the messy gap between “updated” and “fixed.”
A green vulnerability dashboard is not remediation evidence
A scanner state change is useful, but it is not the same as proof that vulnerable Linux code stopped running. Here is what stronger remediation evidence should show.
Patched on disk, old library still running: how to find stale Linux processes
Package updates can replace vulnerable shared libraries on disk while long-running Linux processes keep the old deleted objects mapped in memory. Here is how to inspect stale library mappings after patching.
Your Linux host is patched. Is it actually running the fixed kernel?
Kernel updates can be installed on disk while the host is still booted into the older vulnerable kernel. Here is a practical RHEL-family workflow for checking reboot debt after patching.
Vendor says it is fixed. Your scanner says it is vulnerable. Now what?
Red Hat Enterprise Linux and RHEL-family vulnerability results can look contradictory because enterprise Linux vendors backport fixes. Here is how EVRs, advisories, scanner logic, and runtime state fit together.
What Linux patch evidence should include before you close a vulnerability
Package version evidence is useful, but it is not always enough to close a Linux vulnerability. Here is the host-level evidence worth collecting before calling a finding remediated.
Linux restart debt after patching: when updated packages are not the end of the work
Package updates can fix files on disk while old code keeps running in long-lived processes. Here is how restart debt happens on Linux, how to inspect it, and why it matters after a patch window.
Build a post-patch Linux verification CSV with Ansible
A practical RHEL-family workflow for using Ansible to collect host, kernel, package, restart debt, deleted library mappings, and listening service evidence into a CSV after a patch window.
The patch installed cleanly. The vulnerable code may still be running.
Package managers show what changed on disk. They do not always show whether long-running services still have old libraries mapped in memory, or whether a host is still booted into the vulnerable kernel.