[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
Yes, there are solutions to this that don't expose the whole kernel to
root.
* This project's kernel module could use DKMS. This could make use of the MOK
workflow already present in Ubuntu.
* This project's kernel module could be included in the upstream kernel.
The last option would be more secure, but more difficult to achieve.
I don't think this can be solved in Ubuntu, so let's continue this
discussion in the first upstream issue you linked. (Although I'd
probably need to take a look at the source code and I don't know any
C#.)
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Disco:
Fix Released
Status in linux source package in Eoan:
Fix Released
Status in linux source package in Focal:
Fix Released
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
I believe this fix causes a regression with NoteBook Fan Control (NBFC) as
lifting the kernel lockdown was used as a workaround to enable NBFC to control
fan speed.
See https://github.com/hirschmann/nbfc/issues/414#issuecomment-354274657 and
https://github.com/hirschmann/nbfc/issues/472
Would there be another workaround than "simply" disable UEFI secure
boot?
** Bug watch added: github.com/hirschmann/nbfc/issues #414
https://github.com/hirschmann/nbfc/issues/414
** Bug watch added: github.com/hirschmann/nbfc/issues #472
https://github.com/hirschmann/nbfc/issues/472
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Disco:
Fix Released
Status in linux source package in Eoan:
Fix Released
Status in linux source package in Focal:
Fix Released
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate:
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
This bug was fixed in the package linux - 5.3.0-24.26 --- linux (5.3.0-24.26) eoan; urgency=medium * eoan/linux: 5.3.0-24.26 -proposed tracker (LP: #1852232) * Eoan update: 5.3.9 upstream stable release (LP: #1851550) - io_uring: fix up O_NONBLOCK handling for sockets - dm snapshot: introduce account_start_copy() and account_end_copy() - dm snapshot: rework COW throttling to fix deadlock - Btrfs: fix inode cache block reserve leak on failure to allocate data space - btrfs: qgroup: Always free PREALLOC META reserve in btrfs_delalloc_release_extents() - iio: adc: meson_saradc: Fix memory allocation order - iio: fix center temperature of bmc150-accel-core - libsubcmd: Make _FORTIFY_SOURCE defines dependent on the feature - perf tests: Avoid raising SEGV using an obvious NULL dereference - perf map: Fix overlapped map handling - perf script brstackinsn: Fix recovery from LBR/binary mismatch - perf jevents: Fix period for Intel fixed counters - perf tools: Propagate get_cpuid() error - perf annotate: Propagate perf_env__arch() error - perf annotate: Fix the signedness of failure returns - perf annotate: Propagate the symbol__annotate() error return - perf annotate: Fix arch specific ->init() failure errors - perf annotate: Return appropriate error code for allocation failures - perf annotate: Don't return -1 for error when doing BPF disassembly - staging: rtl8188eu: fix null dereference when kzalloc fails - RDMA/siw: Fix serialization issue in write_space() - RDMA/hfi1: Prevent memory leak in sdma_init - RDMA/iw_cxgb4: fix SRQ access from dump_qp() - RDMA/iwcm: Fix a lock inversion issue - HID: hyperv: Use in-place iterator API in the channel callback - kselftest: exclude failed TARGETS from runlist - selftests/kselftest/runner.sh: Add 45 second timeout per test - nfs: Fix nfsi->nrequests count error on nfs_inode_remove_request - arm64: cpufeature: Effectively expose FRINT capability to userspace - arm64: Fix incorrect irqflag restore for priority masking for compat - arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419 - tty: serial: owl: Fix the link time qualifier of 'owl_uart_exit()' - tty: serial: rda: Fix the link time qualifier of 'rda_uart_exit()' - serial/sifive: select SERIAL_EARLYCON - tty: n_hdlc: fix build on SPARC - misc: fastrpc: prevent memory leak in fastrpc_dma_buf_attach - RDMA/core: Fix an error handling path in 'res_get_common_doit()' - RDMA/cm: Fix memory leak in cm_add/remove_one - RDMA/nldev: Reshuffle the code to avoid need to rebind QP in error path - RDMA/mlx5: Do not allow rereg of a ODP MR - RDMA/mlx5: Order num_pending_prefetch properly with synchronize_srcu - RDMA/mlx5: Add missing synchronize_srcu() for MW cases - gpio: max77620: Use correct unit for debounce times - fs: cifs: mute -Wunused-const-variable message - arm64: vdso32: Fix broken compat vDSO build warnings - arm64: vdso32: Detect binutils support for dmb ishld - serial: mctrl_gpio: Check for NULL pointer - serial: 8250_omap: Fix gpio check for auto RTS/CTS - arm64: Default to building compat vDSO with clang when CONFIG_CC_IS_CLANG - arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionally - efi/cper: Fix endianness of PCIe class code - efi/x86: Do not clean dummy variable in kexec path - MIPS: include: Mark __cmpxchg as __always_inline - riscv: avoid kernel hangs when trapped in BUG() - riscv: avoid sending a SIGTRAP to a user thread trapped in WARN() - riscv: Correct the handling of unexpected ebreak in do_trap_break() - x86/xen: Return from panic notifier - ocfs2: clear zero in unaligned direct IO - fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry() - fs: ocfs2: fix a possible null-pointer dereference in ocfs2_write_end_nolock() - fs: ocfs2: fix a possible null-pointer dereference in ocfs2_info_scan_inode_alloc() - btrfs: silence maybe-uninitialized warning in clone_range - arm64: armv8_deprecated: Checking return value for memory allocation - sched/fair: Scale bandwidth quota and period without losing quota/period ratio precision - sched/vtime: Fix guest/system mis-accounting on task switch - perf/core: Rework memory accounting in perf_mmap() - perf/core: Fix corner case in perf_rotate_context() - perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp - drm/amdgpu: fix memory leak - iio: imu: adis16400: release allocated memory on failure - iio: imu: adis16400: fix memory leak - iio: imu: st_lsm6dsx: fix waitime for st_lsm6dsx i2c controller - MIPS: include: Mark __xchg as __always_inline - MIPS: fw: sni: Fix out of bounds init of o32 stack - s390/cio: fix virtio-ccw DMA without PV - virt: vbox: fix memory
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
So, um, is there a simple way to get this fix into the other affected
distributions or do I have to open an issue in each one?
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Disco:
Fix Released
Status in linux source package in Eoan:
Fix Released
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic
root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet
splash kaslr i915.alpha_support=1 vt.handoff=1
RelatedPackageVersions:
linux-restricted-modules-4.15.0-68-generic N/A
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
This bug was fixed in the package linux - 4.15.0-72.81
---
linux (4.15.0-72.81) bionic; urgency=medium
* bionic/linux: 4.15.0-72.81 -proposed tracker (LP: #1854027)
* [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX
(LP: #1853326)
- Revert "arm64: Use firmware to detect CPUs that are not affected by
Spectre-v2"
- Revert "arm64: Get rid of __smccc_workaround_1_hvc_*"
* [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX2 and
Kunpeng920 (LP: #1852723)
- SAUCE: arm64: capabilities: Move setup_boot_cpu_capabilities() call to
correct place
linux (4.15.0-71.80) bionic; urgency=medium
* bionic/linux: 4.15.0-71.80 -proposed tracker (LP: #1852289)
* Bionic update: upstream stable patchset 2019-10-29 (LP: #1850541)
- panic: ensure preemption is disabled during panic()
- f2fs: use EINVAL for superblock with invalid magic
- [Config] updateconfigs for USB_RIO500
- USB: rio500: Remove Rio 500 kernel driver
- USB: yurex: Don't retry on unexpected errors
- USB: yurex: fix NULL-derefs on disconnect
- USB: usb-skeleton: fix runtime PM after driver unbind
- USB: usb-skeleton: fix NULL-deref on disconnect
- xhci: Fix false warning message about wrong bounce buffer write length
- xhci: Prevent device initiated U1/U2 link pm if exit latency is too long
- xhci: Check all endpoints for LPM timeout
- usb: xhci: wait for CNR controller not ready bit in xhci resume
- USB: adutux: fix use-after-free on disconnect
- USB: adutux: fix NULL-derefs on disconnect
- USB: adutux: fix use-after-free on release
- USB: iowarrior: fix use-after-free on disconnect
- USB: iowarrior: fix use-after-free on release
- USB: iowarrior: fix use-after-free after driver unbind
- USB: usblp: fix runtime PM after driver unbind
- USB: chaoskey: fix use-after-free on release
- USB: ldusb: fix NULL-derefs on driver unbind
- serial: uartlite: fix exit path null pointer
- USB: serial: keyspan: fix NULL-derefs on open() and write()
- USB: serial: ftdi_sio: add device IDs for Sienna and Echelon PL-20
- USB: serial: option: add Telit FN980 compositions
- USB: serial: option: add support for Cinterion CLS8 devices
- USB: serial: fix runtime PM after driver unbind
- USB: usblcd: fix I/O after disconnect
- USB: microtek: fix info-leak at probe
- USB: dummy-hcd: fix power budget for SuperSpeed mode
- usb: renesas_usbhs: gadget: Do not discard queues in
usb_ep_set_{halt,wedge}()
- usb: renesas_usbhs: gadget: Fix usb_ep_set_{halt,wedge}() behavior
- USB: legousbtower: fix slab info leak at probe
- USB: legousbtower: fix deadlock on disconnect
- USB: legousbtower: fix potential NULL-deref on disconnect
- USB: legousbtower: fix open after failed reset request
- USB: legousbtower: fix use-after-free on release
- staging: vt6655: Fix memory leak in vt6655_probe
- iio: adc: ad799x: fix probe error handling
- iio: adc: axp288: Override TS pin bias current for some models
- iio: light: opt3001: fix mutex unlock race
- efivar/ssdt: Don't iterate over EFI vars if no SSDT override was specified
- perf llvm: Don't access out-of-scope array
- perf inject jit: Fix JIT_CODE_MOVE filename
- CIFS: Gracefully handle QueryInfo errors during open
- CIFS: Force revalidate inode when dentry is stale
- CIFS: Force reval dentry if LOOKUP_REVAL flag is set
- kernel/sysctl.c: do not override max_threads provided by userspace
- firmware: google: increment VPD key_len properly
- gpiolib: don't clear FLAG_IS_OUT when emulating open-drain/open-source
- Staging: fbtft: fix memory leak in fbtft_framebuffer_alloc
- iio: hx711: add delay until DOUT is ready
- iio: adc: hx711: fix bug in sampling of data
- btrfs: fix incorrect updating of log root tree
- NFS: Fix O_DIRECT accounting of number of bytes read/written
- MIPS: Disable Loongson MMI instructions for kernel build
- Fix the locking in dcache_readdir() and friends
- media: stkwebcam: fix runtime PM after driver unbind
- tracing/hwlat: Report total time spent in all NMIs during the sample
- tracing/hwlat: Don't ignore outer-loop duration when calculating
max_latency
- ftrace: Get a reference counter for the trace_array on filter files
- tracing: Get trace_array reference for available_tracers files
- x86/asm: Fix MWAITX C-state hint value
- iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
- cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic
- btrfs: fix uninitialized ret in ref-verify
- arm64/sve: Fix wrong free for task->thread.sve_state
- [Config] updateconfigs for USB_RIO500
* Bionic update: upstream stable patchset 2019-11-13 (LP: #1852492)
- zram: fix race between backing_dev_show and backing_dev_store
- dm snapshot: use
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
This bug was fixed in the package linux - 5.3.0-24.26 --- linux (5.3.0-24.26) eoan; urgency=medium * eoan/linux: 5.3.0-24.26 -proposed tracker (LP: #1852232) * Eoan update: 5.3.9 upstream stable release (LP: #1851550) - io_uring: fix up O_NONBLOCK handling for sockets - dm snapshot: introduce account_start_copy() and account_end_copy() - dm snapshot: rework COW throttling to fix deadlock - Btrfs: fix inode cache block reserve leak on failure to allocate data space - btrfs: qgroup: Always free PREALLOC META reserve in btrfs_delalloc_release_extents() - iio: adc: meson_saradc: Fix memory allocation order - iio: fix center temperature of bmc150-accel-core - libsubcmd: Make _FORTIFY_SOURCE defines dependent on the feature - perf tests: Avoid raising SEGV using an obvious NULL dereference - perf map: Fix overlapped map handling - perf script brstackinsn: Fix recovery from LBR/binary mismatch - perf jevents: Fix period for Intel fixed counters - perf tools: Propagate get_cpuid() error - perf annotate: Propagate perf_env__arch() error - perf annotate: Fix the signedness of failure returns - perf annotate: Propagate the symbol__annotate() error return - perf annotate: Fix arch specific ->init() failure errors - perf annotate: Return appropriate error code for allocation failures - perf annotate: Don't return -1 for error when doing BPF disassembly - staging: rtl8188eu: fix null dereference when kzalloc fails - RDMA/siw: Fix serialization issue in write_space() - RDMA/hfi1: Prevent memory leak in sdma_init - RDMA/iw_cxgb4: fix SRQ access from dump_qp() - RDMA/iwcm: Fix a lock inversion issue - HID: hyperv: Use in-place iterator API in the channel callback - kselftest: exclude failed TARGETS from runlist - selftests/kselftest/runner.sh: Add 45 second timeout per test - nfs: Fix nfsi->nrequests count error on nfs_inode_remove_request - arm64: cpufeature: Effectively expose FRINT capability to userspace - arm64: Fix incorrect irqflag restore for priority masking for compat - arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419 - tty: serial: owl: Fix the link time qualifier of 'owl_uart_exit()' - tty: serial: rda: Fix the link time qualifier of 'rda_uart_exit()' - serial/sifive: select SERIAL_EARLYCON - tty: n_hdlc: fix build on SPARC - misc: fastrpc: prevent memory leak in fastrpc_dma_buf_attach - RDMA/core: Fix an error handling path in 'res_get_common_doit()' - RDMA/cm: Fix memory leak in cm_add/remove_one - RDMA/nldev: Reshuffle the code to avoid need to rebind QP in error path - RDMA/mlx5: Do not allow rereg of a ODP MR - RDMA/mlx5: Order num_pending_prefetch properly with synchronize_srcu - RDMA/mlx5: Add missing synchronize_srcu() for MW cases - gpio: max77620: Use correct unit for debounce times - fs: cifs: mute -Wunused-const-variable message - arm64: vdso32: Fix broken compat vDSO build warnings - arm64: vdso32: Detect binutils support for dmb ishld - serial: mctrl_gpio: Check for NULL pointer - serial: 8250_omap: Fix gpio check for auto RTS/CTS - arm64: Default to building compat vDSO with clang when CONFIG_CC_IS_CLANG - arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionally - efi/cper: Fix endianness of PCIe class code - efi/x86: Do not clean dummy variable in kexec path - MIPS: include: Mark __cmpxchg as __always_inline - riscv: avoid kernel hangs when trapped in BUG() - riscv: avoid sending a SIGTRAP to a user thread trapped in WARN() - riscv: Correct the handling of unexpected ebreak in do_trap_break() - x86/xen: Return from panic notifier - ocfs2: clear zero in unaligned direct IO - fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry() - fs: ocfs2: fix a possible null-pointer dereference in ocfs2_write_end_nolock() - fs: ocfs2: fix a possible null-pointer dereference in ocfs2_info_scan_inode_alloc() - btrfs: silence maybe-uninitialized warning in clone_range - arm64: armv8_deprecated: Checking return value for memory allocation - sched/fair: Scale bandwidth quota and period without losing quota/period ratio precision - sched/vtime: Fix guest/system mis-accounting on task switch - perf/core: Rework memory accounting in perf_mmap() - perf/core: Fix corner case in perf_rotate_context() - perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp - drm/amdgpu: fix memory leak - iio: imu: adis16400: release allocated memory on failure - iio: imu: adis16400: fix memory leak - iio: imu: st_lsm6dsx: fix waitime for st_lsm6dsx i2c controller - MIPS: include: Mark __xchg as __always_inline - MIPS: fw: sni: Fix out of bounds init of o32 stack - s390/cio: fix virtio-ccw DMA without PV - virt: vbox: fix memory
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
This bug was fixed in the package linux - 5.0.0-37.40 --- linux (5.0.0-37.40) disco; urgency=medium * disco/linux: 5.0.0-37.40 -proposed tracker (LP: #1852253) * System hangs at early boot (LP: #1851216) - x86/timer: Skip PIT initialization on modern chipsets * drm/i915: Add support for another CMP-H PCH (LP: #1848491) - drm/i915/cml: Add second PCH ID for CMP * Some EFI systems fail to boot in efi_init() when booted via maas (LP: #1851810) - efi: efi_get_memory_map -- increase map headroom * seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test (LP: #1849281) - SAUCE: seccomp: avoid overflow in implicit constant conversion - SAUCE: seccomp: rework define for SECCOMP_USER_NOTIF_FLAG_CONTINUE - SAUCE: seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test * dkms artifacts may expire from the pool (LP: #1850958) - [Packaging] dkms -- try launchpad librarian for pool downloads - [Packaging] dkms -- dkms-build quieten wget verbiage * update ENA driver to version 2.1.0 (LP: #1850175) - net: ena: fix swapped parameters when calling ena_com_indirect_table_fill_entry - net: ena: fix: Free napi resources when ena_up() fails - net: ena: fix incorrect test of supported hash function - net: ena: fix return value of ena_com_config_llq_info() - net: ena: improve latency by disabling adaptive interrupt moderation by default - net: ena: fix ena_com_fill_hash_function() implementation - net: ena: add handling of llq max tx burst size - net: ena: ethtool: add extra properties retrieval via get_priv_flags - net: ena: replace free_tx/rx_ids union with single free_ids field in ena_ring - net: ena: arrange ena_probe() function variables in reverse christmas tree - net: ena: add newline at the end of pr_err prints - net: ena: documentation: update ena.txt - net: ena: allow automatic fallback to polling mode - net: ena: add support for changing max_header_size in LLQ mode - net: ena: optimise calculations for CQ doorbell - net: ena: add good checksum counter - net: ena: use dev_info_once instead of static variable - net: ena: add MAX_QUEUES_EXT get feature admin command - net: ena: enable negotiating larger Rx ring size - net: ena: make ethtool show correct current and max queue sizes - net: ena: allow queue allocation backoff when low on memory - net: ena: add ethtool function for changing io queue sizes - net: ena: remove inline keyword from functions in *.c - net: ena: update driver version from 2.0.3 to 2.1.0 - net: ena: Fix bug where ring allocation backoff stopped too late - Revert "net: ena: ethtool: add extra properties retrieval via get_priv_flags" - net: ena: don't wake up tx queue when down - net: ena: clean up indentation issue * Add Intel Comet Lake ethernet support (LP: #1848555) - SAUCE: e1000e: Add support for Comet Lake * Intel Wireless AC 3168 on Eoan complaints FW error in SYNC CMD GEO_TX_POWER_LIMIT (LP: #1846016) - iwlwifi: exclude GEO SAR support for 3168 * tsc marked unstable after entered PC10 on Intel CoffeeLake (LP: #1840239) - SAUCE: x86/intel: Disable HPET on Intel Coffe Lake platforms - SAUCE: x86/intel: Disable HPET on Intel Ice Lake platforms * cloudimg: no iavf/i40evf module so no network available with SR-IOV enabled cloud (LP: #1848481) - [Packaging] include iavf/i40evf in generic * High power consumption using 5.0.0-25-generic (LP: #1840835) - PCI: Add a helper to check Power Resource Requirements _PR3 existence - ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver - PCI: Fix missing inline for pci_pr3_present() * CML CPUIDs (LP: #1843794) - x86/cpu: Add Comet Lake to the Intel CPU models header * shiftfs: prevent exceeding project quotas (LP: #1849483) - SAUCE: shiftfs: drop CAP_SYS_RESOURCE from effective capabilities * shiftfs: fix fallocate() (LP: #1849482) - SAUCE: shiftfs: setup correct s_maxbytes limit * Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message (LP: #1850443) - Bluetooth: hidp: Fix assumptions on the return value of hidp_send_message * [SRU][B/OEM-B/OEM-OSP1/D/E] UBUNTU: SAUCE: add rtl623 codec support and fix mic issues (LP: #1850599) - SAUCE: ALSA: hda/realtek - Add support for ALC623 - SAUCE: ALSA: hda/realtek - Fix 2 front mics of codec 0x623 * NFSv4.1: Interrupted connections cause high bandwidth RPC ping-pong between client and server (LP: #1828978) - NFSv4.1: Avoid false retries when RPC calls are interrupted * SUNRPC: Use after free when GSSD credentials are invalid causes oops (LP: #1842037) - SUNRPC: Clean up - SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential * Suppress "hid_field_extract() called with n (192) > 32!" message floods (LP: #1850600) -
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
I can confirm that this bug is fixed in bionic:
# echo "x" > /proc/sysrq-trigger
Nov 14 20:38:58 panzersperre kernel: sysrq: SysRq :
Nov 14 20:38:58 panzersperre kernel: This sysrq operation is disabled from
userspace.
I don't have a disco or eoan to test.
** Tags removed: verification-needed-bionic
** Tags added: verification-done-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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
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
** 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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
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!
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
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-
eoan' to 'verification-done-eoan'. If the problem still exists, change
the tag 'verification-needed-eoan' to 'verification-failed-eoan'.
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-eoan
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
** Changed in: linux (Ubuntu Bionic)
Status: Triaged => Fix Committed
** Changed in: linux (Ubuntu Disco)
Status: Triaged => Fix Committed
** Changed in: linux (Ubuntu Eoan)
Status: Triaged => 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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic
root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet
splash kaslr i915.alpha_support=1
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
I'm no expert in either kernel or C programming and I didn't test this
patch, but it looks good to me.
Also, the resulting code is quite similar to the one Fedora is currently using
- they accidentally fixed this bug in
https://src.fedoraproject.org/rpms/kernel/c/5df4c5562f191b434edf57e8c92b176baad37cba.
(Debian also seems to be affected:
https://salsa.debian.org/kernel-team/linux/blob/4dcfa860/debian/patches/features/all/lockdown/0002-Add-a-SysRq-option-to-lift-kernel-lockdown.patch)
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Triaged
Status in linux source package in Disco:
Triaged
Status in linux source package in Eoan:
Triaged
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
** Description changed:
+ SRU Justification
+
+ Impact: The kernel lockdown support adds a sysrq to allow a physically
+ present user to disable lockdown from the keyboard. A bug in the
+ implementation makes it possible to also lift lockdown by writing to
+ /proc/sysrq-trigger.
+
+ Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
+ trigger.
+
+ Test Case: Write "x" to /proc/sysrq-trigger. When working properly there
+ should be no messages in dmesg about lifting lockdown, and lockdown
+ restrictions (e.g. loading unsigned modules) should remain in effect.
+
+ Regression Potential: Anyone using /proc/sysrq-trigger to disable
+ lockdown will no longer be able to do so. Implementation bugs could
+ prevent use of the sysrq from the keyboard from disabling lockdown, but
+ this has been confrimed to still work with the fix in place.
+
+ ---
+
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical access
to the system. It is automatically enabled when the system is booted
with UEFI Secure Boot, which is the case for me.
This should show the bug:
- # echo "x" > /proc/sysrq-trigger
- Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
+ # echo "x" > /proc/sysrq-trigger
+ Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-
the-kernel-lockdown/), so I'm not the first to notice this behavior
(even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
- 554 │ /* Ban synthetic events from some sysrq functionality */
- 555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
- 556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
- 557 │ printk("This sysrq operation is disabled from
userspace.\n");
- 558 │ /*
- 559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
- 560 │ * should not) and is the invoked operation enabled?
- 561 │ */
- 562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
- 563 │ pr_cont("%s\n", op_p->action_msg);
- 564 │ console_loglevel = orig_log_level;
- 565 │ op_p->handler(key);
- 566 │ } else {
- 567 │ pr_cont("This sysrq operation is disabled.\n");
- 568 │ }
+ 554 │ /* Ban synthetic events from some sysrq functionality */
+ 555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
+ 556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
+ 557 │ printk("This sysrq operation is disabled from
userspace.\n");
+ 558 │ /*
+ 559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
+ 560 │ * should not) and is the invoked operation enabled?
+ 561 │ */
+ 562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
+ 563 │ pr_cont("%s\n", op_p->action_msg);
+ 564 │ console_loglevel = orig_log_level;
+ 565 │ op_p->handler(key);
+ 566 │ } else {
+ 567 │ pr_cont("This sysrq operation is disabled.\n");
+ 568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
- USERPID ACCESS COMMAND
- /dev/snd/controlC1: niklas 2442 F pulseaudio
- /dev/snd/controlC0: niklas 2442 F pulseaudio
+ USERPID ACCESS COMMAND
+ /dev/snd/controlC1: niklas 2442 F pulseaudio
+ /dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
** Tags added: patch
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Triaged
Status in linux source package in Disco:
Triaged
Status in linux source package in Eoan:
Triaged
Status in linux source package in Focal:
In Progress
Bug description:
SRU Justification
Impact: The kernel lockdown support adds a sysrq to allow a physically
present user to disable lockdown from the keyboard. A bug in the
implementation makes it possible to also lift lockdown by writing to
/proc/sysrq-trigger.
Fix: Correct the logic to disallow disabling lockdown via /proc/sysrq-
trigger.
Test Case: Write "x" to /proc/sysrq-trigger. When working properly
there should be no messages in dmesg about lifting lockdown, and
lockdown restrictions (e.g. loading unsigned modules) should remain in
effect.
Regression Potential: Anyone using /proc/sysrq-trigger to disable
lockdown will no longer be able to do so. Implementation bugs could
prevent use of the sysrq from the keyboard from disabling lockdown,
but this has been confrimed to still work with the fix in place.
---
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic
root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet
splash kaslr i915.alpha_support=1 vt.handoff=1
RelatedPackageVersions:
linux-restricted-modules-4.15.0-68-generic N/A
linux-backports-modules-4.15.0-68-generic N/A
linux-firmware 1.173.11
SourcePackage: linux
UpgradeStatus:
[Kernel-packages] [Bug 1851380] Re: root can lift kernel lockdown
** Information type changed from Private Security to Public Security
--
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/1851380
Title:
root can lift kernel lockdown
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Invalid
Status in linux source package in Bionic:
Triaged
Status in linux source package in Disco:
Triaged
Status in linux source package in Eoan:
Triaged
Status in linux source package in Focal:
In Progress
Bug description:
Echoing "x" into /proc/sysrq-trigger disables kernel lockdown, even
though it shouldn't.
If I'm not mistaken, kernel lockdown is meant to create a barrier
between root and the kernel that can only be broken with physical
access to the system. It is automatically enabled when the system is
booted with UEFI Secure Boot, which is the case for me.
This should show the bug:
# echo "x" > /proc/sysrq-trigger
Nov 05 14:58:15 panzersperre kernel: sysrq: SysRq :
Nov 05 14:58:15 panzersperre kernel: This sysrq operation is disabled from
userspace.
Nov 05 14:58:15 panzersperre kernel: Disabling Secure Boot restrictions
Nov 05 14:58:15 panzersperre kernel: Lifting lockdown
Note that it first says that the operation is disabled and then performs this
operation.
This should only be possible by physically pressing sysrq+x on an attached
keyboard.
I'm doing this on 4.15.0-68-generic on Ubuntu 18.04.3 LTS.
I have kernel.sysrq set to 1 - this is important to be able to trigger this
bug. (But I don't think it disqualifies this issue as non-security relevant
because root can trivially execute `sysctl kernel.sysrq=1`.)
I first learned about this by reading a blog post
(https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-
lifting-the-kernel-lockdown/), so I'm not the first to notice this
behavior (even though this post doesn't say it's a bug).
Looking through drivers/tty/sysrq.c, I guess the problem is caused by
this if condition in __handle_sysrq:
554 │ /* Ban synthetic events from some sysrq functionality */
555 │ if ((from == SYSRQ_FROM_PROC || from ==
SYSRQ_FROM_SYNTHETIC) &&
556 │ op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
557 │ printk("This sysrq operation is disabled from
userspace.\n");
558 │ /*
559 │ * Should we check for enabled operations
(/proc/sysrq-trigger
560 │ * should not) and is the invoked operation enabled?
561 │ */
562 │ if (from == SYSRQ_FROM_KERNEL ||
sysrq_on_mask(op_p->enable_mask)) {
563 │ pr_cont("%s\n", op_p->action_msg);
564 │ console_loglevel = orig_log_level;
565 │ op_p->handler(key);
566 │ } else {
567 │ pr_cont("This sysrq operation is disabled.\n");
568 │ }
Note that `op_p->enable_mask & SYSRQ_DISABLE_USERSPACE` just causes a
printk and no change of behavior.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-68-generic 4.15.0-68.77
ProcVersionSignature: Ubuntu 4.15.0-68.77-generic 4.15.18
Uname: Linux 4.15.0-68-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.8
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC1: niklas 2442 F pulseaudio
/dev/snd/controlC0: niklas 2442 F pulseaudio
CurrentDesktop: KDE
Date: Tue Nov 5 14:58:33 2019
InstallationDate: Installed on 2015-12-11 (1424 days ago)
InstallationMedia: Kubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
MachineType: LENOVO 20E8S00600
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-68-generic
root=UUID=67485aa6-c665-4c53-bf41-328307d0cbf0 ro rootflags=subvol=@ quiet
splash kaslr i915.alpha_support=1 vt.handoff=1
RelatedPackageVersions:
linux-restricted-modules-4.15.0-68-generic N/A
linux-backports-modules-4.15.0-68-generic N/A
linux-firmware 1.173.11
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2018-07-05 (487 days ago)
dmi.bios.date: 09/26/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: JHET69WW (1.69 )
dmi.board.asset.tag: Not Available
dmi.board.name: Intel powered classmate PC
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrJHET69WW(1.69):bd09/26/2018:svnLENOVO:pn20E8S00600:pvrThinkPad11e:rvnLENOVO:rnIntelpoweredclassmatePC:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad 11e
dmi.product.name: 20E8S00600
dmi.product.version: ThinkPad 11e
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
