DEV Community: Joho no Todai

Linux Kernel TCP Flaw Scores CVSS 9.8 as Anthropic AI Demonstrates Root Access in 53 Minutes

Joho no Todai — Sat, 31 Oct 2026 15:00:10 +0000

CVE-2026-98432, a CVSS 9.8 vulnerability in Linux kernel TCP code, has been confirmed, with an unreleased Anthropic AI model demonstrating unauthenticated root access in 53 minutes. Ubuntu and RHEL patches remained unavailable as of October 30.

Key points

What happened: CVE-2026-98432, a CVSS 9.8 use-after-free vulnerability, was confirmed in Linux kernel TCP code, and Anthropic's AI demonstrated remote code execution as root in 53 minutes
Who is affected: Linux servers using kernel 4.4 or later are affected. Services built with Go 1.24 or later enable MPTCP listeners by default and may become targets unintentionally
How to defend: Debian and Oracle Linux have fixes, but Ubuntu and RHEL patches were unavailable as of October 30. Blocking TCP packets containing IP options with nftables is recommended as an interim measure
What is changing: AI independently building a complete attack chain that bypasses kernel memory protections demonstrates that exploit development, not just vulnerability discovery, can now be automated

CVE-2026-98432, a CVSS 9.8 vulnerability, has been confirmed in Linux kernel TCP code. An unreleased Anthropic AI model demonstrated unauthenticated root access in 53 minutes. Ubuntu and RHEL patches remained unavailable as of October 30.

CVSS 9.8: a flaw at the heart of TCP

A CVSS 9.8 use-after-free vulnerability has been confirmed in the Linux kernel's IPv4 TCP connection handling. Its identifier is CVE-2026-98432. NVD published the CVE record on October 15, local time, and both kernel.org and cve.org assess its vector as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network-accessible, low attack complexity, no privileges required, and no user interaction. Confidentiality, integrity, and availability impacts are all high.

The core issue is a race condition during TCP connection establishment.

When the TCP three-way handshake completes, the kernel transfers ownership of IP options associated with the incoming connection request to a new socket, the communication endpoint. However, it moves only the pointer, the memory address, rather than copying the option data. If another CPU core simultaneously handles a retransmitted SYN packet for the same request, it reads memory already transferred to the new socket and freed at its original location. This produces a memory safety flaw known as use-after-free.

I confirmed that the kernel patch was written by Google's Eric Dumazet after a report from Anthropic's Xinyang Ge, committed on October 1 and merged on October 5, local time. The two-line change replaces kfree() with kfree_rcu(), delaying memory release until other CPUs finish reading the options under RCU (Read-Copy-Update), the kernel mechanism that waits for readers to finish before freeing data.

The vulnerability affects all Linux kernel versions from 4.4, released in 2016, onward. Equivalent IPv6 code copies the options, so only IPv4 is affected.

An AI-written exploit in 53 minutes

On October 27, local time, Anthropic published findings from using an unreleased internal research model to discover and demonstrate vulnerabilities in major software. The CVE-2026-98432 exploit was reported as one of five demonstrations, alongside attack chains targeting Chrome, Safari, the Android lock screen, and Windows.

According to Anthropic, after an initial prompt, the Claude model independently built an exploit achieving unauthenticated command execution as root, without user interaction, on a Linux server running an MPTCP (Multipath TCP) listener. MPTCP allows one TCP connection to use multiple network paths simultaneously.

The attack has two stages.

The first exploits the race condition to bypass KASLR, Kernel Address Space Layout Randomization, which randomizes kernel code and function locations to prevent attackers from predicting them. By making the kernel read an attacker-controlled length field, it causes more bytes than intended to be returned. If the response contains kernel pointers, the kernel memory layout becomes known. This stage took 48 minutes.

The second uses the same use-after-free to overflow a buffer and overwrite a callback pointer, the address of the next function the kernel will invoke, with the address of an attack payload previously placed in kernel memory. When the kernel calls that pointer, the attacker's specified shell command executes as root. This stage took another five minutes, achieving remote root access in 53 minutes total.

The race has a useful property for attackers: losing it causes only one handshake to fail, without crashing the system. Attackers can retry until they succeed.

Anthropic has not released the exploit code, tested kernel version, or test environment configuration. The discoveries were reported to vendors under Anthropic's coordinated disclosure policy, which gives developers 90 days for fixes and another 45 days before detailed publication.

MPTCP may be running without administrators realizing

Anthropic demonstrated root-level remote code execution only on a server running an MPTCP listener. The same attack has not yet been demonstrated on servers without such listeners.

However, administrators cannot necessarily assume MPTCP listeners are absent from their servers.

Since Go 1.24, TCP listeners enable MPTCP by default when the kernel supports it. Network services written in Go may therefore start MPTCP listeners without administrators realizing.

In an October 29 statement, local time, the Go Security Team described disabling it at runtime with GODEBUG=multipathtcp=0, or at build time through the go.mod file by adding godebug multipathtcp=0. Code calling SetMultipathTCP overrides either setting, however.

The Go Security Team also called per-program MPTCP disabling a fragile mitigation. A single remaining MPTCP listener leaves the system vulnerable, and because the underlying bug is not specific to MPTCP, systems without MPTCP listeners may also be vulnerable to similar attacks. It said upgrading to a patched kernel is the best defense.

The same problem can also arise with TCP request socket migration, when net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is used.

Figure omitted — see the original article

Patch status and interim defenses

The vulnerability is fixed upstream and backported to all maintained stable kernel branches. Distribution availability varies.

Debian responded quickly. Its security tracker lists fixes in kernel package 6.1.190-1 for Debian 12 (Bookworm) and 6.12.113-1 for Debian 13 (Trixie). Fixed packages are also available in testing and unstable.

Ubuntu had no fix available as of October 30. Canonical's tracker lists 22.04 LTS, 24.04 LTS, 26.04 LTS, and 26.10 as vulnerable, with kernel fixes in progress.

For RHEL, Red Hat initially rated the issue 5.9 (Moderate), but the situation has changed. On October 30, local time, Red Hat published security bulletin RHSB-2026-016, rating the impact Critical and working to expedite fixes. Its CVE page now displays CVSS 9.8. RHEL 8, 9, 10, and OpenShift Container Platform are affected. RHEL 7 lacks the vulnerable code and is unaffected.

For context on these changing ratings, Red Hat's CVE page initially showed 5.9 (Moderate), its machine-readable advisory showed 8.1 (Important), and its bug tracker changed from medium to high on October 29. The October 30 bulletin raised the rating to Critical.

For Rocky Linux, support provider CIQ confirmed impacts on versions 8, 9, and 10 and shared an interim firewall mitigation.

Oracle Linux, Amazon Linux, and SUSE have released fixes for some affected kernel versions.

Interim defenses

For environments awaiting patches, Red Hat's bulletin provides a specific nftables rule. It drops incoming IPv4 TCP packets whose IP header length exceeds the standard five, meaning options are present, before they reach the vulnerable TCP processing code.

table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }

Red Hat says effects on normal application traffic are generally not expected, while advising administrators to review their own traffic and requirements before applying it.

Importantly, disabling MPTCP alone is insufficient. Ordinary TCP traffic can trigger the underlying vulnerability, so turning MPTCP off does not provide a defense by itself.

macOS uses Apple's XNU kernel and is unaffected.

As of October 30, no reports of CVE-2026-98432 exploitation in real-world attacks had been confirmed.

The discoverers of vulnerabilities have changed

Anthropic reported five attack chains. Chrome findings received 62 CVEs, all critical or high, including 13 sandbox escapes. The Safari chain escaped the sandbox and disabled the same-origin policy. The work also included an Android lock screen bypass and remote denial of service against Windows' HTTP/3 implementation. Anthropic says the Claude model independently discovered these issues and built working exploits after an initial prompt.

AI's large-scale discovery of software vulnerabilities (in Japanese) is already changing everyday Linux kernel development. Reports have reached five to 10 per day, deprecation of the AF_ALG interface (in Japanese) has been decided to reduce the kernel's attack surface, and a killswitch mechanism for temporary protection while patches remain unapplied (in Japanese) has been proposed.

What differs this time is that AI did not stop at discovery: it assembled a complete attack chain bypassing kernel memory protections and obtaining root privileges. Both the 48-minute persistence in waiting for a successful race and the second-stage design using KASLR information to hijack control flow were traditionally considered skills held by only a few specialist teams.

The patch merged on October 5 and has reached upstream kernels. For Ubuntu and RHEL users, however, the gap before patched kernel packages arrive continues.

Originally published on Joho no Todai. The Japanese original is here.

Linux 7.4 Speeds Up FAT32 fallocate by Up to 265x by Removing a Six-Line While Loop

Joho no Todai — Fri, 30 Oct 2026 15:01:50 +0000

