SM-023 {title}

Markovian ProtocolMeasured {S['read_at'][:10]}Status: draft, not publishedDOI: {DOI}

The short version

Canonical, in the Ubuntu Pro FAQ, answered by a Canonical staff member: “critical vulnerabilities are released within 24 hours. Then, on average, high CVEs are patched within 30 days, and medium CVEs within 60 days since they are known to the Ubuntu Security Team. This criteria applies to every package affected by the vulnerability, across every Ubuntu release actively supported.”¹ The Ubuntu Pro general-availability post: “critical CVEs patched in less than 24 hours on average.”²
“Critical” is the Ubuntu Security Team’s own priority, which Ubuntu says is “distinct from other published severity levels such as CVSS base scores”.³ We read all {S['total_critical']} vulnerabilities Ubuntu rates critical from its CVE API; from the team’s public tracker, ubuntu-cve-tracker, the commit that first set each one’s Priority: line to critical; and the first fix that reached users, the earlier of its first security notice (USN) and the day the fixed package was published to the archive.⁶
{CV['n']} kernel vulnerabilities were raised to critical from a CVSS score. Every one was recorded as medium, and between {S['cvss_first_raise'][8:10].lstrip('0')} June and 18 October 2026 a tracker commit raised it to critical with the note “Priority reason: See ubuntu cvss score” and an Ubuntu CVSS v4 score of 9.1 to 9.4, in batches: {', '.join(f"{v} in {MONTHS.get(k, k)}" for k, v in S['cvss_raised_by_month'].items())}.
{CV['fixed_before_start']} of them were already fixed when they were raised, and one ({S['cvss_never_affected'][0]}) affects no Ubuntu release. Of the other {missed}, none was fixed within 24 hours: {CV['measured']} were fixed {d(CV['median_d'])} after being raised at the median, none within a week, the longest after {d(CV['max_d'])}; {notfixed} were still waiting when we read them, {min(S['no_fix_open_pro_days_since_raise']):g} to {max(S['no_fix_open_pro_days_since_raise']):g} days after being raised.
The {HD['n']} the team rated critical by its own judgement are mostly older. {HD['fixed_before_start']} were fixed before the tracker first marked them critical, most of them because they were first entered in the tracker, already critical, after the fix; of the {HD['measured']} that can be timed, {HD['within_1d']} were fixed within a day.
Across every release: of the {S['fixed_kernel']} critical kernel vulnerabilities with a fix somewhere, {SP['n']} still show the main linux package as needed or pending on a release in standard or Ubuntu Pro support (read {S['read_at'][:10]}).
On 23 September 2026 Canonical announced a move to a single two-week kernel update cycle and said its aim is “to get environments into a defensible, safer state within 24 to 48 hours of public disclosure – well before a patch ships.”⁴ The FAQ still says 24 hours for the patch.

Disclosure: Markovian Protocol holds no financial position in Canonical, was paid by no one for this work, and showed it to no one before publication. How we work.

Critical by judgement and critical by CVSS

How the priority was set	Critical	Fixed	Fixed before rated critical	Timed	Within a day	Within a week	Median wait
By the team’s judgement	{HD['n']}	{HD['fixed']}	{HD['fixed_before_start']}	{HD['measured']}	{HD['within_1d']}	{HD['within_7d']}	{d(HD['median_d'])}
Raised from medium on a CVSS score	{CV['n']}	{CV['fixed']}	{CV['fixed_before_start']}	{CV['measured']}	{CV['within_1d']}	{CV['within_7d']}	{d(CV['median_d'])}

Wait = first fix reaching users minus the first commit that set the vulnerability’s Priority: line to critical in ubuntu-cve-tracker. First fix = the earlier of the first USN and the first publication, in the Security, Updates or Release pocket and on or after that release’s own release date, of the fixed version the tracker lists for any release: the main linux package for kernel vulnerabilities, the vulnerability’s own package otherwise (Launchpad publishing history; versions kept in Ubuntu Pro’s private archive cannot be dated and are left out). “Fixed before rated critical” = a negative wait, left out of the timed columns. Livepatch notices (LSNs) exist for {S['lsn_cves']} of these vulnerabilities; none came before the first fix, so counting them changes nothing. Read at {S['read_at'][11:16]} UTC on {S['read_at'][:10]}.

