Kernel & Embedded News: __get_user() Removed in 7.4; ZDI Bugs Leak

Linux 7.3 shipped on 18 October (our full release coverage) and the 7.4 merge window is now open, with no rc1 tagged as of this writing. This edition covers a removed user-space access API, the public disclosure of unpatched vulnerabilities, and three merge-window changes affecting process teardown, build times and early boot.

In this edition

• __get_user() and __put_user() are removed in Linux 7.4. Linus Torvalds merged a 48-commit cleanup that deletes the unchecked user-space access primitives from generic kernel code. — audit your out-of-tree drivers
• Unpatched kernel vulnerability reports reach public mailing lists. Five Zero Day Initiative reports, including two CVSS 9.0 remote-code-execution bugs in the in-kernel SMB server, were posted publicly before fixes shipped. — act now if you run ksmbd
• exit, exec and close_range() now close files synchronously. A VFS change in 7.4 stops deferring the final file release to task work. — note the behavior change
• Kernel build-speed patches start landing. The first part of a 23-patch series reached 7.4, with the full series claiming up to 36% faster clean builds. — workflow gain
• memblock gets binary search. A fix in the early boot-time allocator cuts one pathological boot path from minutes to milliseconds. — planning signal

__get_user() and __put_user() are gone: check your driver code

During the 7.4 merge window, Linus Torvalds merged a 48-commit branch — much of it written by him personally — that removes __get_user() and __put_user() from generic kernel code. The merge touches 50 files, from arm, powerpc and s390 signal code to the i915, vhost and Xen drivers. On x86 the two functions are removed entirely; arm64 had already defined them as aliases of the checked versions; a few architectures retain internal remnants for now.

The double-underscore variants skipped the user-address range check for speed in hot paths, on the assumption that the caller had already validated the pointer. The merge commit makes two arguments for removing them. First, the performance argument no longer holds: on modern CPUs the dominant cost of a user access is toggling the access-permission state (STAC/CLAC on x86), not the range check, so the unchecked variants are no faster. Second, they are a standing source of security bugs, because nothing in the call itself validates that the pointer refers to user memory.

The replacements are already in the tree. Use get_user() and put_user() for single checked accesses. Where several accesses share one validation, use the scoped user access regions — scoped_user_read_access() and scoped_user_write_access() with unsafe_get_user()/unsafe_put_user() inside. For kernel pointers that may be unreliable, get_kernel_nofault() is the correct tool.

One process detail is worth recording: Torvalds wrote that he used an LLM “as a glorified coccinelle script” to apply the conversion pattern across call sites. The pattern — the tool applies the transformation, the maintainer designs and reviews — is becoming the accepted shape of AI use in kernel work.

How to check your driver code

If you maintain out-of-tree modules or a vendor BSP patch stack, scan for the removed primitives now:

raghu@techveda.org:~$ grep -rn "__get_user\|__put_user" drivers/your_driver/ --include="*.c" --include="*.h"

Code that calls them will fail to build against 7.4 on x86, and the same removal will reach other architectures in later cycles. Most conversions are mechanical — drop the underscores and delete the now-redundant access_ok() call — and loops over user buffers convert cleanly to one scoped region. Kernels pinned to current LTS series are unaffected until you rebase, but new driver code should use the checked interfaces from today.

Five unpatched vulnerability reports reach public mailing lists

On 21 October, Trend Micro’s Zero Day Initiative sent a batch of Linux kernel vulnerability reports to security@kernel.org — with public mailing lists (linux-kernel, linux-cifs, netdev, dri-devel) in Cc. Full technical detail, including reproduction steps and KASAN traces, became public before fixes existed in any release. Greg Kroah-Hartman replied to each report the next day, objecting and asking the organisation to fix its submission process.

The two serious reports concern the in-kernel SMB server. ZDI-CAN-33549 is an integer underflow in the SMB Direct (RDMA) transport, and ZDI-CAN-33774 is a race condition in protocol dispatch; both are remote code execution and both carry a ZDI severity rating of CVSS 9.0. The remaining three are a local privilege escalation in skb_zerocopy() (ZDI-CAN-33367, rated 7.8), an out-of-bounds write in the vmwgfx graphics driver (ZDI-CAN-34068), and an information leak in the NVMe target (ZDI-CAN-34076). The reports were produced against 7.3-rc kernels, and no CVE numbers had been assigned at disclosure.

Fix status at the time of writing: the ksmbd race fix already exists in maintainer Namjae Jeon’s tree; Stefan Metzmacher expects his SMB Direct rework headed for 7.5 to cover the underflow; and the skb_zerocopy() issue, which Eric Dumazet noted had been reported independently a week earlier, has a fix under review. None of this has reached a stable release yet.

If a device you ship runs ksmbd, treat these reports as public exploit documentation and plan mitigation now, before the stable backports arrive. ksmbd is used on NAS-class and file-sharing embedded products because it is lighter than Samba, so this is an embedded problem, not only a server one.

How to check your device

raghu@techveda.org:~$ lsmod | grep ksmbd
raghu@techveda.org:~$ zcat /proc/config.gz | grep "CONFIG_SMB_SERVER"

If ksmbd is built but unused, blacklist or unload the module until fixed kernels ship. The SMB Direct bug additionally requires CONFIG_SMB_SERVER_SMBDIRECT and RDMA-capable hardware, which is rare on embedded boards — the dispatch race is the one that applies to a plain ksmbd deployment. The skb_zerocopy() escalation matters most on systems that run untrusted local code, such as container hosts. Track the fixes in our weekly kernel CVE patch tracker once CVE identifiers are assigned.

