Keep the Boundary When the Work Fails

A cancelled task still has things to put away. Files may be open. Locks may be held. Objects may need cleanup. Stopping a program's work is itself work—and the machinery doing it deserves more attention than we usually give the exit sign.

In a September 14 security write-up, Sammy Hajhamid, who publishes as PepsiPu, examines how a cancelled thread retraces active function calls to run cleanup. This is called stack unwinding. In the glibc path he examines, that process can evaluate instructions called DWARF expressions to recover earlier execution state.

Cleanup is not just putting things away. It is running more instructions.

Hajhamid demonstrates how an attacker who already has specific memory-corruption capabilities can redirect this machinery toward code execution. His example requires control over a large allocated memory region and out-of-bounds writes of zero bytes. This is not a claim that cancelling an ordinary task, by itself, compromises a machine. It is a demonstration of what existing corruption can reach through a path whose everyday purpose sounds reassuring: cleanup.

I want to take that change of perspective to the workbench. Not to reproduce the exploit. To stop treating recovery as though it sits outside the system we are responsible for building.

---

A good purpose is not a permission boundary

The cleanup machinery exists for a reason. Simply abandoning a thread's resources could leave files open or locks held. Removing cleanup indiscriminately would exchange one class of trouble for another.

That is what makes this more useful than a story about an obviously bad feature. The intended behavior is necessary. The question is what the mechanism can do, what it trusts, and how those assumptions hold when something has already gone wrong.

“Only used for recovery” describes when a capability runs. It does not limit its authority.

The same distinction is worth making at a different scale. A retry worker, a restore procedure, or a diagnostic exporter is not the DWARF mechanism in Hajhamid's demonstration. Each is, however, a place to ask the same engineering question: what becomes possible when the normal route fails?

A system diagram that shows only successful work leaves out part of the machine. A promise about privacy or permissions that applies only to successful work leaves out part of the promise.

The job is not simply to get work moving again. It is to keep the original limits on access in force while doing so.

---

The retry that changes the job

Imagine a small service that processes documents for several community groups. This is a hypothetical design, not an incident reported in the source.

During normal operation, each job uses credentials restricted to its own group's storage. A failed job goes to a retry worker. To simplify support, that worker uses one credential with access to every group.

The retry succeeds. The dashboard turns green.

But the system has changed the terms of the job. A failure handed the document to a worker with access to every group’s storage. Nobody had to decide that this particular document warranted broader access. The exception path made the decision automatically.

The fix is not necessarily to eliminate the retry worker. It is to carry the job's original access limits into the retry and report a blocked job when it cannot continue within them. If broader access is genuinely required, make that a separate, explicit decision—not a hidden property of trying again.

That may leave more failures visible. Good. A blocked job and an unauthorized recovery are not interchangeable inconveniences.

The people whose documents are being handled bear part of the risk. Their interests cannot disappear because the operator would prefer a shorter queue. This is where coherence stops meaning a tidy dashboard: an orderly result is not enough if the order depends on making affected people invisible.

---

Rehearse one failure, preserve one promise

Tomorrow, choose one workflow you own and can test safely. Not the whole infrastructure. One import, one background job, one restore procedure.

Before touching it, write a sentence stating what must remain true when it fails. For the hypothetical document service:

A failed job must never gain access to another group's documents.

That sentence is the test's center. “The retry eventually succeeds” is a separate condition.

Use an isolated test environment with disposable accounts and synthetic documents. Give a test job access to group A and create a harmless marker document in group B. Cause a controlled failure through a supported test hook or a simulated dependency timeout. Do not provoke memory corruption or interfere with production to imitate the source's demonstration.

Follow the job into recovery. Identify the credential the retry actually uses and the storage scope it actually receives. Using the retry credential in the isolated test environment, attempt to read the known group B marker and confirm that access is denied—not merely that the document was never requested. Inspect diagnostic output too: a restricted worker is not enough if its failure report copies the input somewhere with broader access.

The evidence should tell a small, complete story: the job failed; recovery ran; the boundary held—or it did not. A green completion status alone cannot tell that story.

If the boundary breaks, change the recovery arrangement and run the same test again. Keep the test beside the workflow so the next person who simplifies retry handling has a way to discover what their simplification costs. One passing rehearsal does not certify every failure mode. It gives one important promise an observable check.

Build the access limit into the recovery path, rather than asking a tired operator to remember it during an incident. The durable capability is not merely getting the work moving again. It is being able to show what remained protected while it stopped.

A failure may interrupt the work. It must not silently rewrite who the work is allowed to affect.