A host installed the fixed package but was never restarted. Is the flaw gone?
answer
- disk state versus memory state
- a version query reads the package database
- the replaced file is still mapped
- old inode survives while a process holds it
- restart is what unmaps the old code
basics
~20 sNo. Installing a package writes a new file to disk; every process already running keeps the old copy of the shared library mapped in memory and keeps executing it. Until those processes restart, the vulnerable code is still live.
solid answer
~50 sNo. A package install replaces the file on disk and updates the package database, and that is all a version query reads. A process that already mapped the old shared object keeps that mapping for its whole lifetime, because the mapping is tied to the file that was open when it loaded, not to the path. So a long-running daemon on a host that has not restarted since the install is executing exactly the same vulnerable code as an unpatched host, while the version string looks correct. What has to restart depends on where the code lives: a userspace library needs every process that maps it to restart; a kernel fix needs a boot onto the new kernel; firmware is usually written to a staging bank and only becomes the running image at the next power cycle. "Installed" and "running" are two different facts about the same host.
go deeper
Be ready to state plainly that installing a file and running its code are two different events, and that a process keeps the library it loaded at start. Know the three restart units: process, kernel boot, power cycle.
An interviewer expects the mechanism: the mapping is tied to the file that was open when the process loaded, so replacing the path leaves the old code executing until exit. Contrast Linux replace-then-restart with Windows staging the swap for reboot.
Show that you check per host which processes started before the install landed, and that you treat firmware and management controllers as separate lifecycles rather than assuming the host cadence covers them.
Own the consequence for how patching is measured across an estate: if the number quoted is installs, the programme is measuring distribution rather than risk removal, and the gap is where a patient adversary lives.
## The claim being tested "We installed the fix" and "the fix is in force" are different statements about a host, and almost every patch number quoted in a review is the first one. The question is whether you know why they come apart. ## What installing actually does A package install does three things: it writes new files onto the filesystem, it updates the package database so a version query answers with the new number, and it may run a post-install step. None of those three touches memory that is already in use. On Linux, a shared object is mapped into a process's address space when the process starts (or when it explicitly loads the object later). The mapping is against the file's inode, not against its path. A package manager replaces a library by writing a new file and renaming it over the old path, which unlinks the old inode from the directory but does not destroy it: the kernel keeps the old inode alive as long as any process still has it mapped. The consequence is exact and worth memorising - **the running process continues to execute the old, vulnerable machine code until it exits**. A host that installed the fix in April and has not restarted the daemon since is, on that flaw, indistinguishable in behaviour from a host that never got the update. It just looks green. Windows arrives at the same place from the opposite direction. There the loader holds the file open, so a replacement usually cannot be written at all while the code is in use; the update is staged and applied during the restart. That is why Windows servicing is reboot-shaped by design: the platform admits up front that the swap needs a restart, where Linux lets you complete the install and then quietly keep running the old code. ## Which restart is the one that matters The unit that must restart is the unit that loaded the code: | Where the fix lives | What makes it take effect | | --- | --- | | Userspace shared library | Every process that maps it must restart | | A single service's own binary | That service restarts | | Kernel | Boot onto the fixed kernel (or a live patch, with limits) | | Device or platform firmware | Written to a staging bank, activated at the next power cycle - a warm reboot often is not enough | | Out-of-band management controller | Its own firmware, its own lifecycle, unaffected by anything the host operating system does | The last two rows are where estates lose track. Firmware updates commonly succeed as a write and then sit staged, so the device advertises a new available version and keeps executing the old one. And a management controller runs its own software on its own processor, stays powered when the host is off, and is not in the host's package cadence at all - patching the operating system says nothing about it. ## Why this is a security fact, not a housekeeping one Two different people produce this state, and the state is identical. An administrator defers a power cycle on a hypervisor because the guests on it cannot pause during a busy quarter - an entirely reasonable business decision. An operator who is already inside on the management segment and has time to spend simply waits for the same hosts, because the population that never completes a cycle is a standing supply of unpatched, high-value machines that nobody counts as unpatched. You cannot tell those two stories apart from the version number, which is precisely why the version number is the wrong thing to look at. The reachability question still applies on top: a flaw in a library only matters where a process that maps it can be reached. A vulnerable parsing routine inside a listening service on the management segment is exploitable; the same library mapped by a one-shot utility that runs at midnight is a much smaller problem. But that is a question about which un-restarted process to prioritise, not a reason to call the host fixed. ## What to say in an interview Say the mechanism in one line - the replaced file is on disk, the old code is still mapped - and then say the consequence in one line: a patched host that never restarted the thing is exactly as exploitable as an unpatched one. Then name the three restart units (process, kernel boot, power cycle) and note that a management controller has none of them.
- Which processes on the host do you actually have to restart, and how do you decide?Every process that mapped the replaced library. In practice you rank them by reachability and privilege: listening services first, especially anything reachable from the management segment or running as root, then long-lived batch workers, then interactive sessions. A full boot restarts all of them at once and is the simpler proof if the host can take it.
- Does deleting or overwriting the vulnerable file remove the risk immediately?No. On Linux the old inode stays alive while any process has it mapped, so overwriting or unlinking the path changes what new processes load and nothing about what old ones are executing. The exposure ends when the last mapper exits, not when the file disappears.
- A firmware update said it completed. Why might the device still be vulnerable?Because most platform firmware is written into a staging bank and only becomes the running image at activation, which usually means a power cycle rather than a warm reboot. Until then the device advertises the new version as staged and keeps executing the old one, so the successful write proves storage, not execution.
Swapping the recipe card in the drawer does not change the dish already cooking on the stove. The kitchen looks updated; the pan does not.
saying these in an interview costs you the question
- Says the package version being current means the flaw is gone
- Believes running processes pick up a new library on the next call
- Treats a successful install as the end of the work
- Assumes overwriting the file stops the old code executing
- Thinks firmware written equals firmware running