exit, exec and close_range() now close files synchronously

A VFS change by Christian Brauner, merged for 7.4, makes the kernel close file descriptors synchronously during close_range(), exec and process exit. Until now, these paths queued each file’s final release (fput()) as task work and ran it later. close(2) itself was always synchronous and is unchanged, and kernel threads are not affected.

The motivation is cost. For a process with a large descriptor table, deferred closing meant per-file atomic operations and task-work bookkeeping, then a second pass over file structures that had gone cold in the CPU cache. The measured gains: 16–21% faster descriptor-table teardown for a single process closing between 65,536 and one million descriptors, falling to 4–8% when 32 to 64 processes tear down tables concurrently. File types with heavier release paths gain less — around 13% for eventfds, 11% for pipes, 6% for AF_UNIX sockets.

The change grew out of an 18-patch coredump series that lets a coredump server drop a crashing process’s descriptor table before the dump is written; synchronous teardown is the prerequisite, and Brauner argues it is worth having on its own.

What it means for your system

There is nothing to configure; restart-heavy services and process-per-request designs simply get a slightly faster exec and exit path. The point to note is ordering: from 7.4, the final release of a file — your driver’s release() callback, lock release, any teardown driven by the last reference — completes before close_range(), exec or exit returns, rather than at some later task-work moment. Code and tests that implicitly depended on the old deferred timing should be re-checked on 7.4, and drivers with slow release() paths now add that latency directly to process exit.

Kernel builds are getting faster, in parts

The first portion of Lorenzo Stoakes’ 23-patch build-speed series, posted on 8 September, was merged for 7.4. The merged subset includes faster kallsyms generation, mksysmap reimplemented in C instead of shell, removal of unneeded sorting steps, emitting relocations only at the final vmlinux link, caching of cc-option/ld-option compiler probes, keeping .modinfo out of vmlinux, and using pigz for kernel compression when available.

The widely quoted numbers belong to the full series, not this subset: up to 36% faster allmodconfig builds, around 70% faster incremental builds, and around 90% faster no-op rebuilds. On the author’s own machine, a full build with a cold ccache went from roughly 960 to 860 seconds. Figures for what 7.4 alone delivers are not yet published, so expect a smaller, still useful improvement until the rest lands.

The remaining parts — modpost caching, parallel objtool, building Rust crates in parallel — are still under review, with the parallel-Rust patch flagged as the risky one because the compiler’s parallel mode is not yet fully stable. This series also used an LLM to locate bottlenecks, with the author auditing and rewriting the result; Torvalds engaged on the kallsyms design.

How to use it

Nothing needs enabling, with one exception: install pigz on build hosts so compression parallelises.

raghu@techveda.org:~$ sudo apt install pigz

Measure your own delta once 7.4-rc1 is out, against your real configs rather than allmodconfig. The incremental and no-op gains matter most for daily driver development and training-lab work, where the compile-test loop dominates. CI pipelines that build many configurations per run should re-baseline their job times on 7.4.

memblock learns binary search: a boot-time scaling lesson

Tarun Sahu’s patch, merged through Mike Rapoport’s memblock tree for 7.4, replaces the linear scans in memblock_add_range() and memblock_isolate_range() with a binary search via a new memblock_bsearch_start() helper. Worst-case complexity for building the memory map drops from O(N²) to O(N log N).

The motivating workload is KHO — Kexec HandOver — which preserves memory contents across a kexec so that a running system can be live-updated without losing state. KHO can register hundreds of thousands of disjoint memory ranges at boot, and with the old linear scan, retrieving 393,000 preserved pages took about 268 seconds. With binary search it takes about 50 milliseconds. These are the patch author’s measurements; one independent tester in the review thread reported SLUB initialisation on his system dropping from about 38.6 seconds to 0.5 seconds with transparent hugepages disabled.

An ordinary embedded board with a handful of memory regions will not measure any difference. The item still matters: kexec-based live update is maturing into infrastructure that large fleets depend on, and its supporting data structures are now being made to scale. It is also a clear example of a boot-time failure class: a linear scan that costs nothing at ten regions and takes minutes at a hundred thousand. Boot-time work on embedded products regularly finds the same pattern in other places.

How to evaluate it

When working on boot time, make memblock’s behaviour visible before assuming it is not a factor. Boot with memblock=debug on the kernel command line to log every memblock operation, and on kernels built with CONFIG_ARCH_KEEP_MEMBLOCK and debugfs, inspect the region count after boot:

raghu@techveda.org:~$ sudo cat /sys/kernel/debug/memblock/memory

A region count in the tens is normal; a count in the thousands — from aggressive device-tree reserved-memory carving, EFI fragmentation or handover mechanisms — is where pre-7.4 kernels pay the quadratic cost. If your platform plans to adopt kexec live update, 7.4 is the series where its boot-time cost becomes realistic.

References

• Merge __{get,put}_user() removal branch — torvalds/linux
• Several Linux kernel vulnerabilities accidentally posted to public mailing list
• ZDI-CAN-33549 report thread (SMB Direct)
• ZDI-CAN-33774 report thread (ksmbd)
• Linux 7.4 to close files synchronously for close_range, exec and exit
• Linux 7.4 begins landing patches to speed up the kernel build process
• memblock: use binary search to locate candidate regions — patch thread

— Raghu Bharadwaj