Other start times

For the {CV['n']} raised on a CVSS score, other starts give longer waits, because they include the time each spent at medium, for which the FAQ’s figure is 60 days:

Counting a new release that came out after a vulnerability was raised, already carrying the fix, as a fix on its release date changes nothing: {CA['timed']} timed, {CA['within_1d']} within a day, median {d(CA['median_d'])}. {S['cvss_never_affected'][0]} is left out of every count of waits, since no Ubuntu release carried it.

Every supported release

Clock starts when	Timed	Within a day	Median
the vulnerability was published	{CP['measured']}	{CP['within_1d']}	{d(CP['median_d'])}
the team first recorded it (at medium)	{CK['measured']}	{CK['within_1d']}	{d(CK['median_d'])}
the team raised it to critical (used above)	{CV['measured']}	{CV['within_1d']}	{d(CV['median_d'])}

The FAQ applies the 24 hours “across every Ubuntu release actively supported”. On {S['read_at'][:10]}, {len(S['standard_releases'])} releases are in standard support and {len(S['pro_releases']) - len(S['standard_releases'])} more in Ubuntu Pro (ESM): {', '.join(rn(r) for r in S['pro_releases'])}. Of the {S['fixed_kernel']} critical kernel vulnerabilities with a fix somewhere, {SP['n']} still show the main linux package as needed or pending on at least one of them:

Only the main linux source package is counted, not the dozens of kernel variants. “Pending” means a fix is prepared but not yet released. {', '.join(rn(r) for r in S['legacy_releases'])} are now covered only by the paid Legacy add-on, not Ubuntu Pro, and are left out above; on them {SL['n']} of the fixed critical kernel vulnerabilities are still open.⁵

Another {notfixed} critical kernel vulnerabilities had no fix released for the LTS releases that still need them on {S['read_at'][:10]}, {min(S['no_fix_open_pro_days_since_raise']):g} to {max(S['no_fix_open_pro_days_since_raise']):g} days after they were raised to critical. One of them, CVE-2023-53867, is already fixed in the kernels 24.04 and 26.04 LTS shipped with; it is still needed on 18.04, 20.04 and 22.04 LTS.

What Canonical announced in September

Canonical’s post of 23 September 2026 outlined “a transition from its current 4-week regular and 2-week security kernel Stable Release Update (SRU) cycles to a unified, rapid 2-week SRU cycle, published weekly”, with no date given for the change, and said that while a patch is prepared “Canonical aims to provide safe workarounds where applicable”.⁴ It went on: “Where no safe workaround exists, Canonical will say so clearly and point users toward general hardening steps instead.” Since that post, two vulnerabilities now rated critical were published; both were recorded as medium and raised to critical on 18 October 2026, two days before our read. On {S['read_at'][:10]}, CVE-2026-93221 had a fix pending for 26.04 LTS and still needed for 20.04, 22.04 and 24.04 LTS; CVE-2026-98365 had fixes pending for 24.04 and 26.04 LTS and still needed for 18.04, 20.04 and 22.04 LTS. 26.10 already ships a kernel containing both fixes. Neither had a USN, the mitigation field on each CVE page was empty, and searching Canonical’s blog, Ubuntu’s security notices and Ubuntu’s Discourse forum for each CVE found neither a workaround nor a statement that none exists (workaround_search_2026-10-20.json). On {S['read_at'][:10]}, Ubuntu’s web pages for both, and for CVE-2026-89530, still showed “Ubuntu priority Medium” (last updated 8 October, 25 September and 6 October) while Ubuntu’s CVE API and tracker said critical (saved pages: 98365, 93221, 89530).

How this ends

Canonical can close it three ways: ship CVSS-rated critical kernel fixes within 24 hours; stop rating kernel vulnerabilities critical from a CVSS score alone, so that “critical” means what the team judges critical; or change the FAQ to say what kernel users should expect. We recheck monthly and print the table here.

Our questions to the Ubuntu Security Team

Their reply, scored

What we can’t be sure of

Run it yourself

Needs Python 3 and git; Ubuntu’s CVE API and Launchpad’s are anonymous. The tracker clone takes a few minutes; known_dates.py about two, crit_dates.py about 35, since it fetches each file’s history. Scripts and exhibits: sm-023/.

{title}