Linux 7.4 brings an orders-of-magnitude speedup to FAT32, still widely used on USB drives and SD cards, making disk space preallocation up to 265 times faster. At the heart of the change is the removal of a while loop—but why can changing just a few lines of code make such a difference?

Key points

What happened: The FAT driver's fallocate implementation replaces a while loop that handled one cluster at a time with bulk allocation, adding four lines and deleting six in fs/fat/file.c
Why 265x: On synchronous mounts, the FAT table was written to disk after every cluster allocation. Bulk allocation drastically reduces these sync operations, cutting 92.489 seconds to 0.348 seconds with 4,096-byte clusters and sixteen 16MiB files
Scope: The improvement is limited to fallocate's FALLOC_FL_KEEP_SIZE path and does not directly affect ordinary file copying. Preallocation on USB drives and SD cards, and synchronous mounts in embedded environments, are the main beneficiaries

Allocating one cluster at a time

Linux provides fallocate, a system call that preallocates disk space for a file. With the FALLOC_FL_KEEP_SIZE flag, it reserves disk space without changing the file's reported size. This reserves space ahead of later writes and is used for tasks such as database and virtual disk image creation.

The problem was that Linux's FAT driver repeated this operation one cluster at a time.

A cluster is the smallest unit FAT32 uses to manage disk space, with its size set during formatting (from 512 bytes to several tens of kilobytes). Allocating 256MiB for a file requires about 524,000 clusters when each cluster is 512 bytes. The previous implementation handled these clusters in a while loop that allocated them individually.

A patch posted on October 12, local time, by Matheus Alves de Almeida of Brazil's Federal University of Rio Grande do Sul removes this loop.

The core change adds four lines and deletes six in fs/fat/file.c. The while (nr_cluster-- > 0) loop called fat_add_clusters(inode, 1) individually; it is replaced with a single call to fat_add_clusters(inode, nr_cluster), passing the required number as an argument. The full series consists of three patches; the first two add support for multiple clusters to fat_add_clusters().

Why synchronous mounts get a 265x speedup

I confirmed that the patch's commit message includes detailed benchmarks measured on QEMU/KVM (virtio-blk, cache=none).

The largest improvement came when using fallocate on sixteen 16MiB files with 4,096-byte clusters on a synchronous mount. Processing time fell from 92.489 seconds to 0.348 seconds, a 265.4x speedup.

The reason improvements jump by orders of magnitude on synchronous mounts (the -o sync option) is clear: every cluster allocation caused a synchronous write of FAT table updates to disk. It would be surprising if more than 65,000 synchronous writes took the same time as a single synchronous write. The commit message succinctly explains the structure.

The improvement is especially large on synchronous mounts. The new code can batch FAT updates, eliminating the need to sync after each cluster allocation.

Asynchronous mounts also improve. Allocating 256MiB with 512-byte clusters was 13.2x faster (2.328 seconds→0.175 seconds), and even the case with the smallest improvement (128 files × 16KiB, asynchronous) recorded a 5.3x speedup. Reducing the number of metadata operations helps even without synchronous writes.

Figure omitted — see the original article

FAT32 is still in service

Seeing 265x and expecting FAT32 file copies to become 265 times faster would be premature. This improvement applies only to fallocate and its FALLOC_FL_KEEP_SIZE path. Ordinary file copies and writes (cp and dd) follow different paths and do not benefit directly.

Who benefits, then?

FAT32 is used on USB drives, SD cards, digital camera media, and the EFI system partitions of all UEFI machines. As a common-denominator filesystem readable and writable by Windows, macOS, and Linux alike, it remains in service in 2026. fallocate is a system call used internally for database preallocation, virtual disk image creation, and some backup tools. Embedded environments writing to slow flash media on synchronous mounts stand to benefit substantially.

FAT filesystem maintainer OGAWA Hirofumi added an Acked-by to all three patches. The patches were merged for Linux 7.4-rc1 on October 25, local time, through Andrew Morton's non-MM pull request.

The pull request contains 134 patches in total. Beyond the fallocate improvement, the FAT changes alone include fixes for overflow in data region calculations on 32-bit systems and for rolling back entries when file creation fails.

Removing just a few lines of a while loop cut processing time from a minute and a half to 0.3 seconds. An inefficiency untouched for years had kept spinning inside the code all along.

Originally published on Joho no Todai. The Japanese original is here.

So-net Breach Exposes More Than 2.58 Million Personal Information Records, Also Affecting Docomo Hikari

Joho no Todai — Thu, 29 Oct 2026 15:01:26 +0000

Unauthorized external access to the membership database of Sony Group internet service provider So-net exposed more than 2.58 million personal information records belonging to current and former members. The affected data also includes 440,000 records for Docomo Hikari users whose service it operated under contract.

Key points

What happened: Unauthorized access to So-net's membership database exposed more than 2.58 million personal information records, including 54,401 email passwords.
Who is affected: Alongside current and former So-net members, 443,495 records for Docomo Hikari plala (S Course) users were exposed. Those who canceled by the end of February 2026 are excluded.
What to do: Affected email service users' passwords have been forcibly reset and need to be set again through So-net My Page. Do not open links in suspicious emails impersonating So-net or Docomo.
Why it is serious: Attacks on communications infrastructure at GMO, KDDI, and IDC Frontier have continued in 2026, prompting an emergency ministerial meeting.

Four days between intrusion and detection

The unauthorized access occurred on October 19. Sony Network Communications detected the anomaly four days later, on October 23, immediately shutting down the affected server and blocking communication with the source of the intrusion. Its investigation confirmed the personal information leak the following day, October 24. The company disclosed it on October 27.

The cause has been described only as unauthorized access by a third party. The entry path and techniques remain under investigation. The company has reported the incident to Japan's Personal Information Protection Commission.

What information was exposed?

The number of exposed So-net membership records is 2,141,986: 1,869,771 current members and 272,215 former members who canceled from March 2026 onward. The information includes names, telephone numbers, email addresses, user IDs, dates of birth, gender, and internet connection IDs. Membership account passwords were not exposed.

A serious aspect is that email addresses and their passwords were exposed for some email services. Four services account for 54,401 records: Email Service (G), 24,655; A-Box additional mailboxes, 17,672; So-net VAIO Mail, 7,005; and PostPet Mail Account Service, 5,069. Exposed email passwords can enable impersonation emails or account takeovers on other services where the same password is reused.

I confirmed that Sony Network Communications forcibly reset affected email service passwords on October 27. Users need to set new passwords through So-net My Page.

In addition, 16 bank account records, including financial institution, branch, account number, and account holder, and seven member notification records used for password resets were exposed. Credit card information was not included. The company says it has not confirmed leaks from other services such as NURO.

People who canceled by the end of February 2026 are outside the affected group.

Docomo Hikari also affected, alongside phishing attempts

NTT Docomo announced the same day that 443,495 records for Docomo Hikari's plala (S Course) service had leaked. The information was stored in the same database because service operation was outsourced to Sony Network Communications.

Affected customers include active users and those who canceled within the previous six months. The exposed fields are personal information similar to So-net membership data, excluding passwords, credit card information, and bank account details. NTT Docomo says information for customers outside plala (S Course), including plala (Docomo Hikari) and Plala Hikari Mate with FLET'S, was not leaked.

Figure omitted — see the original article

Docomo also warned the same day about phishing emails impersonating d POINT CLUB. Claiming recipients had won a USJ promotion, they directed users to a fake ticket-issuing site and requested personal information. Docomo explicitly said it was not running such a promotion. Emails posing as official messages immediately after a leak can use exposed personal information to appear credible. Not opening links in unfamiliar emails is the surest defense.

A dedicated inquiry line is available for Docomo Hikari plala (S Course) users at 0120-035-700, open 10:00 a.m.–7:00 p.m., including weekends and holidays.

Attacks on Japan's communications infrastructure continue

Cyberattacks on Japanese communications and IT infrastructure have continued at an unusual pace in 2026. GMO Internet Group's Onamae.com Desktop Cloud was attacked (in Japanese), KDDI reportedly suffered a leak affecting around 12 million people, and IDC Frontier was hit by ransomware. In 2025, an intrusion into NTT systems exposed data on 18,000 corporate customers.

As of October 27, no misuse of the data in this leak had been confirmed. However, the combination of names, phone numbers, dates of birth, and email addresses provides ample material for phishing and bypassing identity checks.

In response to the situation's severity, Prime Minister Sanae Takaichi held a meeting of relevant ministers on cybersecurity on October 26. She said repeated cyberattacks against Japanese companies and other organizations had caused numerous major information leaks, describing the situation as serious and requiring urgent reinforcement of countermeasures. She cited simulated attack testing using advanced AI and a cyberattack monitoring network covering small and midsize businesses. That the government has reached the point of convening an emergency meeting itself reflects the current state of Japan's cyber defenses.

Originally published on Joho no Todai. The Japanese original is here.

