Re: [PATCH 00/11] Convert moduleparams to seq_buf
Kees Cook <[email protected]> Mon, 1 Jun 2026 12:59:49 -0700
| Newsgroups | org.infradead.lists.linux-um,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.dmaengine,org.kernel.vger.kvm,org.kernel.vger.linux-acpi,org.kernel.vger.linux-arch,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.linux-modules,org.kernel.vger.linux-pci,org.kernel.vger.linux-pm,org.kernel.vger.linux-rdma,org.kernel.vger.linux-scsi,org.kernel.vger.linux-security-module,org.kernel.vger.linux-serial,org.kernel.vger.linux-usb,org.kernel.vger.netdev,org.kvack.linux-mm,org.nongnu.qemu-devel,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <202606011259.CE6E74CE@keescook> |
On Tue, May 26, 2026 at 08:53:06AM +0200, Petr Pavlu wrote: > On 5/21/26 3:33 PM, Kees Cook wrote: > > Hi, > > > > I tried to trim the CC list here, but it's still pretty huge... > > > > We've had a long-standing issue with "write to a string pointer" callbacks > > that don't bounds check the destination (and for which the bounds is > > also not part of the callback prototype, even if it is "known" to be > > PAGE_SIZE, which sysfs_emit() depends on). Both moduleparams and sysfs > > use this pattern. As a first step, and to test the migration method, > > migrate moduleparams first. > > > > There are 2 "mechanical" treewide patches that are handled by Coccinelle: > > - treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS > > - treewide: Convert custom kernel_param_ops .get callbacks to seq_buf via cocci > > > > The last treewide patch is manual, and may need to be broken up into > > per-subsystem patches, though I'd prefer to avoid this, as it would > > extend the migration from 1 relase to at least 2 releases. (1 to > > release the migration infrastructure, then 1 release to collect all the > > subsystem changes, and possibly 1 more release to remove the migration > > infrastructure.) > > > > Thoughts, questions? > > This looks reasonable to me. I added a few minor comments on the patches > but they already look solid. Thanks for the review! I'll get a v2 prepared with your notes addressed. :) -Kees -- Kees Cook