[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- 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 Bionic: Fix Committed Status in linux source package in Disco: Fix Released 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- 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 Bionic: Fix Committed Status in linux source package in Disco: Fix Released 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
** Tags added: cscc -- 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 Bionic: Fix Committed Status in linux source package in Disco: Fix Released 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
This bug was fixed in the package linux - 5.0.0-21.22 --- linux (5.0.0-21.22) disco; urgency=medium * linux: 5.0.0-21.22 -proposed tracker (LP: #1834902) * Disco update: 5.0.15 upstream stable release (LP: #1834529) - net: stmmac: Use bfsize1 in ndesc_init_rx_desc - Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup() - ubsan: Fix nasty -Wbuiltin-declaration-mismatch GCC-9 warnings - staging: greybus: power_supply: fix prop-descriptor request size - staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context. - staging: most: cdev: fix chrdev_region leak in mod_exit - staging: most: sound: pass correct device when creating a sound card - ASoC: tlv320aic3x: fix reset gpio reference counting - ASoC: hdmi-codec: fix S/PDIF DAI - ASoC: stm32: sai: fix iec958 controls indexation - ASoC: stm32: sai: fix exposed capabilities in spdif mode - ASoC: stm32: sai: fix race condition in irq handler - ASoC:soc-pcm:fix a codec fixup issue in TDM case - ASoC:hdac_hda:use correct format to setup hda codec - ASoC:intel:skl:fix a simultaneous playback & capture issue on hda platform - ASoC: dpcm: prevent snd_soc_dpcm use after free - ASoC: nau8824: fix the issue of the widget with prefix name - ASoC: nau8810: fix the issue of widget with prefixed name - ASoC: samsung: odroid: Fix clock configuration for 44100 sample rate - ASoC: rt5682: Check JD status when system resume - ASoC: rt5682: fix jack type detection issue - ASoC: rt5682: recording has no sound after booting - ASoC: wm_adsp: Add locking to wm_adsp2_bus_error - clk: meson-gxbb: round the vdec dividers to closest - ASoC: stm32: dfsdm: manage multiple prepare - ASoC: stm32: dfsdm: fix debugfs warnings on entry creation - ASoC: cs4270: Set auto-increment bit for register writes - ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol - drm/omap: hdmi4_cec: Fix CEC clock handling for PM - IB/hfi1: Clear the IOWAIT pending bits when QP is put into error state - IB/hfi1: Eliminate opcode tests on mr deref - IB/hfi1: Fix the allocation of RSM table - MIPS: KGDB: fix kgdb support for SMP platforms. - ASoC: tlv320aic32x4: Fix Common Pins - drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata() - perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS - perf/x86/intel: Initialize TFA MSR - linux/kernel.h: Use parentheses around argument in u64_to_user_ptr() - iov_iter: Fix build error without CONFIG_CRYPTO - xtensa: fix initialization of pt_regs::syscall in start_thread - ASoC: rockchip: pdm: fix regmap_ops hang issue - drm/amdkfd: Add picasso pci id - drm/amdgpu: Adjust IB test timeout for XGMI configuration - drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in shadow_list - drm/amd/display: fix cursor black issue - ASoC: cs35l35: Disable regulators on driver removal - objtool: Add rewind_stack_do_exit() to the noreturn list - slab: fix a crash by reading /proc/slab_allocators - drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind - virtio_pci: fix a NULL pointer reference in vp_del_vqs - RDMA/vmw_pvrdma: Fix memory leak on pvrdma_pci_remove - RDMA/hns: Fix bug that caused srq creation to fail - KEYS: trusted: fix -Wvarags warning - scsi: csiostor: fix missing data copy in csio_scsi_err_handler() - drm/mediatek: fix possible object reference leak - drm/mediatek: fix the rate and divder of hdmi phy for MT2701 - drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phy - drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phy - drm/mediatek: using new factor for tvdpll for MT2701 hdmi phy - drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy - ASoC: Intel: kbl: fix wrong number of channels - ASoC: stm32: sai: fix master clock management - ALSA: hda: Fix racy display power access - virtio-blk: limit number of hw queues by nr_cpu_ids - blk-mq: introduce blk_mq_complete_request_sync() - nvme: cancel request synchronously - nvme-fc: correct csn initialization and increments on error - nvmet: fix discover log page when offsets are used - platform/x86: pmc_atom: Drop __initconst on dmi table - NFSv4.1 fix incorrect return value in copy_file_range - perf/core: Fix perf_event_disable_inatomic() race - genirq: Prevent use-after-free and work list corruption - usb: dwc3: Allow building USB_DWC3_QCOM without EXTCON - usb: dwc3: Fix default lpm_nyet_threshold value - USB: serial: f81232: fix interrupt worker not stop - USB: cdc-acm: fix unthrottle races - usb-storage: Set virt_boundary_mask to avoid SG overflows - intel_th: pci: Add Comet Lake support - iio: adc: qcom-spmi-adc5: Fix of-based
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Bionic) Status: New => Fix Committed ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Andrea Righi (arighi) -- 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 Bionic: Fix Committed 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
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 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-disco -- 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 Committed 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
[Kernel-packages] [Bug 1834479] Re: depmod may prefer unsigned l-r-m nvidia modules to signed modules
** Changed in: linux (Ubuntu Disco) Status: In Progress => Fix Committed -- 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 Committed 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