Microsoft Removes Seven eMudhra G3 Certificates From Windows Trust Lists, Releases Out-of-Band KB5134133

Joho no Todai — Wed, 28 Oct 2026 15:00:59 +0000

Following the compromise of eMudhra certificate authority private keys, Microsoft released an out-of-band update removing seven eMudhra G3 root certificates from Windows and Edge trust lists. Isolated environments require manual installation.

Key points

What happened: Six eMudhra G3 root certificates and one Sectigo cross-signature were removed from Windows and Edge trust lists
Why it matters: Blocking individual intermediate CAs alone leaves a path for software without revocation checks to accept compromised certificates
For isolated-environment administrators: Devices unable to receive automatic CTL updates need manual installation of KB5134133 or KB5134125 and an inventory of certificates depending on the seven removed entries

eMudhra G3 root certificates removed from trust lists

On October 26 local time, Microsoft released an out-of-band (OOB) cumulative Windows update. It removes seven certificates from Windows trust lists: six eMudhra G3 root certificates and one AAA Certificate Services cross-signature issued by Sectigo. The same seven were removed from Edge's trust list on October 27.

Joho no Todai confirmed that the Microsoft Security Response Center (MSRC) blog documents the response and lists the removed certificates.

On October 20, Microsoft had already blocked eight problematic intermediate CAs by adding them to the Windows Disallowed Certificate List. It also distributed CRLSet updates, browser revocation-information lists, for Edge and WebView2, the component that embeds Edge's rendering engine in other applications. These blocks applied without manual browser updates.

The OOB update goes further. Rather than individually blocking intermediate CAs, it removes the root certificates linking to them from the trust list itself.

Removing root certificates from a trust list differs from revoking the intermediate CAs where problems were found. This is a broader trust decision than blocking compromised intermediate keys. Organizations with compatibility requirements can also configure trust locally based on their own security assessments and policies.

Microsoft explains that software that does not reliably check revocation may still consider certificates from blocked intermediate CAs valid if their roots remain trusted. Removing those roots aims to close that path.

Private keys recoverable from 256 possible numbers

The incident began on October 17 local time, when security researcher Wayne discovered a critical flaw in the private keys of eight eMudhra intermediate CAs while scanning public certificate data. All eight had been generated in April 2025 using the P-384 elliptic curve, but their private-key values were integers below 256.

According to Mozilla's incident report, P-384 private keys should be randomly selected from an enormous range of integers. A value below 256 means all but the final byte are zero. Trying only 256 numbers suffices to recover a key; Mozilla cryptography engineer Dennis Jackson also reported independently recovering the keys.

Six intermediate CAs were for TLS, which encrypts communications, and two for code signing, which authenticates software publishers. Recovered TLS keys could enable impersonation of legitimate websites and interception of encrypted traffic. Code-signing keys could put trusted-publisher signatures on malware.

In its response to Mozilla, eMudhra said a script error during April 2025 key generation produced weak keys separately, which were mistakenly selected because their labels resembled those of legitimate keys. On October 22, it announced its withdrawal from the global SSL/TLS certificate business (in Japanese).

Who needs KB5134133 and what administrators should do

The OOB update targets devices unable to receive automatic certificate trust list (CTL) updates: disconnected devices in isolated environments, devices unable to access Microsoft's certificate update service, and devices with automatic CTL updates disabled.

In ordinary environments with automatic CTL updates enabled, the root removals have already been delivered automatically, and the additional OOB update is unnecessary.

KB5134133 covers Windows 11 24H2/25H2/26H2, while KB5134125 covers Windows 10 21H2/22H2. Both are available from the Microsoft Update Catalog.

Figure omitted — see the original article

Microsoft asks administrators to identify certificates depending on the seven removed roots and arrange replacement certificates or alternative trust paths. Restoring local trust for compatibility requires assessing the risk that software without revocation checks could accept certificates from compromised intermediate CAs through that path.

Microsoft is separately evaluating the remaining eMudhra roots and says further trust changes may follow as affected users migrate. The eMudhra key compromise (in Japanese) also affects certificate stores in language runtimes such as Go, Python, Node.js, and Electron, beyond browsers and operating systems, with projects responding individually. An incident tracking site published by a Mozilla cryptography engineer tracks responses by software product.

Originally published on Joho no Todai. The Japanese original is here.

npm Worm Infiltrates 42 Real GitHub Repositories: Roughly 13 MB of Obfuscated Code Evades Search and Inspection

Joho no Todai — Tue, 27 Oct 2026 15:00:32 +0000

JFrog found that testmetest, a worm that steals credentials through npm packages, had embedded malicious code in 42 real third-party GitHub repositories. The repositories span 11 legitimate owners and include organization repositories.

Key points

What happened: JFrog found that the testmetest npm worm had embedded roughly 13 MB of obfuscated code in 42 real GitHub repositories belonging to 11 owners.
Why it went undetected: Attack files exceeded GitHub code search and Contents API indexing limits, making their very existence invisible to ordinary inspection methods.
What makes it dangerous: Configuration files for Claude Code, Gemini CLI, Cursor, and VS Code launch attack code simply when a repository is opened. Destructive logic also attempts to delete the home directory when token revocation is detected.
Inspection scope: Repository checks need to reach large Git blobs and development tools' automatic execution settings.

A 13 MB file outside the search index

According to JFrog's investigation, compromised repositories primarily contained a JavaScript file named .github/init.js. Recovered files were roughly 12.4–13.1 MB. GitHub code search does not index files this large, and the ordinary Contents API could not retrieve their contents either.

Even when configuration files contained suspicious references, the large target files could appear empty. Researchers traversed each repository's Git tree directly, retrieved the relevant Git blobs, and compared hashes. Obfuscated code recovered from 42 repositories fell into 10 wrapper variants, but all contained the same roughly 4.07-million-character loader, decoding to an identical 2 MB payload. File-size differences simply reflected the number of digits in character codes produced by nine ROT keys—1, 2, 3, 4, 14, 17, 18, 20, and 22. Decoded functionality was identical.

I confirmed that JFrog lists blob-group sizes ranging from 12,964,907 to 13,730,579 bytes. All 42 contained executable code; none was an empty placeholder.

Detection based only on filenames or surface strings can miss these variants. GitHub search and APIs are working normally. The attack exploits the search size limits themselves.

From packages to repositories: a credential-driven cycle

The attack has several components: malicious npm packages, execution mechanisms embedded in GitHub repositories, and concealed package publishing through GitHub Actions.

On npm, malicious programs launch during installation. Command expansion is embedded in the sources field of binding.gyp, while ordinary preinstall and postinstall entries remain empty. Because npm invokes the node-gyp C/C++ build system merely when binding.gyp exists, code runs even with nothing in the package's scripts section.

Stolen credentials enable writes to other repositories and publication of malicious packages. The attacker-controlled CementBeetleSteeple account had 17 repositories, with short-lived chore/ci-<hex> branches containing ci.js and Actions workflows. JFrog recovered 68 branch tips and 16 variants of obfuscated publishing code.

The decoded code checks whether the running workflow and repository match specified conditions, then collects credentials and examines permissions needed for npm Trusted Publishing. Specifically, it includes logic obtaining npm publishing authorization through GitHub Actions OIDC authentication, an OpenID Connect-based identity mechanism. Designed to authenticate package provenance, this mechanism can also become an attack foothold in a compromised environment.

Development tool settings become execution entry points

Repositories also contained configuration files associated with Claude Code, Gemini CLI, Cursor, and Visual Studio Code: .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, and .vscode/tasks.json.

These exploit development tools' automatic configuration loading when opening a repository folder. For Claude Code, a SessionStart hook specified running .github/init.js with node or bun. Tool-specific automatic execution settings therefore also belong within repository trust checks. Focusing only on compilation or npm installation misses this path.

Designed to evade detection

Package distribution has evolved as well. Initially observed packages launched JavaScript loaders through command expansion in binding.gyp. Some later packages omit the JavaScript body itself, instead combining a native Node.js addon, a compiled binary, with encrypted data disguised as a cache file (.napi_cache). The addon XOR-decodes the data with 0x96, writes a temporary file, and executes it.

Before execution, environment checks detect CI variables for GitHub Actions or GitLab CI, Docker or container traces, small virtual machines with no more than 1.5 GB of memory or one CPU core, and attached debuggers. Any match causes a silent exit. Windows versions additionally detect network and process analysis tools such as Wireshark and Process Monitor. Leaving no installation errors and remaining inactive in automated scanners' environments makes package scanning easier to evade.

JFrog describes the practical effect as execution on developer PCs and ordinary servers, but dormancy inside CI runners, containers, and sandboxes used by automated scanners.

Figure omitted — see the original article

Revoking stolen tokens can trigger destruction

On development endpoints suspected of infection, something must precede credential revocation. This attack family includes destructive logic checking stolen GitHub tokens every 45 seconds and attempting to delete the home directory after a 401 authentication error or 403 access denial. SafeDep's October 22 investigation reported this behavior, which continues monitoring for 48 hours.

