[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM=PXV6VU82easb_v74JaMAb+1dAkQvRqp0iw2p-Rsb9pjyFQA@mail.gmail.com>
Date: Sat, 19 Sep 2026 14:50:50 -0600
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: A quartet of Linux local root vulns: DirtyAH6,
PPPoEject, TUNderflow, and DiagSpill
I may be missing something but I do see a path that may be clean
without inventing new package manager features or relying on brittle,
text-based version strings. The concern regarding loose version
matching and local source rebuilds breaking the ABI is real, but IMHO
we don't need to invent a new package manager feature to fix it.
As long as `CONFIG_MODVERSIONS` is enabled, why not simply hash a
sorted version of CRCs Module.symvers, (maybe needing to use
KBUILD_EXTRA_SYMBOLS for external dependencies? for some distros)
Then use `Provides: kernel-abi-token = <hash>` and `Depends:
kernel-abi-token = <hash>` and let people use weak depanancies.
You could have a monolithic source recipe, but the automated build
pipeline programmatically spits out separate .deb, .rpm, or
.pkg.tar.zst files for each module.
There is a complexity shift to the repository infrastructure but does
not require sub-packaging and also solves the local build conflict
problem at least in the common case I am thinking about.
I guess the recommends may get a bit large and require metapackages by
following the simplest pattern:
```
Package: linux-image-generic
Recommends: linux-module-pppoe, linux-module-sctp, linux-module-rds, ...
```
So there may be some risk based packaging decisions to make or...
To me it seems that `Provides: kernel-abi-token = <hash>` resolves
many of the above concerns.
On Fri, Sep 18, 2026 at 11:57 AM Eli Schwartz <eschwartz@...too.org> wrote:
>
> On 9/18/26 11:30 AM, Kevin Riggle wrote:
> > Would it be as conceptually straightforward on the distro side as
> > breaking most of these less-common modules out into their own
> > packages, e.g. linux-module-pppoe, linux-module-sctp, etc?
>
> That is exactly what Hanno said to do, so I presume that he thinks it is
> as simple as that.
>
> There are, of course, challenges. Not all distribution package managers
> support split subpackages -- the Gentoo package manager does not, albeit
> people often compile from source on that distro ;) so it is redundant
> for the most part but also impossible to implement for
> "gentoo-kernel-bin", or for `--getbinpkg "gentoo-kernel"`.
>
> It also opens up a slightly worrying concern, that if you don't ship the
> whole thing together they can get out of sync. I doubt it would be very
> good for ABI if modules can be built against one kernel .config, then
> loaded against a very different one because package managers aren't
> describing the binding between two packages with anything closer than a
>
> rundepend="
> ${parent_package}==${exact_release_tag}-${monotonic_integer_buildid}
>
> "
>
> Depending on package manager, buildid may be stored as:
>
> - part of the "Version" field (e.g. debian) and defined purely as a
> versioning convention
>
> - some extra field that is parsed as a version, e.g. Gentoo "${PR}"
> (package revision) or Arch Linux "pkgrel", rpm "Release:", etc.
>
>
> Where it exists, it inevitably refers to a text value in a build recipe.
> For rpm, you can use %autorelease which parses git log; it doesn't
> really solve the problem here.
>
> So you would have to be very careful about consistently incrementing
> that and then it would break anyway if someone decides to rebuild an
> existing package from source, which, well, *kernels* and people
> rebuilding from source. ;) Hardly uncommon.
>
> It's quite rare for software to need such tight binding. So adding such
> a package manager feature (to bind subpackages to an extra metadata
> field outside of version + revision/buildid, probably a UUID or hash) is
> potentially a lot of one-off effort.
>
> ...
>
> Alternatively, kernels could ship with a default /usr/lib/modprobe.d
> file that sets "install ... /bin/false" for modules that are shipped but
> "a bad idea unless you really know you need it". The size of the
> resulting package cannot be minimized by dropping unneeded large files,
> but that's the status quo today. It seems eminently reasonable that this
> would solve the security issue, and people could install an override in
> /etc/modprobe.d for any modules they don't want to be masked.
>
> Some distros also have a package manager config file setting
> (INSTALL_MASK, NoExtract) to skip individual filenames or filename globs
> from being unpacked by any package. It is a bit bulky to use (one record
> per module you don't use) and likely not suitable for automatic
> deployment with user opt-out as it's quite disruptive if you do end up
> needing the module.
>
>
> --
> Eli Schwartz
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
