LPC slides put 191k Sashiko reviews and 463 CVE cites on the board. Boro stays a local CLI

What was on the LPC 2026 timetable?

Linux Plumbers Conference 2026 ran 5–7 October in Prague. Contribution 2645 lists “Sashiko current status” on 6 October at 10:00, 45 minutes, in Club H, in the AI-Assisted Open Source Development microconference. The speaker is Roman Gushchin (Google). The attached deck is “Sashiko - LPC 2026 (1).pdf.”

Contribution 2599, same room at 12:00, is Andrea Righi (NVIDIA), “Boro: Do We Need More AI-assisted Kernel Tooling?,” 15 minutes. Righi’s abstract calls Sashiko “the de facto standard for reviewing publicly posted patch series on mailing lists,” then says that design is a weaker fit for backports and distro kernels. That ranking is his conference text. We opened the two talk pages, both PDFs, the READMEs, and sashiko.dev. We did not attend.

What numbers did the Sashiko slides print?

The March–October 2026 scale slide prints 191,000 reviews across 99 lists, about 37,800 a month, 19.3 million git lookups, and 697.7 billion tokens with 83.1% from cache. p90 single-patch turnaround is printed as 4.0 hours to 15 minutes; series as 14.7 hours to 27 minutes. Those are Gushchin’s figures. For how to keep a slide total in its column, see how to read an AI company announcement.

Impact slides add 7,635 In-Reply-To replies from 1,158 developers across 4,212 threads, 1,277 linus/master and 1,567 linux-next cites via Reported-by, Closes, or Link, and 463 “2026 Linux kernel CVEs whose fix commit cites Sashiko.” A later community slide prints 96 mailing lists rather than 99. We did not reconcile the two. AI Tamer’s 8 October note restates 191,000 / 1,277 / 463 from the same deck. It is a secondary reading, not a second measurement.

How does Sashiko say the review works?

The architecture slides call Sashiko an agentic harness whose goal is to stop new issues entering the kernel. Code is Rust, Apache-2.0, donated to the Linux Foundation; sashiko.dev is “sponsored by Google.” Outbound LKML-style mail is opt-in. Prompt injection is named as a reason to keep a dedicated harness — the same class of risk as our prompt-injection explainer, applied to review mail rather than a consumer chatbot.

The pipeline slide splits discovery from verification. Stages 1–7 emit concerns; stages 8–9 are new deduplication and post-verification; stage 10 emits findings with a severity. A concern becomes a finding only if it survives falsification against the tree. The README credits per-subsystem prompts to Chris Mason’s review-prompts repository.

The README, which the slides also show, benchmarks 1,000 upstream commits that later gained a Fixes: tag. With Gemini 3.1 Pro, Sashiko “detected 53.6% of bugs that had originally passed human review.” Manual sampling puts false positives under 20%. Output “may vary across runs.” Those are the project’s scores. A method for reading that kind of self-benchmark is evaluating AI agents.

What is new on the LPC slides is local use: cargo install sashiko, then sashiko review against a worktree. The README warns that patch text and surrounding files go to the configured LLM provider. A bug-database slide prints 9,117 open bugs from 14 September to 5 October 2026. “Sashiko for Sashiko” reviews its own GitHub PRs at sashiko.sashiko.dev, “still tuning.” A later slide adds sashiko review --agent.

What is Boro, and what did NVIDIA propose?

Boro’s abstract and README describe a local-first CLI for backports, distro kernels, security-fix integration, and work that has not reached a public list. It shares Sashiko’s review prompts. Slide commands are boro review, boro build, and boro test on a BASE..HEAD range.

BORO_MODEL does discovery; BORO_VALIDATION_MODEL does a fast complete-context review, adjudication, and the LKML-style report. The intended split is a cheap or local model for discovery and a stronger model for the baseline. Build and test use virtme-ng. Out-of-tree module breakage is TODO.

Righi proposed folding backport follow-up tracking, the two-model split, and virtme-ng build/boot into Sashiko, and asked whether upstream submissions should include a local AI review. A WIP slide prints an 82.4% expensive-token saving for a Gemma-4 plus Nemotron mix. That table is a speaker slide, not a paper we reproduced.

Boro is not a hosted scanner and not a coordinated-disclosure inbox. For a different 8 October product that emails maintainers model-written vulnerability reports, see Anthropic’s OSS Scanner. That service is opt-in mail from Anthropic. Boro is a CLI you run in your own tree.

What limits do the authors already list?

Gushchin’s known-issues slide: large-change reviews are worse; it keeps finding issues on unchanged v2/v3 code; “Clean pass != bug-free”; it still hallucinates; Sashiko has bugs too. Impact slides add that Sashiko is six months old, that Alexei Starovoitov is quoted asking authors to drop Reported-by: Sashiko, and that a fix’s cause is often unclear.

The README warns that local review sends patch data and surrounding files to the configured provider, and that multi-stage reviews “can incur significant API costs.” A “what’s next” slide mentions Gemini 4 Argon as “coming soon.” We did not treat that as a release. A Torvalds quote on trust sits on the deck; we did not open the original interview.

What did we not verify?

We did not recount vulns.git, rerun the Fixes: benchmark, sit the talks, or install either CLI. A Phoronix URL that other aggregators pointed at returned HTTP 403 here, so it is not a source. Treat 191,000 and 463 as Gushchin’s 6 October accounting until someone publishes a reproducible recount.