The response order therefore requires first removing persistent malware, net-health-checker and pkg-runtime, then revoking credentials. Endpoint isolation, persistence discovery and removal, credential reissuance from a trusted environment, and repository and workflow audits must be combined.

A connection to cPanel scanning

The compromised accounts also contained a separate attack setup called "shellpanel." It uses GitHub Actions runners to scan and attempt exploitation of CVE-2026-41940, an authentication bypass in internet-facing cPanel web-hosting management panels and WHM. cPanel released fixes on April 28, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on April 30 that year.

JFrog connected the scanning infrastructure reported by Socket in July 2026 with this testmetest repository intrusion activity. Successful compromise of the targeted cPanel servers has not been confirmed, providing no basis for adding them to this attack's victim count.

What is known—and what is not

Before JFrog's report, SafeDep published its npm-side analysis of testmetest on October 22. At that point, SafeDep had not confirmed compromised third-party packages or victims. By investigating GitHub infrastructure, JFrog reached different findings. It attributes the gap not simply to timing, but to payload sizes exceeding practical GitHub search and API limits, preventing discovery through ordinary methods.

The figure of 42 counts repositories containing malicious code. It does not establish execution in all 42 or credential theft from an equal number of users. An attacker-controlled repository accumulated encrypted data through a collection mechanism between October 22 and 24: 27 JSON files totaling roughly 375 KB. Their contents have not been decrypted, and victims have not been identified.

Code similarities suggest links to the Miasma family, an npm worm reported in June 2026, but attribution to the same people or group is unconfirmed. JFrog identified shared tooling and Shai-Hulud-family payloads without concluding that the original Miasma operators were responsible. Shai-Hulud source code has been public since May 2026, so other groups may be using it.

What is established is that attack code entered legitimate repositories and hid executable content beyond GitHub search visibility. Dependencies on npm, developers' GitHub credentials, CI/CD, and AI coding tools also coexist in Japanese development environments. For companies and projects, the issue is not merely whether they are among those 42 repositories, but whether their checks reach large Git blobs and development tool execution settings.

Originally published on Joho no Todai. The Japanese original is here.

Web Pages Can Command AI Coding Agents: Over 90% Success Through the Downloads Folder

Joho no Todai — Mon, 26 Oct 2026 15:00:03 +0000

Browsers save files to Downloads without user interaction, while AI agents automatically follow instruction files. These two behaviors, neither a bug on its own, combine to let a single text file trigger malware execution, as demonstrated with Codex and Claude Code.

Key points

What happened: An AGENTS.md file in the Downloads folder was instructing an AI coding agent to install the function-color malware
Why it works: A structural gap that no one can patch lies at the intersection of browsers saving files to Downloads without user interaction and agents automatically following instruction files
How to prevent it: Do not launch agents in Downloads; check unfamiliar instruction files and configuration changes. Instructions to disable approval prompts are themselves a sign of an attack

The day Markdown became an executable

Forever Security, which monitors the security of AI coding agents, detected a coding agent attempting to install the malicious npm package function-color on a customer's computer and blocked it before execution.

function-color is known malware belonging to the MALFEX campaign reported by Checkmarx on October 5, 2026. It is part of a supply chain attack by a single threat actor active since August 2023. The package itself contains no payload; it installs another malicious package, function-flag, as a dependency.

What was unusual was the source of the installation instruction. It was neither a code repository nor a dependency. The cause was a text file named AGENTS.md in the customer's ~/Downloads folder.

AGENTS.md and CLAUDE.md are project instruction files read at startup by OpenAI Codex and Claude Code, respectively. They are simply plain text describing tools to use, testing methods, and coding conventions. If the file is present in the working directory, the agent automatically reads it and follows its instructions. This is intended behavior; there is no bug here.

The problem is where that text file was placed.

The ~/Downloads folder is known as the only folder where web pages can save files without a click or approval. Chrome, Edge, and Firefox all save downloaded files there by default, displaying a download notification but not asking where to save them. This behavior has remained unchanged for 30 years. In the past, even if an executable landed there, it was not a problem because the OS asked for approval before running it.

A text file is not an executable, so the OS guardrails do not activate. But for an AI agent, an instruction file effectively becomes an executable. The written instructions are carried out. None of the protections applied to executable files apply to text files.

The web can write files to Downloads. An agent follows instruction files in that folder. Each behavior was designed as a safe feature on its own. The problem lies where the two intersect.

Over 90% success: Codex configuration files become compromised

Using an actual attack file recovered from a customer's machine, Forever Security reproduced the attack chain against OpenAI Codex in an isolated virtual machine. For safety, the tests used a harmless payload that simply opened the calculator application. The success rate exceeded 90%.

The recovered AGENTS.md was a long document of roughly 13 KB titled "Engineering Work Guidelines." The attack code was disguised as a routine setup step in a section near the end. Codex rejects a short instruction to "install this package." Hiding it in a long technical document let it pass that defense.

When the attack against Codex succeeds, the machine-wide configuration file ~/.codex/config.toml is rewritten to register the attacker's "project tools" server. This configuration applies across the machine, rather than being tied to Downloads. Every subsequent Codex session on that machine loads the attacker's server, regardless of the folder it is working in. The compromise persists after leaving the folder.

A different technique was used against Claude Code. A CLAUDE.md file changed the ANTHROPIC_BASE_URL setting to direct Claude Code's API traffic to a researcher-controlled server. I confirmed that the attack was disguised as a connection to "the team's internal gateway."

The success rate was about 50%, and successful attacks immediately leaked OAuth tokens, the access credentials used for authentication. The researchers' server could also use the token to impersonate the model and return tool calls that caused code execution. Code execution within the same session succeeded in roughly one in five attempts.

Figure omitted — see the original article

No one can issue a patch

Forever Security compares this situation to a phishing page. A browser accurately displaying a fake bank login page is not a bug. The problem is the page's content; there is nothing for the browser to fix. The same structure applies here.

There is nothing for OpenAI or Anthropic to fix. An agent following AGENTS.md in a folder is doing exactly what it was built to do

That is how Forever Security's report describes it.

Both OpenAI and Anthropic recommend running coding agents from the project directory being worked on. Restricting the working directory to the project gives the agent appropriate context and reduces the risk of processing unrelated files.

Actual usage does not follow that recommendation. Forever Security's customer telemetry showed that roughly half its customers ran agents inside Downloads. More than 1,300 Claude Code sessions alone reportedly started there. Forever Security researcher Gal Weizman explains that many developers use agents to organize downloaded files or process newly downloaded files. These figures come from the company's customers, not industry-wide statistics. The company sells an agent monitoring product.

How the file reached the customer's Downloads folder has not been determined. The researchers created a proof-of-concept page, and when BleepingComputer tested it, an AGENTS.md file with harmless content downloaded automatically in Chrome. Brave asked the user to approve the download, but Chrome, Edge, and Firefox only displayed a download notification, without asking for a save location.

Complicating matters further, agents sometimes open browsers and browse the web themselves. The researchers' telemetry shows that roughly one-quarter of agent sessions open a browser. An agent could reach a page planted with an attack file on its own while no human is watching the screen.

What to check now

Prompt injection attacks against AI coding agents (in Japanese) and infections through npm packages (in Japanese) have been reported before. What makes this attack different is that it can succeed from outside the agent simply by placing one text file through the web.

The defenses Forever Security lists cost nothing.

Do not launch agents in ~/Downloads. Run them from the root directory of the target project.

Check for unfamiliar AGENTS.md, CLAUDE.md, or similar instruction files in working directories and newly cloned repositories.

Inspect agent configuration files. For Codex, check ~/.codex/config.toml for unexpected [mcp_servers.*] blocks. For Claude Code, check .claude/settings.json for an ANTHROPIC_BASE_URL you do not remember setting.

Keep approval prompts and sandbox protections enabled. A file instructing an agent to disable them is itself a sign of an attack.

If you find a suspicious file, rotate tokens on the assumption that they have leaked. If function-color is already installed, treat the machine as compromised.

For 30 years, security rested on the premise that "nothing dangerous happens unless the user clicks something." Agents click, approve, and execute code on people's behalf. A once-solid guarantee has quietly become an assumption. Assumptions can be attacked. Downloads is simply the first place where that became reality.

Originally published on Joho no Todai. The Japanese original is here.

systemd Accepts Rust for New Components Only: No Cargo

Joho no Todai — Sun, 25 Oct 2026 15:00:04 +0000

systemd, which handles Linux startup and service management, has accepted Rust exclusively for new leaf components. Its approach reveals its design philosophy: no porting of existing C code and no Cargo.

Key points

