DEV Community

Cover image for ParticleDB's Jepsen report, Lenovo's fingerprint USB stick, Karpathy's HackerTube and the Linux TCP bug CVE-2026-98432
Nikoloz Turazashvili (@axrisi)
Nikoloz Turazashvili (@axrisi) Subscriber

Posted on

ParticleDB's Jepsen report, Lenovo's fingerprint USB stick, Karpathy's HackerTube and the Linux TCP bug CVE-2026-98432

#security #linux #database #news

Four developer stories from Sunday, November 1, 2026, each read from its own source. The first is a database whose home page said Full ACID. The video has the walkthrough; this article keeps the quotes, numbers and links in one place.

TL;DR

  • Jepsen's analysis of ParticleDB found 96 issues in versions 1.1.4 through 1.1.18.11.rc-22. In the last version it tested, the default transaction mode still lost committed writes. Jepsen recommends users halt further deployment and migrate. Orkes funded the test.
  • Researcher Xusheng Li found that the Lenovo ThinkPlus FU100 fingerprint USB stick, sold as AES-256 hardware encrypted, held an ordinary SD card with nothing on it encrypted.
  • Andrej Karpathy built HackerTube, a site of 6,454 videos recommended in Hacker News comments, in about two hours.
  • Linux kernel CVE-2026-98432 is an IPv4 TCP use-after-free scored CVSS 9.8. Install your distribution's fixed kernel and reboot.

ParticleDB: what Jepsen found

Jepsen, the database testing lab run by Kyle Kingsbury, published its analysis of ParticleDB 1.1.4 on October 31, 2026. ParticleDB is a Rust database from Orkes, built for AI workloads, with a Postgres-compatible interface, key-value, vector search and user-defined functions. Orkes built it to support its Conductor workflow platform. Only single-node behavior was tested, because the builds Jepsen received had no replication.

The report opens with its summary: "We tested versions 1.1.4 through 1.1.18.11.rc-22 and found that ParticleDB's claims of 'Full ACID' were somewhat premature. We present 96 issues in ParticleDB." It also states that "This research was funded by Orkes, Inc., and conducted in accordance with the Jepsen ethics policy."

The home page claimed "Full ACID. 159K TPS." and said the database was "formally proven" with a TLA+ proof. Jepsen reports that no TLA+ specification was available during the collaboration, and that the text directly under "Full ACID" said snapshot isolation, which is not fully isolated. Isolation was also controlled by a startup flag, --txn-mode, because the database ignored or rejected the usual SET TRANSACTION ISOLATION LEVEL statements.

Most of the issues "required just a single server, single client, and no faults." Examples from the report:

  • WHERE 4 = 5 returned rows with primary key 5 (issue 18).
  • WHERE TRUE matched nothing (issue 35).
  • An UPDATE could leave multiple rows with the same primary key (issue 29).
  • Rows from dropped tables could re-emerge in mangled forms (issue 46).
  • Aborted transactions could commit, or fail with their effects still visible (issue 43).

By 1.1.18.11.rc-22, all but ten of the 96 issues appeared resolved. Two serious ones remained. In the default occ transaction mode, ParticleDB "regularly lost data in normal operation", and the strictest serializable mode still allowed Lost Update and internal anomalies when Jepsen killed the process. Orkes has released 1.1.19-rc.13 and says it resolves all remaining issues. Jepsen has not evaluated it.

Orkes believes the problems came from a major refactor in spring 2026 and that its own customers, who stayed on an earlier version, were likely unaffected. Jepsen briefly looked at an internal 1.0.0 build and says it did not seem susceptible to most of the serious safety errors. From May through July 2026, the download page offered versions 1.1.4 through 1.1.18.11.rc-18, and all of them had serious safety errors in normal operation.

Jepsen's conclusion: "Jepsen recommends users halt further deployment of ParticleDB and migrate to other databases as soon as possible." It also advises checking or rebuilding database state from more reliable sources if available.

The documentation findings are in the report too. The Java client docs referred to dependency coordinates that do not exist, and the stored procedure documentation "even fabricated an imaginary email address for the author of this report." After the testing, Orkes labelled the transaction modes experimental and described versions 1.1.4 through 1.1.18.11.rc-22 as "unsupported pre-release builds." Jepsen points out that the Docker install page told users how to deploy those versions "for production."

What to do: if you evaluate a new database, run your own tests of the isolation level it claims, and treat a missing specification behind a "formally proven" banner as a missing specification.

Lenovo's fingerprint USB stick

