In Gogol, a revision tale was the list of souls drawn up at a census: until the next one came around, the dead were counted among the living. The Android security bulletin works the same way — the date in the settings refreshes, the peace of mind is delivered, and the promise "install the latest update and you are safe" quietly dies.
1. The List of Souls
In May 2026 the Android security bulletin contained a single vulnerability. It was a critical flaw in a system component. In March there were 129 of them, the highest count since April 2018. From these two documents alone it is impossible to judge the real security of a phone. The size of the list measures neither the scale of the problem nor the quality of its solution. It merely records the fact that certain bugs made it into the report for a given month.
A person sees the patch-level date change in the settings and locks the screen with an easy mind. That is by design, because it is precisely for that peace of mind that the bulletin exists.
Gogol described this construction beautifully. The revision tale was a list of souls drawn up during a census. Until the next revision came around, the dead were counted among the living. Taxes continued to be paid for them; loans were even taken out against them. Chichikov deceived no one in the literal sense. He simply took advantage of the gap between the paper list and real life. The list itself remained formally honest, because it was never obliged to match reality.
The occasion for this piece was a post by the GrapheneOS developers, published on October 4, 2026. By their account, patches appear in the bulletin two to six months after the manufacturers have already received them and are free to ship them. Some fixes never make it into the bulletin at all, and Google has recently told its partners that the full set of high- and critical-severity patches will go only to the newest releases. These are the post authors' words, and I was unable to confirm the last point independently, though the post quotes the formulation openly. I will not argue about every detail. For me the post was the trigger, because it shows the list has stopped matching the living. The question is whether this is an accident or a structure.
One clarification to avoid a misunderstanding: the size of the bulletin is a poor signal in itself, and that is exactly what I will insist on below. The contrast of "one against a hundred and twenty-nine" is not here as proof of decline; it is here as a reason to take the files off the shelf and look at what happens between them.
2. What Counts as Death
The system did not die the way a failed server dies. The kernel keeps building, the bulletins keep shipping, vulnerabilities keep getting CVE numbers, and maintainers keep answering mail. The pulse is intact. What died is the promise itself: install the latest update and you are protected.
That promise has two halves. The first concerns whether the system manages to produce fixes. The second determines whether they reach the person holding the phone. The whole thesis rests on the second half. The first is needed only as the backdrop against which the gap becomes visible.
3. How Souls Die
The bottleneck used to be finding vulnerabilities. People found them expensively and one at a time, so defenders had time to find a bug, fix it and ship an update. Carrying a fix back to older branches, known as a backport, remained a craft, because the volume of work matched the capacity of craftsmen.
Language models inverted that inequality. Finding bugs became cheap. What is more, every published patch turned into a textbook for the next search. From a fix one derives the bug's pattern and hunts for it across the whole repository. For the attacker, running a model is enough. The defender must find the problem, adapt the fix to every branch, test it, ship it through the vendor and carry it to the end device. The price of searching fell by orders of magnitude, while the price of fixing stayed human. Under that inequality even a perfect patch loses — not on quality, but on the speed of scaling.
This is no longer a hypothesis. As recounted by LWN, at the Kernel Recipes 2026 conference Greg Kroah-Hartman — the man who ships the stable kernels — spoke about the flood of vulnerability reports, caused by the fact that models have made finding them easy.
The authors of the same GrapheneOS post put it bluntly: in 2026 Google is overwhelmed by the volume of vulnerabilities being found by language models, both inside the company and outside. Two independent observations — the talk by the man who ships the kernels and the post by the developers of a user-facing system — converged on the same point. When two witnesses name the same cause without conferring, the witnesses are not the problem.
4. Numbers from the Gallery
The Linux kernel serves as the main mirror, because its accounting is open. We extracted the tag history from the official mirror of the stable branches and recalculated the numbers ourselves, relying on the dates of the tags.
In the first nine months of 2026, 263 stable releases came out, against 242 in the whole of 2025 — per month, that is twenty-nine against twenty. Over two years the count exceeds five hundred releases, and the monthly spread ran from 8 to 37.
At first glance there is an overall increase, but the picture changes when you break it down by branch. The three old long-term branches (6.1, 6.6 and 6.12) together produced 114 releases against 115 the year before. Practically all of the growth among the sixth and seventh series came from one new line, 6.18, which issued 52 of the 59 new tags.
The real find lies elsewhere. The oldest branches, 5.10 and 5.15, which were given their end-of-support date in December, produced 47 releases against 30 the year before. That is growth of 57 per cent. Branches with an announced expiry date are getting more work, not less. The support window is not being closed while it is formally open; it is being packed with tasks to the brim.
Picture a Soviet factory officially closing on December 31. It is precisely in November and December that the shops start working three shifts, turning out mountains of product so the plan can be formally closed out. The same thing is happening here.
There is a more prosaic explanation for the picture: before closing a branch, the maintainer clears the desk, carrying over everything accumulated. But that, too, feeds the general conclusion — the support window is not closed empty, and the last months of an old branch's life turn out to be its densest.
The second count matters more than the first, because it does not depend on how releases are counted. It concerns the volume of work inside them. We recalculated the commits between the tags of the 6.12 branch. The average release of 2025 contained 202 commits. In the first quarter of 2026 the figure fell to 172, but in the second and third quarters it rose to 253. That adds a quarter more work at a comparable rhythm, though the curve is not monotonic.
There is also a chart that illustrates the same thought on someone else's material. On August 28, 2026, Kroah-Hartman posted a slide from his talk showing how many vulnerabilities are fixed in each release. From version 6.9 to 6.19 it is about five hundred per release; from 7.0 more than a thousand; in 7.2 more than fifteen hundred. At first glance this looks like a fourfold degradation of the kernel. Asked whether these were new vulnerabilities or old ones, the maintainer answered with a single word: "Fixed." The chart counts fixed bugs, and what grows is precisely what used to be found poorly. That same linear surplus which gives us an extra quarter of work per release appears on this chart as a sharp step.
The second tally, independent of anyone else's chart, we took ourselves, and it agrees with the first. On September 14, 2026, seven stable kernels came out at once. Together they contained more than nine thousand patches, of which 1,816 fell on 7.2.6 alone and 792 on the oldest, 5.10.270. Kroah-Hartman noted that this batch may set a record.
The rhythm of releases holds, and the work inside them grows.
5. A Counterargument Worth Respecting
The Chrome browser may look like a refutation of this theory. Versions 149 and 150 fixed 1,072 bugs, more than the previous twenty-three milestones combined. Chrome 151 closed another 370 vulnerabilities, 94 per cent of them found by Google's own team. One of them, a sandbox flaw in Navigation, had lain in the code for thirteen years. Neither the automated analyzers nor the reviewers found it; an AI agent did. Among those 370 is one already entered in CISA's list of known exploited vulnerabilities — that is, attacked before the patch shipped.
If the system produces fixes at that speed, where is the problem?
The problem is where the fix never reaches the user. Chrome has one vendor, one build and an auto-update mechanism, so there the promise is kept. Android is built differently. A fix travels from Google to the device maker, then to the carrier, and at every step it can be delayed, altered or never delivered at all. According to GrapheneOS, from Android 16 the first and third quarterly releases go only to Pixel, and the September update for Pixel contains fixes to common platform components that appear neither in the public bulletin nor in the advance patches for partners. The other manufacturers will receive them in December.
To be fair: Google itself built the bypass around this chain. Some system components are delivered to the device directly, through the app store, skipping the manufacturer — like letters carried by one's own courier rather than the public post. The road is narrow: the updatable modules cover far from everything, and the kernel and drivers remain outside its scope. The exception confirms the rule: where Google can haul a patch to the device itself, it does; where it cannot, what remains is a list with a date.
They will say Apple runs the same logic, and nothing happens. True, vertical integration buys a delay, because the patch reaches all devices at once. But a delay is not a repeal. The same arithmetic of finding and fixing operates there too; it is simply paid by one vendor rather than a chain of intermediaries. And even there, a 2021 device receives today's kernel patches only because the maker decided not to close the branch. The decision was taken silently, and it repeats the case of the 5.10 and 5.15 branches exactly.
6. The Camps
Around this gap, camps of opinion immediately formed. Some accuse Google of lying; others believe the Rust language will fix everything; still others call for building one's own operating system; a fourth group pins its hopes on artificial intelligence. Each has its own simple story and its own share of truth. By Kroah-Hartman's estimate, about 80 per cent of kernel vulnerabilities would have been impossible with Rust. That is an enormous share, but the argument would not be settled even if it were all about the programming language.
The same post adds a detail that flips the familiar picture: from the full set of fixes, only what is deemed an immediate threat is selected into the old branches; the rest stays in the newest releases. Branches with formally live support get the crumbs from the table, and no one is obliged to announce it in plain words.
All these camps are arguing about the same thing: who will apply the next patch, and how fast. Rust cures new code, but tens of millions of lines of old code remain, and the window of exposure stays open for years. Building one's own operating system merely changes who does the patching. None of these approaches answers the main question: what do you do when the price of finding has fallen and the price of fixing has not.
7. The Audit That Cannot Be Forged
The answer that survives the arithmetic changes not the speed of fixing but the cost of each individual error.
In a monolithic kernel a driver runs with full rights, so a hole in a Wi-Fi driver is equivalent to full control of the device. In a microkernel the driver is an isolated service holding only the rights it was granted, turning a break-in from a single step into a complicated chain of actions. Hardware capabilities carry the same idea into the silicon itself. A pointer ceases to be merely a number and becomes an unforgeable token with hard boundaries checked by the processor itself. Some of these mechanisms are already present in modern phones as pointer authentication, branch target marking and memory tagging. They are bypassed, but each bypass costs more. This is not a full replacement for the barrier, only its necessary first layer.
Cybernetics calls this approach attenuation — weakening the disturbance at the input. Ashby's law requires that the variety of the regulator be no less than the variety of the disturbances. The patch model tries to win by strengthening the regulator, but human throughput does not scale. The barrier weakens the disturbance itself, damping out a whole class of attacks at the entrance.
8. The App as a Recipe
Until now we have talked about how fixes reach the kernel. But the gap between the list and life does not end at the kernel — it repeats one floor up, where the application lives. If the thesis is right and the list cannot be fixed, the question becomes how services will live on a device where code has no rights by default. This is a forecast, but it has precise mechanics, and every link in it has ancestors alive today.
The unit of delivery is changing. Today a bank or a messenger ships a finished binary containing who knows what, and trust rests entirely on the app store and the brand's reputation. In the new scheme, the service publishes a contract that spells out its capabilities, its requirements of the client, and the paths data travels. The device assembles its client portion for itself out of a small set of verified components. The app ceases to be a finished good and becomes a recipe. Ancestors of this idea already exist: mini-programs inside super-apps like WeChat, capability manifests in Fuchsia, WASI components, and the European PSD2 standard, which forced banks to open their interfaces to third-party clients.
The assembled client is a generated shell endowed with exactly the rights the kernel granted and not one more. It acts as a conductor without power of its own: it may rearrange the blocks, but it cannot grant itself new authority. The user remains sovereign over the shell's appearance. If you want kittens to bloom across the screen after every purchase, that is your personal business — it is your screen and your living room. But the word "pay" means exactly what the contract says. The amount and the recipient are shown not by the generated shell but by the trusted layer of the kernel, like a hardware wallet. Whatever the generator draws, it cannot control the last half meter from the fingertip to the digital signature.
Picture the purchase as a queue at a Soviet savings bank, out of the Prostokvashino cartoon. To collect a parcel or pay for a service you must pass three windows, and you cannot jump over anyone's head. The first window, which handles the choice of goods, stamps your form. The second window checks the prescription or the age, verifies the data and sets the second stamp. Only the third window, the cash desk, takes the money — and strictly on condition that both previous stamps are on the form.
The role of the operating system here is played by the stern but fair postman Pechkin. He does not meddle in your affairs until you show the required certificate. If the generated shell tries to forge the form or draw in an extra digit, Pechkin simply refuses the document. There are no intricate hashes or puzzling templates here. There is only a strict, legible order of stamps that cannot be violated. You are sovereign in your living room, but the rules of the game are guarded by an invisible and unyielding notary.
The make-up of the chain depends on the purchase. A medicine needs a prescription check; socks do not. The make-up itself is part of a public template that is easy to check, and quietly adding an extra link is impossible. The operating system acts as notary between the user's intent and the outside world. The artificial intelligence formulates the intention; the kernel carries it through the certifying offices and releases no action without the full set of stamps.
Each service is audited not on its source code but on its interface — a short machine-readable contract. That is cheap and transparent. A bank may rewrite its server every week as long as the contract stays untouched. The difference between versions — an added endpoint, a widened field, a new data flow — reads by eye. A strict client discards everything absent from the contract and logs the divergences, turning undeclared behavior into incontrovertible evidence. The certificate is made short-lived, so an outdated check rots on its own without demanding complex revocation. For services without a certificate there remains a sandboxed branch with minimum rights and an explicit warning — otherwise the scheme turns into a walled garden.
The main objection here concerns not the technology but the economics of the funnel. An app is not just an interface; it is a funnel through which the service sells, retains users, shows advertising and nudges toward profitable actions. A user's own AI, which discards all of that and shows the bare essence, takes away the service's main source of income. The reaction is predictable: close the API, throttle the request rate, or demand client attestation — restoring exactly what the scheme tries to eliminate. So the right to an open interface will most likely be secured by regulation, like number portability with carriers or PSD2 for banks, rather than grow out of technical solutions. It will happen first where the regulator is already the master: banking, payments, healthcare. The rest will dig in for the fight over the funnel.
I would predict not the disappearance of apps but a split into three layers. Regulated services — banks, government portals, medicine — will move first, since they already have the contract, the regulator and legal accountability. Open protocols, such as messengers with unofficial clients, will move second, because the scheme merely automates what people already do by hand. The rest, living off the funnel, will remain apps the longest and will resist until the law intervenes. The app will die as a good, but survive as the service's obligation to its own contract.
The honest caveat is that the certificate confirms only the client's inability to do anything beyond the contract. What the bank does on its side it will not vouch for — never will. The scheme protects the keys, the session and the interface on the device; the honesty of the server remains a different line of defense.
9. Who Is the Inspector
Every audit comes up against the question of who conducts it, and here the scheme meets politics. Banks are regulated by the state, so the state will issue a bank's certificate. International services would need an international body, which does not exist. If the state signs both legality and security, then the principle "everything not permitted is forbidden", conceived as protection of the user from the service, turns into protection of the state from the user. It would take only a demand that the certified feature set include a lawful-access channel, and the device would by default assemble only such clients.
There is one defense here: split the two axes. Legality is decided by the state; security is signed by independent parties; and everything is kept in a public log, on the model of Certificate Transparency. The state will be able to ban a service, but it will not be able to slip an extra line into it unnoticed, because any change to the contract becomes a public fact.
Regulators are already trying to nail the promise down in law. The European Cyber Resilience Act, from September 11, 2026, requires manufacturers to report an actively exploited vulnerability within a day, provide a full notification within three days, and a final report two weeks after the fix ships. Fines reach 15 million euros. But the law requires disclosure of information, not delivery of a fix. It will not carry the correction to the phone in your hand.
10. Finale
Let us return to Chichikov. His swindle held until the audit. While the list was counted as living, the dead souls brought in money. The bulletin and the patch-level date work exactly the same way. While a person believes the list, the gap between the list and life remains that person's risk, not the vendor's.
The authors of that same post ended it with the thought that Google wants the user to feel safe. In that phrase the construction stands fully revealed: a feeling of security is delivered as a product, separately from security itself. Gogol would have said the same without any technical terms.
You cannot mend this with a patch, because a patch is another entry in the same list. The only way is to replace the audit with one where protection is not promised but verifiable. The device must not take anyone's word — not the vendor's, not the service's, not its own app's — and every seal must be visible to all in a public log.
Dead souls cannot be resurrected. One can only stop carrying them on the list of the living.
The road runs from correct code to verifiable code.