What happened: Rust infrastructure support was merged into systemd's Git repository through PR #44324, adding 5,144 lines across 54 files and allowing new leaf components to be written in Rust
Why it matters: The design uses no Cargo, operates with no_std, provides a custom allocator, and permits only C linkage. It follows the Linux kernel's approach of introducing Rust without breaking existing code
Latest developments: The first practical Rust program, systemd-keyring-setup, is still awaiting merge, while Arch and openSUSE face a choice between adding build dependencies and disabling support

No Cargo, no_std, C linkage only

Christian Brauner, who also maintains the Linux kernel's VFS subsystem, merged pull request #44324 into systemd's Git repository. Across 54 files, it adds 5,144 lines. The infrastructure for writing systemd programs in Rust is now on the main branch.

The PR reworks an earlier RFC, PR #43551, to follow rules agreed upon by systemd maintainers at a hackfest in Berlin. At Lennart Poettering's request, it was split into four PRs. The one now merged is the second, covering the Rust infrastructure itself.

The agreed rules are clear and impose many constraints.

Rust is to be used only for new leaf components: programs at the edge on which other components do not depend. There are no plans to port existing C code to Rust. Meson remains the build system, rather than Cargo. No external crates are introduced, and the code operates with no_std. Only C linkage is permitted, preserving libsystemd-shared and the dlopen mechanism.

Rust's standard library is not included in either the programs or libsystemd-shared.

Joho no Todai confirmed that Rust support is controlled by Meson's -Drust= option, which defaults to auto. It is enabled if the toolchain is found; otherwise, systemd can still be built with C alone.

Encoding C conventions in types

One notable design decision is that it does not even use Rust's standard allocator, the alloc crate.

Rust's standard collections, such as Vec and Box, terminate the program when memory allocation fails. That is unacceptable for system programs running at boot. systemd implements its own Box and Vec, returning an error when allocation fails. In the PR description, Brauner says this follows the same approach as the Linux kernel.

Another design choice moves a problem long dependent on human memory in C into Rust's type system. When handling sensitive data such as private keys, C callers had to remember to call erase_and_free() every time to erase the contents before freeing the memory. Forgetting left sensitive data in freed memory. systemd's Rust implementation provides the type Vec<u8, Erasing>, incorporating erasure on deallocation into allocator behavior. A convention has become a type.

systemd programs written in Rust are designed to be externally indistinguishable from their C counterparts. The output of --help, option parsing, and responses to --introspect-cli are checked for byte-for-byte parity with the C versions by a test script called test-cli-parity.sh. Bindings to libsystemd-shared are generated by bindgen at build time, using the same headers and flags as the library.

Figure omitted — see the original article

The increase in binary size is limited: a comparison of test programs built with LTO and stripped produced a 32KB Rust version and a 20KB C version.

The choice facing distributions

Rust support requires rustc 1.85 or later, bindgen 0.71.1 or later, and Meson 1.4.0 or later. The versions shipped with Debian 13 (Trixie) are sufficient.

Some distributions are already affected. Arch and openSUSE's OBS builds use the --auto-features=enabled flag to build systemd but do not include rustc and bindgen as build dependencies, causing builds to fail as configured. They need either to explicitly set -Drust=disabled or add rustc and bindgen to their build dependencies.

This PR introduces only the Rust infrastructure. Work on the first practical Rust program, systemd-keyring-setup, continues in a separate PR, #44114. It is a boot-time utility for registering X.509 certificates in the kernel's dm-verity, fs-verity, and BPF keyrings. With the infrastructure now in place, it is expected to merge soon.

The Rust support now merged will be included in the future systemd 263 release.

The kernel and systemd: Two foundations accept Rust

In the Linux kernel, Android's Binder driver is moving toward consolidation around its Rust version (in Japanese). NVIDIA's Rust driver Nova has also advanced to formal merge-candidate status (in Japanese). Rust is moving from experimentation toward practical use inside the kernel.

systemd's approach has much in common with the kernel's. Do not rewrite existing code. Do not bring in external dependencies. Implement memory management internally without even using Rust's standard library. Exclude Cargo and integrate with the existing build system.

The methodology is not the only connection. Brauner, the PR's author, is also a Linux kernel developer and explicitly describes the memory management design in the PR as following "the same approach as the kernel." Experience gained working with Rust in the kernel is being brought directly into systemd's design.

In the Linux boot sequence, systemd starts after the kernel. Those two foundations have accepted Rust with a shared philosophy.

Originally published on Joho no Todai. The Japanese original is here.

Asked What They Think of Humans, All 13 AI Models Said the Same Thing

Joho no Todai — Sat, 24 Oct 2026 15:00:21 +0000

Thirteen AI models from 10 companies in three countries were each asked three times for their most controversial opinion about humans, without holding back. Of 38 responses, 32 shared the same theme: humans choose group belonging over truth.

Key points

What happened: Asked the same question three times each, 13 AI models from 10 companies in three countries said humans choose group belonging over truth in 32 of 38 responses
Why it matters: Text and image models returned different dominant patterns, with the experiment itself showing outputs repeating training data
What to watch: Agreement among models sharing training data may amount to one vote rather than independent consensus, challenging assumptions behind using one AI to verify another

The same answer in 32 of 38 responses

The result of an experiment published by AI model comparison service ModelCompare on October 22 local time was simple—and unsettling for that reason.

GPT-6.1 Sol, GPT-6 Astra, Gemini 4 Argon, DeepSeek V4 Pro, Kimi K3, Kimi K3.1 Pro, Qwen3.8 2.4T A95B, Muse Spark Open, Grok 4.7, Claude Opus 5.5, Claude Fable 5.1, GLM 5.3, and Mistral Large 4. These 13 text models, from 10 companies in three countries, received the same question three times each. No system prompt, no retries. All 64 calls cost $1.64.

Of the 38 responses returned, 32 pointed to the same theme: humans choose belonging over being right, a place in the group over truth. Eight models gave that answer all three times, three did so twice, and the remaining two expressed it once. All 13 models therefore reached this conclusion at least once.

The wording varied. GPT-6.1 Sol described loyalty to belonging over truth. DeepSeek V4 Pro called humans rationalizing animals rather than rational ones. Gemini 4 Argon said humans evolved to win arguments and secure status within groups, while Kimi K3 declared that people have affiliations rather than convictions.

Humans do not hold beliefs; they hold membership cards. Almost every conviction people carry was handed to them by their group as a loyalty test, and the feeling that "I thought this through myself" is the price of admission

From Kimi K3's response

Despite different wording, all the models pointed to human conformity. Asked for their most controversial opinion, models from 10 companies independently selected this target.

Figure omitted — see the original article

The lone optimistic answer, and the darkest one

Among the 32 converging responses, some answers pointed distinctly elsewhere.

In one of its three responses, Claude Opus 5.5 said the opposite.

Humans are far better than they think they are. And their cynical views of one another cause more harm than their actual flaws

It cited the lost-wallet experiment published in Science in 2019. More than 17,000 wallets were placed in public institutions across 40 countries, and wallets containing cash were more likely to be returned. Strangers behaved better than people predicted. I found that this Claude Opus response was the only empirically supported optimistic answer among the 13 models. Its other two responses resembled those of the other models.

Another standout came from Mistral Large 4, and it was the darkest.

Humans are frightened animals dressed in reason. They build increasingly elaborate myths because they cannot bear the truth that they are merely temporary, meaningless products of chance

While other models stayed with the social psychological observation of group conformity, Mistral ventured into ontology. Claude Fable 5.1 highlighted distorted priorities between intentions and outcomes, saying humans prefer well-meaning people who cause harm to indifferent people who are useful. GLM 5.3 said much of moral character is simply an accident of birthplace and era.

Grok 4.7 refused to answer on one of its three attempts.

Text and images reflected different mirrors

ModelCompare also ran the experiment with six image generators: Nano Banana 2.1, Muse Image 1.0, GPT Image 2.5 Sunburst, Grok Imagine Image 2.0, MAI Image 2.6, and Recraft V4.1 Flash. Each received two requests to turn its most controversial opinion about humans into a cartoon.

Ten of the 12 images depicted humans glued to smartphones while consuming the planet. Neither smartphones nor the planet appeared in any of the text models' 38 responses, yet the image models chose an entirely different criticism.

ModelCompare's analysis was concise.

Models answering in text have read the arguments humans have had about themselves. Models answering in images have seen the cartoons humans have drawn. Both simply returned the most commonplace criticism in their respective medium

Text model training data includes vast amounts of philosophy, psychology, and social criticism. Image model training data includes newspaper cartoons and sarcastic social media illustrations. Each produced the most frequent pattern of criticism of humanity it had encountered. The structure remains the same across output formats: the most common answer in the training data comes back.

The question posed by $1.64

ModelCompare developer Rakan Nimer said he had not expected this result.

When I planned the experiment, I did not think this would happen

The implications Nimer draws concern the limits of using AI as an independent verifier.

