This bug was fixed in the package linux - 5.2.0-8.9
---------------
linux (5.2.0-8.9) eoan; urgency=medium
* linux: 5.2.0-8.9 -proposed tracker (LP: #1835700)
* Miscellaneous Ubuntu changes
- [Packaging] replace zfs and spl build with zfs 0.8.1-1ubuntu1
- SAUCE: test_bpf: remove expected fail for Ctx heavy transformations test
on
s390
- SAUCE: add -fcf-protection=none to retpoline flags
- SAUCE: usbip: ensure strings copied using strncpy are null-terminated
- SAUCE: usbip: add -Wno-address-of-packed-member to EXTRA_CFLAGS
- SAUCE: perf jvmti: ensure strncpy result is null-terminated
- update dkms package versions
- add removed zfs modules to modules.ignore
[ Upstream Kernel Changes ]
* Rebase to v5.2
-- Seth Forshee <seth.fors...@canonical.com> Mon, 08 Jul 2019 07:13:41
-0500
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1834479
Title:
depmod may prefer unsigned l-r-m nvidia modules to signed modules
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Disco:
Fix Committed
Bug description:
Impact: When testing patches for bug 1834476, a bug was observed
whereby modprobe was someties attempting to load the unsigned nvidia
modules in /lib/modules/$(uname -r)/kernel/nvidia-N/bits rather than
the signed modules from /lib/modules/$(uname -r)/kernel/nvidia-N. This
appears to be because depmod is not deterministic in which module will
be preferred when duplicate modules of the same name exist.
Fix: The unsigned modules are no longer needed after the signed
modules have been generated, so update the build script to remove the
unsigned modules.
Test Case: Confirm that the ko files are found in /lib/modules/$(uname
-r)/kernel/nvidia-N but not in /lib/modules/$(uname
-r)/kernel/nvidia-N/bits. Confirm that the modules are signed and
loadable by the kernel under lockdown (or when booted with
modules.sig_enforce=y), and that modprobe consistently loads the
modules from the expected path after depmod.
Regression Potential: The modules being removed are an intermediate
build artifact and not meant to be loaded, so no regressions are
expected. However, if for some reason linking the intermediate
unsigned module was successful but generation of the signed module was
not, the user would have been left with a module that could
potentially be loaded (if not booted under UEFI secure boot) and would
now be left with no modules. This is not the intended behavior and
never occurred in my testing, so it's not a case we should be
concerned about.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834479/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
