| 2018-10-19 16:50:59 |
Daniel Dadap |
bug |
|
|
added bug |
| 2018-10-19 16:50:59 |
Daniel Dadap |
attachment added |
|
apport data from affected system https://bugs.launchpad.net/bugs/1798863/+attachment/5203120/+files/apport.linux-image-4.18.0-10-generic.c_cz4acm.apport |
|
| 2018-10-19 16:52:52 |
Daniel Dadap |
description |
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) |
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. |
|
| 2018-10-19 17:00:06 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2018-10-23 17:09:12 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2018-10-23 17:10:17 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-10-23 17:10:17 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Cosmic) |
|
| 2018-10-24 14:12:34 |
Daniel Dadap |
tags |
|
apport-collected cosmic |
|
| 2018-10-24 14:12:35 |
Daniel Dadap |
description |
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. |
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way.
---
ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: danix 1729 F.... pulseaudio
DistroRelease: Ubuntu 18.10
InstallationDate: Installed on 2018-10-23 (0 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
NonfreeKernelModules: nvidia_uvm nvidia
Package: linux (not installed)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
RelatedPackageVersions:
linux-restricted-modules-4.18.0-10-generic N/A
linux-backports-modules-4.18.0-10-generic N/A
linux-firmware 1.175
Tags: cosmic
Uname: Linux 4.18.0-10-generic x86_64
UnreportableReason: This report is about a package that is not installed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: False
dmi.bios.date: 03/20/2018
dmi.bios.vendor: HP
dmi.bios.version: P70 Ver. 01.18
dmi.board.name: 8270
dmi.board.vendor: HP
dmi.board.version: KBC Version 46.67
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr:
dmi.product.family: 103C_5336AN HP ZBook
dmi.sys.vendor: HP |
|
| 2018-10-24 14:12:37 |
Daniel Dadap |
attachment added |
|
AlsaInfo.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204908/+files/AlsaInfo.txt |
|
| 2018-10-24 14:12:38 |
Daniel Dadap |
attachment added |
|
CRDA.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204909/+files/CRDA.txt |
|
| 2018-10-24 14:12:40 |
Daniel Dadap |
attachment added |
|
CurrentDmesg.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204910/+files/CurrentDmesg.txt |
|
| 2018-10-24 14:12:42 |
Daniel Dadap |
attachment added |
|
IwConfig.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204911/+files/IwConfig.txt |
|
| 2018-10-24 14:12:45 |
Daniel Dadap |
attachment added |
|
Lspci.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204912/+files/Lspci.txt |
|
| 2018-10-24 14:12:46 |
Daniel Dadap |
attachment added |
|
Lsusb.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204913/+files/Lsusb.txt |
|
| 2018-10-24 14:12:48 |
Daniel Dadap |
attachment added |
|
ProcCpuinfoMinimal.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204914/+files/ProcCpuinfoMinimal.txt |
|
| 2018-10-24 14:12:50 |
Daniel Dadap |
attachment added |
|
ProcInterrupts.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204915/+files/ProcInterrupts.txt |
|
| 2018-10-24 14:12:52 |
Daniel Dadap |
attachment added |
|
ProcModules.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204916/+files/ProcModules.txt |
|
| 2018-10-24 14:12:53 |
Daniel Dadap |
attachment added |
|
PulseList.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204917/+files/PulseList.txt |
|
| 2018-10-24 14:12:55 |
Daniel Dadap |
attachment added |
|
RfKill.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204918/+files/RfKill.txt |
|
| 2018-10-24 14:12:58 |
Daniel Dadap |
attachment added |
|
UdevDb.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204919/+files/UdevDb.txt |
|
| 2018-10-24 14:13:01 |
Daniel Dadap |
attachment added |
|
WifiSyslog.txt https://bugs.launchpad.net/bugs/1798863/+attachment/5204920/+files/WifiSyslog.txt |
|
| 2018-10-24 16:55:36 |
Seth Forshee |
linux (Ubuntu Cosmic): status |
Incomplete |
Confirmed |
|
| 2018-10-24 16:55:36 |
Seth Forshee |
linux (Ubuntu Cosmic): assignee |
|
Seth Forshee (sforshee) |
|
| 2018-10-25 14:19:55 |
Seth Forshee |
linux (Ubuntu Cosmic): status |
Confirmed |
In Progress |
|
| 2018-10-25 17:35:57 |
Tyler Hicks |
bug |
|
|
added subscriber Tyler Hicks |
| 2018-10-25 18:19:24 |
Mathieu Trudel-Lapierre |
bug task added |
|
shim (Ubuntu) |
|
| 2018-10-25 18:19:33 |
Mathieu Trudel-Lapierre |
shim (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2018-10-25 18:19:35 |
Mathieu Trudel-Lapierre |
shim (Ubuntu Cosmic): importance |
Undecided |
Medium |
|
| 2018-10-25 18:19:37 |
Mathieu Trudel-Lapierre |
shim (Ubuntu Cosmic): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2018-10-25 19:22:08 |
Steve Langasek |
shim (Ubuntu Cosmic): status |
In Progress |
Invalid |
|
| 2018-10-25 23:26:51 |
Seth Arnold |
cve linked |
|
2018-18653 |
|
| 2018-10-26 16:03:29 |
Seth Forshee |
description |
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way.
---
ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: danix 1729 F.... pulseaudio
DistroRelease: Ubuntu 18.10
InstallationDate: Installed on 2018-10-23 (0 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
NonfreeKernelModules: nvidia_uvm nvidia
Package: linux (not installed)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
RelatedPackageVersions:
linux-restricted-modules-4.18.0-10-generic N/A
linux-backports-modules-4.18.0-10-generic N/A
linux-firmware 1.175
Tags: cosmic
Uname: Linux 4.18.0-10-generic x86_64
UnreportableReason: This report is about a package that is not installed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: False
dmi.bios.date: 03/20/2018
dmi.bios.vendor: HP
dmi.bios.version: P70 Ver. 01.18
dmi.board.name: 8270
dmi.board.vendor: HP
dmi.board.version: KBC Version 46.67
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr:
dmi.product.family: 103C_5336AN HP ZBook
dmi.sys.vendor: HP |
SRU Justification
Impact: An bug in the secure boot lockdown patches in the 18.10 kernel causes the results of module signature verification to be ignored, allowing modules with no signature or an invalid signature to be loaded. A second bug results in the MOK not being trusted for signing modules, but this bug has been masked by the first bug.
Fix: These bugs should be fixed together to avoid regressions in dkms module loading under secure boot. First, fix the latter bug by trusting keys in the kernel's secondary keyring for module signing. Then fix the former bug by removing code related to trusting IMA signatures for loading modules under kernel lockdown.
Test Case: Confirm the following behavior under kernel lockdown:
1) Unsigned modules cannot be loaded.
2) Modules signed with an untrusted key cannot be loaded.
3) Modules signed with the kernel's ephemeral build-time key can be loaded.
4) Modules signed with a MOK which has been enrolled with shim can be loaded.
I have tested to verify these conditions with the proposed fixes.
Regression Potential: This restores the behavior from previous Ubuntu releases, so no regressions are expected wrt those releases. In some cases modules that were loading under lockdown might no longer load, but this is the intended behavior.
---
On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors:
* Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge.
* As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright.
* Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
* Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel.
Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key:
[ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
...
[ 6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel
...
[ 6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[ 6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
[ 6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way.
---
ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: danix 1729 F.... pulseaudio
DistroRelease: Ubuntu 18.10
InstallationDate: Installed on 2018-10-23 (0 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
NonfreeKernelModules: nvidia_uvm nvidia
Package: linux (not installed)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
RelatedPackageVersions:
linux-restricted-modules-4.18.0-10-generic N/A
linux-backports-modules-4.18.0-10-generic N/A
linux-firmware 1.175
Tags: cosmic
Uname: Linux 4.18.0-10-generic x86_64
UnreportableReason: This report is about a package that is not installed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: False
dmi.bios.date: 03/20/2018
dmi.bios.vendor: HP
dmi.bios.version: P70 Ver. 01.18
dmi.board.name: 8270
dmi.board.vendor: HP
dmi.board.version: KBC Version 46.67
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr:
dmi.product.family: 103C_5336AN HP ZBook
dmi.sys.vendor: HP |
|
| 2018-11-08 10:50:31 |
Stefan Bader |
linux (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2018-11-13 10:00:07 |
Nichita Uțiu |
bug |
|
|
added subscriber Nichita Uțiu |
| 2018-11-15 11:03:51 |
Brad Figg |
tags |
apport-collected cosmic |
apport-collected cosmic verification-needed-cosmic |
|
| 2018-11-25 00:09:40 |
Thanh Tung |
linux (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-11-26 11:27:35 |
Kleber Sacilotto de Souza |
linux (Ubuntu Cosmic): status |
Fix Released |
Fix Committed |
|
| 2018-11-28 13:16:46 |
Kleber Sacilotto de Souza |
tags |
apport-collected cosmic verification-needed-cosmic |
apport-collected cosmic verification-done-cosmic |
|
| 2018-12-03 08:49:32 |
Launchpad Janitor |
linux (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-12-03 08:49:32 |
Launchpad Janitor |
cve linked |
|
2018-18955 |
|
| 2018-12-03 08:49:32 |
Launchpad Janitor |
cve linked |
|
2018-6559 |
|
| 2019-02-14 12:11:20 |
Brad Figg |
tags |
apport-collected cosmic verification-done-cosmic |
apport-collected cosmic verification-done-cosmic verification-needed-bionic |
|
| 2019-02-14 16:55:02 |
Andy Whitcroft |
tags |
apport-collected cosmic verification-done-cosmic verification-needed-bionic |
apport-collected cosmic kernel-fixup-verification-needed-bionic verification-done-bionic verification-done-cosmic |
|
| 2019-02-18 12:25:10 |
Seth Forshee |
linux (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-07-24 21:16:36 |
Brad Figg |
tags |
apport-collected cosmic kernel-fixup-verification-needed-bionic verification-done-bionic verification-done-cosmic |
apport-collected cosmic cscc kernel-fixup-verification-needed-bionic verification-done-bionic verification-done-cosmic |
|