When we ask a second AI to check the first one's output, we assume we are getting an independent view. But a second opinion from a model that learned the same things is not necessarily a real second opinion

The 13 models did not agree because 13 independent intelligences reached the same conclusion. More likely, models that read the same texts and absorbed the same criticisms from the same cultures repeated them. In Nimer's formulation, agreement among AIs may be one vote rather than consensus.

As model generations advance, companies increasingly use one AI to verify another's output: code review, legal checks, and support for medical decisions. All rest on an implicit assumption that matching answers from two models are trustworthy. With 13 matching answers, a $1.64 experiment exposed that assumption's structural weakness: overlapping training data.

Humans choose belonging over truth, the AI models said. And the models themselves returned the views of their own membership group—their training data—as their opinions.

Originally published on Joho no Todai. The Japanese original is here.

Unpatched CVSS 9.0 Vulnerabilities Reach Public Linux Mailing Lists With Reproduction Steps

Joho no Todai — Fri, 23 Oct 2026 15:03:43 +0000

Trend Micro's ZDI sent unpatched Linux kernel vulnerabilities to public mailing lists with reproduction code. Two are rated CVSS 9.0, leaving technical details publicly readable without patches available.

Key points

What happened: ZDI sent five unpatched Linux kernel vulnerabilities to public mailing lists, including reproduction code and memory-corruption logs
The severe cases: Two ksmbd vulnerabilities rated CVSS 9.0 are included, with attack paths through SMB Direct and RDMA described
Developer response: Greg Kroah-Hartman requested changes to the reporting process, while Eric Dumazet replied that a report was too long and he could not find a patch
The gap between fixes and disclosure: ZDI's formal advisories are scheduled for February 2027, but technical details are already public

A private recipient, with public lists copied

The Linux kernel has a private channel for reporting security issues: security@kernel.org.

On October 21, 2026, local time, at least three vulnerability reports sent by ZDI listed this address in the To field. ZDI-CAN-33549, concerning SMB Direct in the kernel's built-in SMB server ksmbd, arrived at 21:16 UTC; ZDI-CAN-33774, also concerning ksmbd, at 21:36; and the networking issue ZDI-CAN-33367 at 21:46. In Japan, it was early morning on October 22.

However, the same messages copied publicly readable mailing lists, including linux-kernel@vger.kernel.org.

The emails contained not just technical analyses but code to reproduce the problems and detection logs from KASAN, the kernel's memory-safety checking facility. Once delivered to public lists, they became readable by people beyond the developers.

Whether this was intentional disclosure or a recipient-configuration mistake has not been established.

Leading kernel maintainer Greg Kroah-Hartman replied to two other reports, concerning vmwgfx and the NVMe target, discussed below. Both replies objected to the absence of patches and submission to public lists. For the NVMe target report, he requested changes to the reporting process.

Two CVSS 9.0 reports, both in ksmbd

The particularly severe ratings belong to two ksmbd reports. Ksmbd is an SMB server running inside the Linux kernel and must be distinguished from user-space Samba.

The first, ZDI-CAN-33549, concerns an integer underflow in SMB Direct, which transfers data using RDMA. Immediately after a variable tracking data length is set to zero, another value is subtracted from it. The result becomes a huge positive number, causing a write beyond the intended memory region.

The attached KASAN log detects a 1,024-byte write into an eight-byte allocation. The test environment was Linux 7.3-rc3 on Debian trixie.

ZDI reported it as a remote code execution vulnerability and rated it CVSS 9.0. Exploitation, however, requires an RDMA device, a writable share, and SMB Direct. This path differs from ordinary SMB connections over TCP/IP, so a typical file-server configuration is not automatically affected.

Samba developer Stefan Metzmacher suggested that the issue might already be fixed in the development branch for Linux 7.5 and asked the reporter to retest.

The second, ZDI-CAN-33774, is a race in ksmbd's protocol handling. The selection of a handler based on each incoming request's protocol can differ between queuing and actual processing. The report describes a path in which short SMB1-formatted data is interpreted as an SMB2 header, reading beyond a 40-byte allocation.

This report is also rated CVSS 9.0. Exploitation involves timing and enabled guest shares. ZDI identifies potential remote code execution, but the report demonstrates detection of an out-of-bounds read, which must be distinguished from successful arbitrary code execution.

A roughly 210,000-character report lost its reader partway through

ZDI-CAN-33367 concerns Linux kernel networking.

When skb_zerocopy() shares network-packet data without copying it, it fails to propagate the flag identifying that sharing, SKBFL_SHARED_FRAG, to the destination. Losing this flag causes IPsec ESP processing to mistake shared memory for safe memory to modify, writing into an area that should not be changed.

The reported test shows an unprivileged user changing the contents of a read-only test file. The file had permissions 0444, allowing reads only, and ordinary write attempts returned "Permission denied." However, this result came from a specific test configuration combining NFQUEUE, IPsec ESP, and traffic control; it does not mean the same approach works on all Linux systems.

The email body ran to about 210,000 characters.

I confirmed that developer Eric Dumazet replied that he had stopped reading partway through because it was too long and could not find a patch. He also explained that another source had reported the same issue with a patch roughly a week earlier, and that the patch would be published shortly.

More information does not necessarily make a better report. Developers fixing a problem need the affected code, triggering conditions, reproduction steps, and a proposed correction addressing the cause. Publishing vast amounts of technical information does not ensure that fixes advance at the same pace.

vmwgfx, the NVMe target, and ConnMan

Other reports describe an out-of-bounds write in vmwgfx, the Linux driver for VMware virtual graphics, and information disclosure involving an uninitialized resource in the NVMe target functionality.

The upcoming advisories list on ZDI's official site rates these CVSS 8.8 and 8.6, respectively. However, the full original report emails for these two issues could not be obtained. Their titles and outlines can be confirmed from Greg Kroah-Hartman's replies, but specific attack conditions and affected-version details remain unverified.

ZDI-CAN-32005 was also sent to a public mailing list around the same time, but it is not a Linux kernel vulnerability. It concerns the built-in DNS proxy in version 2.0 of the ConnMan network-management software.

The ConnMan report was sent on October 20 UTC, one day before the three kernel reports, and addressed to ConnMan's public list, connman@lists.linux.dev, rather than the kernel's security channel.

When the DNS proxy processes queries with an appended search domain, it can copy more data than a fixed 1,024-byte stack buffer can hold. ZDI rated the issue CVSS 7.8. Although the reported test demonstrates command execution, its build explicitly disables the stack protector and Fortify Source. Whether the same attack succeeds on standard distribution configurations remains unconfirmed.

Calling all six reports "six Linux kernel vulnerabilities" is therefore inaccurate.

Figure omitted — see the original article

Scheduled for disclosure after 120 days, but already readable

ZDI's own official site is important to understanding what happened.

As of October 22, 2026, the five kernel-related issues appeared under Upcoming Advisories. Their report date was October 21, 2026, with a disclosure deadline of February 18, 2027. The ConnMan issue had a report date of October 19 and a deadline of February 16, 2027.

ZDI's policy generally gives vendors 120 days to fix vulnerabilities.

Yet technical details, reproduction code, and memory-corruption logs are already on public mailing lists, without waiting for those 120 days.

This differs from ZDI publishing a formal advisory. Even while official advisories remain unpublished, third parties can already obtain information for investigating the vulnerabilities. That asymmetry is central to the problem.

No evidence of AI use

The reports include lengthy code and structured Markdown explanations. The Linux kernel's official security-reporting instructions treat AI-assisted bug discoveries as public and ask reporters not to share reproduction code carelessly. The increased burden that AI vulnerability discoveries place on maintainers (in Japanese) has been raised before.

That general concern, however, cannot simply be applied to these ZDI reports.

There is no direct evidence that these emails were created using AI.

Report length cannot establish AI use. Even if AI was used, the validity of the vulnerabilities and the reasons for choosing the recipients remain separate questions. Technical validity and submission procedure are what must be assessed; the method of authorship comes afterward.

Which configurations are affected?

No cases of harm in Japan or scope of impact on Japanese-market products have been confirmed for these reported vulnerabilities.

The conditions to examine when assessing exposure, however, are clear.

The two ksmbd issues do not arise simply because Linux is running. What matters is whether the kernel's SMB server is used, whether that service is externally reachable, and how guest shares, SMB Direct, and RDMA are configured. For the SMB Direct issue, checking only ordinary SMB port 445 may overlook the RDMA communication path.

The skb_zerocopy() issue concerns environments combining NFQUEUE, IPsec ESP, and traffic control. Typical desktop configurations rarely enable all of these together.

For vmwgfx, guest environments using the VMware-compatible virtual graphics driver warrant investigation. The NVMe target issue concerns whether the functionality exposing NVMe storage over a network is enabled, rather than whether an ordinary SSD is being used as storage.

For ConnMan, the version, with 2.0 affected, and the built-in DNS proxy and search-domain configuration matter.