Security researcher Xusheng Li found that the Lenovo ThinkPlus FU100, sold as an AES-256 encrypted device, was "just a plain SD card internally," according to Tom's Hardware, which reported on research first published by HackingPassion. The fingerprint reader only enabled the USB connection, and nothing on the card was actually encrypted. Li used the phrase "just an SD card in a fancy case" in a March 2026 conference talk.

The timeline from the HackingPassion write-up: Li reported the flaw to Lenovo on August 2, 2025. On August 27 a temporary fix was ready, a layer of epoxy over the SD card. Lenovo rated its advisory high. A later fix for the FU100, FU200, TU800 and the TSD303 SSD requires owners to call a service line in China and then either send the device back for replacement or get an on-site firmware upgrade. Lenovo advises backing up data and strongly recommends wiping the drive before sending it in.

Li also looked at the TSD303 external SSD, whose data was encrypted but whose drive sent the correct password back over USB in plain text for the software to compare. The first fix derived a key from a timestamp-like value. The later fix has the drive check the typed password itself.

Last week, Tom's Hardware reports, Li pointed OpenAI's Codex, together with his employer's reverse engineering tool, at other makers' USB protection software. Netac's tool took about seven minutes to break, because it had a fixed key built in and wrote the user's password to diagnostic logs. KakaSoft's took about 26 minutes and Nexcopy's about 10. SecZure's YutianDun has two hidden accounts with simple passwords that Li describes as backdoors.

What to do: encrypt files with software you control, such as full-disk or container encryption you can inspect, before they reach any USB stick. Treat a fingerprint reader as a convenience.

HackerTube

On Friday night, Andrej Karpathy wrote, he opened YouTube and "realized that I was looking at an enshittified wall of slop." On Saturday morning he gave his coding agent the task of writing a YouTube clone from whatever videos have been recommended on Hacker News.

According to his post, the agent downloaded all Hacker News comments, filtered them, and ran Sonnet over them in a Claude Code Workflow to remove spam. That left about 40,000 comments recommending a YouTube video: 6,454 videos recommended by a few people on Hacker News from 2007 to 2026, across 150 topics. The site, hackertube.org, has recommendations without user accounts, keyboard shortcuts and a data export, and shows the frame at the 50 percent mark instead of the uploaded thumbnail. Karpathy writes that the build "takes ~2 hours now." His manual steps were a Google Cloud API key for video metadata, a VPS and a domain name.

The post passed 1,800 points on Hacker News within a day, and a spin-off, HackerBooks, appeared for books recommended on Hacker News. On October 12 we covered Karpathy's argument that access and tasks create a gap in how people understand these tools; a working site built in two hours is one more data point.

Linux CVE-2026-98432: patch and reboot

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake. The kernel CNA scores it CVSS 3.1 9.8. The fix, by Eric Dumazet, is titled "ipv4: free inet_opt and ireq_opt after an RCU grace period" and changes plain kfree() calls to kfree_rcu(); the commit is dated October 1, 2026. The Ubuntu CVE page quotes the description: a race between a retransmitted SYN and the freeing of a child socket's IP options.

Stable kernels with the fix shipped on October 11 and 15, and the CVE was published on October 15. Per the Atlas write-up, the bug goes back to Linux 4.4. Red Hat raised its rating from Important to Critical on October 30 in bulletin RHSB-2026-016, which says "Red Hat is expediting the release of fixes." On Saturday evening, October 31, Ubuntu's tracker listed every release as vulnerable and RHEL 8, 9 and 10 had no fixed kernel, while Debian, SUSE, Oracle UEK and Amazon Linux had fixes and AlmaLinux had fixed kernels in testing.

Anthropic's October 27 post says its model "wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction." In its proof of concept, "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution." Anthropic has not published the exploit. The Go Security Team notes that as of Go 1.24, Go programs enable multipath TCP for listen sockets on Linux by default, and warns that "the underlying bug is not specific to MPTCP", so systems without such a listener may still be vulnerable to similar attacks.

What to do:

  1. Install your distribution's fixed kernel and reboot. Do this on container hosts and Kubernetes nodes as well, because containers use the host kernel.
  2. If your distribution has no fixed kernel yet, Red Hat and AlmaLinux publish a firewall rule that drops incoming IPv4 TCP packets carrying IP options. Red Hat says it reduces exposure and is not a substitute for patching.
  3. Patch hosts that run multipath TCP listeners first.

Verdict

REVERT: halt ParticleDB deployments per Jepsen's advice, and patch that kernel.

Sources

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources

Top comments (0)