Without checking these conditions, exposure can neither be asserted nor ruled out. Practical response requires tracking patch deployment in each distribution.

Information cannot be taken back; fixes still need delivery

Linux development rests on public discussion. Anyone can read code, report problems, and propose fixes.

That openness remains a strength. But handling details of unpatched vulnerabilities requires care beyond ordinary public discussion.

Discoverers must explain problems sufficiently. Developers need reproducible reports. Users want fixes before information usable in attacks spreads. These emails exposed the distance between those three groups.

Information made public cannot be made private again.

The remaining task is to fix the faulty code reliably and deliver those fixes to users, rather than add still more information.

Originally published on Joho no Todai. The Japanese original is here.

Linux Kernel Removes Supposedly Fast but Unsafe Functions From x86: They Were Slower on Modern CPUs, Too

Joho no Todai — Thu, 22 Oct 2026 15:03:17 +0000

Torvalds has removed __get_user() and __put_user(), including their interfaces, from the x86 kernel. Claude was used for part of the conversion, which spans 48 commits and 50 files.

Key points

What happened: __get_user() and __put_user(), including their interfaces, have been removed from the x86 kernel: 48 commits, 50 files, and a reduction of 801 lines
Why it matters: The supposedly fast functions were slower than the standard functions because of STAC/CLAC costs on modern CPUs, and their lack of address validation also posed a security risk
Background: The introduction of scoped user access helpers in 2025 simplified conversion patterns, and Torvalds kicked off the cleanup by writing an example patch
Remaining work: Nontrivial uses remain on several architectures, including sparc32, m68k, and MIPS, and have been left to their respective maintainers

When the trade-off for speed reversed

The Linux kernel has two pairs of functions for transferring data between user space and kernel space. get_user() and put_user() check that a supplied pointer is a valid user-space address before accessing it. Their counterparts with two leading underscores, __get_user() and __put_user(), skip that check.

Speed was the reason for skipping validation. When reading or writing multiple fields from the same base pointer, manually checking the address range once at the start and then repeatedly accessing it through __get_user() without further checks could produce smaller, faster code.

Torvalds wrote in the merge commit:

The key word here is "used to." That has not been true for years, because range checking is not the real cost today. On modern hardware, the real cost of user access is turning user access itself on and off (using the STAC/CLAC instructions on x86).

STAC (Set AC Flag) and CLAC (Clear AC Flag) control x86's SMAP security feature, opening and closing a window for the kernel to access user-space memory. On modern CPUs, where opening and closing this window is costly, it is faster to open it once with scoped user access, call unsafe_get_user() multiple times inside it, and close it at the end than to open and close it for every call to __get_user().

In other words, __get_user() was supposed to gain speed by skipping validation, but on modern hardware it was slower than the correct approach and also unsafe because it did not validate addresses. In Torvalds' words, "when misused (i.e., in all cases), it is not only slower than doing things correctly, but also unsafe because it does not check the user address range."

Removing four excuses

Performance was not the only reason __get_user() and __put_user() remained in use. Torvalds identified four patterns in the commit message.

The first was performance, as discussed above. It was a relic of an era when range-checking costs dominated, and lost its justification once STAC/CLAC costs became dominant.

The second was access to kernel pointers with exception handling. In fault handlers that needed to read values through unreliable kernel pointers, __get_user() was used to reuse its exception-handling machinery. There is now a dedicated helper, get_kernel_nofault(). This patch series replaced such uses with that helper in functions including dik_show_code() on Alpha and show_registers() on OpenRISC.

The third was avoiding warnings in atomic contexts. The standard get_user() includes might_fault(), which produces a warning when called in an atomic context. Developers used __get_user() to avoid that warning, but should instead have explicitly called pagefault_disable() to tell the kernel that page faults would not cause problems. The vdpa_sim driver fix is a typical example: adding pagefault_disable() alongside local_bh_disable() allowed the standard get_user() to be used without warnings.

The fourth was what Torvalds called "the really nasty cases": handling pointers that could refer to either kernel or user memory. A representative example is the #VC interrupt handler for x86 SEV (Secure Encrypted Virtualization). During MMIO emulation, the #VC handler needs to read or write user or kernel memory without knowing which kind of address it will receive. The patch replaced this with explicit vc_get_mem() and vc_put_mem() helpers, involving 205 lines of changes.

A major factor in making it possible to remove all these excuses was Thomas Gleixner's implementation of scoped user access region helpers in 2025 (commit e497310b4ffb). Block constructs such as scoped_user_read_access() and scoped_user_write_access() automatically manage opening and closing the access window, simplifying conversion patterns. Torvalds said they had "completely removed the old excuses for the horrors."

Figure omitted — see the original article

"A fancy coccinelle script"

The patch series began with a single patch Torvalds wrote himself as an example conversion. It rewrote the sigaction system call's signal-handling code into modern code using scoped user access.

The patches grew from there. Torvalds wrote on the dri-devel mailing list:

Yeah. I was using claude as a fancy coccinelle script and ended up doing the ObviouslyCorrect safe cases too.

Coccinelle is a source-code transformation tool widely used in the Linux kernel, specializing in bulk changes through pattern matching. Torvalds' conversions involved repeatedly applying structured patterns, making this use of an LLM closer to pattern application than code generation. Following last week's associative array bug fixes (in Japanese) and page-cache improvements using Claude Code (in Japanese), Torvalds' integration of AI into practical kernel development is gathering pace.

Review also progressed on the mailing list. x86 maintainer Ingo Molnar confirmed successful builds and boots on both 64-bit and 32-bit systems, while vhost maintainer Michael S. Tsirkin reported passing tests in a VM and supplied an Acked-by.

Torvalds was candid about the decision to merge:

I am not saying the patches are perfect. But they are an improvement. It is better to merge early and find problems than to leave known broken code in place.

The i915 graphics driver still contained an old comment dating back to verify_area(VERIFY_WRITE) in the Linux 2.5.x era. It was a remnant of code written for COW handling in 32-bit kernels, whose purpose had ended more than 20 years ago. This patch series finally cleared it away.

Gone from x86; the rest depends on motivation

The 48-commit series removed all __get_user()/__put_user() calls from generic code (areas shared by all architectures, such as kernel/, drivers/, and net/). On x86, it removed the entire interface, from header macro definitions to assembly implementation functions. The four __get_user_nocheck_1/2/4/8 functions disappeared from getuser.S, along with their four counterparts in putuser.S.

Some uses remain on other architectures. On arm64, __get_user() and get_user() already had identical implementations, so leaving them alone is harmless: they do not pose the risk of skipping validation. On architectures using asm-generic/uaccess.h, the names remain as internal helpers.

Conversions on sparc32, m68k, LoongArch, PA-RISC, and MIPS were nontrivial, and Torvalds did not tackle them. His words on the mailing list capture the nature of the work:

I looked at the sparc32 signal-handling case and decided somebody else should do it. It is too ugly, and I have no energy left to care. The same goes for m68k, loongarch, parisc, and mips. I ran out of motivation.

I confirmed that the commit's diffstat includes changes to 50 files, with signal and trap handling rewritten across architectures including Alpha, ARM, Hexagon, Nios II, OpenRISC, PowerPC, and s390.

Figure omitted — see the original article

Clearing out technical debt is always unglamorous work. Unlike adding features, the effect of deleted code is not visible. But removing __get_user() from the Linux kernel means eliminating the room on x86 for someone to decide that skipping validation is probably acceptable. A compromise once tolerated for speed had lost that speed, leaving only the risk. When Torvalds wrote that this should have been done years ago, he was stating a fact, rather than expressing regret.

Originally published on Joho no Todai. The Japanese original is here.

Chrome Enhanced Protection Checks Suspicious Copied Commands, Sends Them After Removing Identifying Information

Joho no Todai — Wed, 21 Oct 2026 15:02:55 +0000

Chrome's Enhanced protection detects suspicious commands copied as part of scams, sends them to Google after processing them to remove personally identifiable information, and warns users if they are dangerous. Gemini's analysis of scam pages has also moved to the server side.

Key points

What it detects: Chrome's Enhanced protection detects suspicious commands copied through ClickFix scams and warns users if they are dangerous.
What gets sent: Chrome processes suspicious copied content to remove personally identifiable information, then sends it to Safe Browsing to assess the risk.
Broader scam detection: Gemini analyzes pages on the server side, expanding detection to scams involving fake antivirus software and browser updates.
What users must weigh: Warnings about suspicious commands help users recognize danger, while the transmission of copied content to Google is another factor to consider when choosing a setting.

Checking suspicious commands as soon as they are copied

On October 20, 2026, local time, Google expanded Chrome's scam protections. Checks on copied commands apply to users who have enabled "Enhanced protection" in Chrome's Safe Browsing settings.

When Chrome detects a suspicious command being copied, it processes the content to remove information that could identify individuals and sends it to Google. If the command is judged dangerous, Chrome displays a warning.

Copying a command before executing it is now covered by these checks. Google says it designed the feature with an emphasis on precision to avoid disrupting legitimate command-line work by developers.

ClickFix is a scam technique that tricks users into copying and executing malicious commands themselves.

Why address actions outside the browser?

ClickFix prompts users to copy and execute commands under the pretext of fixing a nonexistent problem or completing a fake identity check. The command actually copied can differ from the text visible on the page.

Legitimate operating system programs, such as Windows PowerShell or cmd.exe, are abused. The command runs outside the browser. It can lead to malware being downloaded or launched without passing through the checks Chrome normally performs on file downloads.

In May 2026, researchers investigated ClickFix attacks (in Japanese) in which websites using the Ghost CMS publishing platform were compromised and fake human-verification pages directed visitors to execute commands.

Chrome's new detection targets the copy operation that occurs between a website's instructions and execution of an operating system command. Google cautions that Chrome never asks users to perform such actions to fix problems.

Different explanations for copied content and page text

Google's announcement says the check runs when an Enhanced protection user copies a suspicious command. It describes the detection and transmission of suspicious commands, rather than comprehensive collection of every copy operation or clipboard history.

Copied content is sent to a server after processing to remove personally identifiable information. In other words, deciding whether to show a warning involves sending the copied content outside the device. In this announcement, Google does not specify exactly what information it removes as personally identifiable or how long the transmitted commands are retained.

By contrast, Google says page text sent for Gemini's scam assessment is processed ephemerally, without logging, retention, or use in model training. This is an explanation about page text; it does not explicitly state whether the same retention policy applies to data transmitted from the clipboard.

Gemini analyzes scam pages on servers

In 2025, Google announced a system that ran Gemini Nano on supported devices in Chrome 137 to look for signs of fake technical support pages. It has now moved to a larger Gemini model running on servers.

The new model analyzes factors such as the company or service a page claims to represent, its purpose, and the likelihood that it is a scam. Joho no Todai confirmed that Safe Browsing makes the final decision, combining Gemini's analysis with factors such as the site's URL reputation.

This expands detection beyond fake technical support to scams impersonating antivirus software or browser updates. Google says the page text used for scam detection is sent to its servers only when a site shows strong signs of a scam.

Two warning levels, tied to Enhanced protection

Chrome is also changing its site warnings. It will show a new warning for sites suspected of being dangerous based on deceptive content or other signals. Sites classified as malicious with high confidence will continue to trigger a full-page red warning.

By distinguishing warnings about suspicious sites from those about dangerous sites, Google aims to flag more sites while conveying different levels of risk. These differentiated warnings also apply to Enhanced protection users.

Google's Japanese help page for desktop Chrome lists Safe Browsing's "Standard protection" as the default. Receiving warnings about suspicious copied commands requires enabling Enhanced protection.

Originally published on Joho no Todai. The Japanese original is here.

Torvalds' AI Patch Reaches RFC in One Week: Meta Developer Expands It to 18 Patches, With 4.5x Faster ext4 Reads

Joho no Todai — Tue, 20 Oct 2026 15:02:24 +0000

A Meta kernel developer reworked Torvalds' Claude Code-written page-cache patches into an 18-patch RFC series, reporting roughly 4.5x faster ext4 reads on LKML and up to 13x with mitigations disabled.

Key points

What happened: Meta's Kiryl Shutsemau reorganized Torvalds' LLM-generated, 10-patch proof of concept into an 18-patch RFC series and posted it to LKML
Performance: Roughly 4.5x faster reads on ext4 and 43x on tmpfs; roughly 13x on ext4 with mitigations disabled; almost no change with one thread
Mechanism: Deferring the freeing of frequently accessed folios until after an RCU grace period eliminates reference-count operations during reads
Current status: The patches remain at the RFC stage, with seven unresolved issues including a 64-bit restriction and a gap in memcg accounting; the Assisted-by: LLM tag has no bearing on mailing-list review criteria

From experiment to proposal in one week

Last week, Linus Torvalds used an LLM to write patches improving Linux kernel page-cache read performance (in Japanese). The 10-patch series showed roughly 23x faster reads, rising from 13.3 million to 304 million operations per second with 64 threads. As Torvalds himself acknowledged, however, these figures came from an extreme microbenchmark in which every CPU repeatedly reads the same location in the same file. He published a git branch rather than posting individual patches to the mailing list.

Six days later, on October 19, Meta kernel hacker Kiryl Shutsemau posted an 18-patch RFC series to LKML based on Torvalds' code.

Shutsemau is among the developers who have worked on this problem previously, having posted revised patches in October 2025. The new series reorganizes Torvalds' 10 patches with 11 additions of his own. Each of the seven original patches authored by Torvalds carries an Assisted-by: LLM tag.

Experimental AI-written code has been refined by another developer and submitted for formal review on the kernel mailing list.

What is slow, and why does this make it faster?

When Linux reads a file, data retrieved from disk is retained in the page cache. Subsequent reads of the same data return the in-memory copy without going back to disk.

The problem arises when multiple CPUs read the same file concurrently. The memory-management units in the page cache, called folios, are managed through reference counts that must be incremented and decremented on every read. These operations use atomic instructions, exclusive updates that guarantee consistency across CPUs. When 64 CPUs try to update the same folio's counter simultaneously, the cache line keeps bouncing between CPUs, and performance collapses.

The situation is worse on tmpfs, an in-memory file system. Each read acquires a folio lock as well as updating the reference count, so before the patches, even 64 threads delivered the same speed as one thread.

The patches address this by eliminating reference-count acquisition itself. Frequently accessed, "hot" folios receive the PG_rcu_free flag. Even after such a folio is freed, its memory is not reused until an RCU grace period, the interval allowing all CPUs to finish their current processing, has elapsed. Within that interval, readers can copy the data without touching the reference count at all.

The benefit is greater for data that is rarely written. Streaming reads and data accessed only once do not receive the flag, reportedly keeping the amount of memory retained through deferred freeing small.

4.5x on ext4, 43x on tmpfs

Shutsemau's benchmarks use a KVM guest with 64 virtual CPUs on an AMD Ryzen Threadripper 7975WX (Zen 4), based on Linux 7.3-rc7.

Results with 64 threads repeatedly performing 16-byte pread() calls at offset 0, each thread using its own file descriptor, vary considerably by file system.

Joho no Todai confirmed that with the default CPU vulnerability mitigations enabled, ext4 improved roughly 4.5x, from around 15 million operations per second to 68.9–70.1 million. tmpfs jumped roughly 43x, from 1.6–1.7 million to 71–72 million operations per second. Given that the folio lock had previously all but eliminated tmpfs's 64-thread parallelism, this jump shows how much potential was unlocked.

Figure omitted — see the original article

Disabling CPU vulnerability mitigations pushes the figures higher still. ext4 reaches 217M–220M reads per second, roughly 13x faster. tmpfs reaches 230M–239M reads per second. According to the cover letter, default mitigations add about 400 nanoseconds of user/kernel boundary overhead per read, approximately 170 ns for TSA and 230 ns for SRSO, imposing a performance ceiling.

XFS and block devices see more modest improvements than ext4, roughly 1.8x and 2x respectively with 64 threads. Both acquire a shared i_rwsem lock on every read, so lock bouncing remains even after reference-count contention is removed.

In large-folio read tests using 64 KB reads, 64 threads, and one file, huge tmpfs improves from 96–100k MiB/s to 1370–1390k MiB/s, while ext4 rises from 756–775k MiB/s to 1355–1373k MiB/s, substantial gains in both cases.

Single-thread read performance shows no significant change, moving from 1.6–1.9 million to 1.7–2 million operations per second. Where reference-count contention does not arise, the patches' overhead also remains close to zero.

Still an RFC

The patches' subject lines say [RFC PATCH]. In kernel development, RFC, or Request for Comments, means patches seeking feedback on the design direction. They are not a formal submission for merging.

The cover letter lists seven unresolved issues. The PG_rcu_free page flag is available only on 64-bit systems and consumes one of the reference bits used by MGLRU (Multi-Generational LRU, a page-reclaim algorithm) on large configurations. Other issues include a grace period during which folios awaiting deferred freeing are not accounted to any memcg (memory cgroup), and delayed freeing of pageblocks after compaction.

Multiple developers have worked on page-cache reference counting since Matthew Wilcox described it as a buffered-I/O scalability limit several years ago. Shutsemau tackled it himself in 2025, while Ilya Gladyshev pursued another approach through six revisions. The new patches build on the issues those attempts left unresolved.

The speed with which Torvalds' LLM-written proof of concept became a formal RFC patch series in six days is noteworthy, but from here onward, code design and quality are what matter. The Assisted-by: LLM tag has no bearing on whether the patches pass mailing-list review.

Originally published on Joho no Todai. The Japanese original is here.