[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2024-02-29 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux-mtk/5.15.0-1030.34
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-jammy-linux-mtk' to 'verification-done-jammy-
linux-mtk'. If the problem still exists, change the tag 'verification-
needed-jammy-linux-mtk' to 'verification-failed-jammy-linux-mtk'.


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: kernel-spammed-jammy-linux-mtk-v2 
verification-needed-jammy-linux-mtk

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2024-01-12 Thread Anthony Wong
** Tags added: fixed-linux-oem-6.5

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/

  The fix is to change Landlock from LSMBLOB_NEEDED to
  

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-06-28 Thread Launchpad Bug Tracker
This bug was fixed in the package linux-oem-6.1 - 6.1.0-1015.15

---
linux-oem-6.1 (6.1.0-1015.15) jammy; urgency=medium

  * jammy/linux-oem-6.1: 6.1.0-1015.15 -proposed tracker (LP: #2024152)

  * Packaging resync (LP: #1786013)
- [Packaging] resync git-ubuntu-log
- [Packaging] resync getabis

  * CVE-2023-2430
- io_uring: get rid of double locking
- io_uring: extract a io_msg_install_complete helper
- io_uring/msg_ring: move double lock/unlock helpers higher up
- io_uring/msg_ring: fix missing lock on overflow for IOPOLL

  * LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot (LP: #1987998)
- SAUCE: LSM: Change Landlock from LSMBLOB_NEEDED to LSMBLOB_NOT_NEEDED

  * Some INVLPG implementations can leave Global translations unflushed when
PCIDs are enabled (LP: #2023220)
- x86/mm: Avoid incomplete Global INVLPG flushes

  * cls_flower: off-by-one in fl_set_geneve_opt (LP: #2023577)
- net/sched: flower: fix possible OOB write in fl_set_geneve_opt()

  * CVE-2023-2176
- RDMA/core: Refactor rdma_bind_addr

  * ALSA: hda/realtek: Enable headset onLenovo M70/M90 (LP: #2021449)
- ALSA: hda/realtek: Enable headset onLenovo M70/M90

  * Add microphone support of the front headphone port on P3 Tower
(LP: #2023650)
- ALSA: hda/realtek: Add Lenovo P3 Tower platform

  * Add support of Smart Amplifier IC ALC1319D  on Intel platforms
(LP: #2023201)
- ASoC: Intel: soc-acpi: add table for RPL Dell SKU 0BDA

  * Fix speaker volume too low on HP G10 laptops (LP: #2023197)
- ALSA: hda/realtek: Enable 4 amplifiers instead of 2 on a HP platform

  * System hang at reading amdgpu sysfs attribute psp_vbflash (LP: #2023307)
- SAUCE: drm/amd: Make sure image is written to trigger VBIOS image update
  flow

  * System either hang with black screen or rebooted on entering suspend on AMD
Ryzen 9 PRO 7940HS w/ Radeon 780M Graphics (LP: #2020685)
- drm/amdgpu: refine get gpu clock counter method
- drm/amdgpu/gfx11: update gpu_clock_counter logic

  * Fix Monitor lost after replug WD19TBS to SUT port with VGA/DVI to type-C
dongle (LP: #2021949)
- thunderbolt: Increase timeout of DP OUT adapter handshake
- thunderbolt: Do not touch CL state configuration during discovery
- thunderbolt: Increase DisplayPort Connection Manager handshake timeout

  * Fix Disable thunderbolt clx make edp-monitor garbage while moving the
touchpad (LP: #2023004)
- drm/i915: Explain the magic numbers for AUX SYNC/precharge length
- drm/i915: Use 18 fast wake AUX sync len

  * Include the MAC address pass through function on RTL8153DD-CG (LP: #2020295)
- r8152: add USB device driver for config selection

  * FM350(mtk_t7xx) failed to suspend, or early wake while suspending
(LP: #2020743)
- net: wwan: t7xx: Ensure init is completed before system sleep

 -- Timo Aaltonen   Fri, 16 Jun 2023
11:51:13 +0300

** Changed in: linux-oem-6.1 (Ubuntu Jammy)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-2176

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-2430

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-06-19 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux-oem-6.1/6.1.0-1015.15
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-jammy' to 'verification-done-jammy'. If the
problem still exists, change the tag 'verification-needed-jammy' to
'verification-failed-jammy'.

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: kernel-spammed-jammy-linux-oem-6.1

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-06-16 Thread Timo Aaltonen
** Changed in: linux-oem-6.1 (Ubuntu Jammy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/

  The fix is to 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-06-13 Thread Thadeu Lima de Souza Cascardo
** Also affects: linux-oem-6.1 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-oem-6.1 (Ubuntu Kinetic)
   Status: New => Invalid

** Changed in: linux-oem-6.1 (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux-oem-6.1 (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux-oem-6.1 (Ubuntu Jammy)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

** Changed in: linux-oem-6.1 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux-oem-6.1 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux-oem-6.1 source package in Jammy:
  In Progress
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid
Status in linux-oem-6.1 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-03-01 Thread Launchpad Bug Tracker
This bug was fixed in the package linux-oem-6.0 - 6.0.0-1012.12

---
linux-oem-6.0 (6.0.0-1012.12) jammy; urgency=medium

  * jammy/linux-oem-6.0: 6.0.0-1012.12 -proposed tracker (LP: #2004348)

  * CVE-2023-0469
- io_uring/filetable: fix file reference underflow

  * LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot (LP: #1987998)
- SAUCE: LSM: Change Landlock from LSMBLOB_NEEDED to LSMBLOB_NOT_NEEDED

  * CVE-2023-0045
- x86/bugs: Flush IBP in ib_prctl_set()

  * CVE-2022-47520
- wifi: wilc1000: validate pairwise and authentication suite offsets

  * CVE-2022-3567
- ipv6: Fix data races around sk->sk_prot.

  * CVE-2022-45934
- Bluetooth: L2CAP: Fix u8 overflow

  * CVE-2022-42896
- Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm

  * CVE-2022-43945
- NFSD: Remove "inline" directives on op_rsize_bop helpers
- NFSD: Cap rsize_bop result based on send buffer size

  * CVE-2022-20369
- NFSD: fix use-after-free in __nfs42_ssc_open()

  * CVE-2023-0461
- net/ulp: prevent ULP without clone op from entering the LISTEN status
- net/ulp: use consistent error code when blocking ULP

  * Expose built-in trusted and revoked certificates (LP: #1996892)
- [Packaging] Expose built-in trusted and revoked certificates

 -- Timo Aaltonen   Fri, 10 Feb 2023
12:37:27 +0200

** Changed in: linux-oem-6.0 (Ubuntu Jammy)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-20369

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-3567

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-42896

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-43945

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-45934

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-47520

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-0045

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-0461

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-0469

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-02-14 Thread Timo Aaltonen
** Changed in: linux-oem-6.0 (Ubuntu Jammy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/

  The fix is to change Landlock from LSMBLOB_NEEDED to
  LSMBLOB_NOT_NEEDED.

  Due to the "LSM: Module stacking for AppArmor" patchset being 25
  patches long, it was impractical to revert just the 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-02-13 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux-oem-6.0/6.0.0-1012.12
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-jammy' to 'verification-done-jammy'. If the
problem still exists, change the tag 'verification-needed-jammy' to
'verification-failed-jammy'.

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: kernel-spammed-jammy-linux-oem-6.0

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  In Progress
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2023-02-09 Thread Thadeu Lima de Souza Cascardo
** Also affects: linux-oem-6.0 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-oem-6.0 (Ubuntu Kinetic)
   Status: New => Invalid

** Changed in: linux-oem-6.0 (Ubuntu)
   Status: New => Invalid

** Changed in: linux-oem-6.0 (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux-oem-6.0 (Ubuntu Jammy)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

** Changed in: linux-oem-6.0 (Ubuntu Jammy)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-6.0 package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released
Status in linux-oem-6.0 source package in Jammy:
  In Progress
Status in linux source package in Kinetic:
  Fix Released
Status in linux-oem-6.0 source package in Kinetic:
  Invalid

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-12-12 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux-nvidia/5.15.0-1011.11
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-jammy' to 'verification-done-jammy'. If the
problem still exists, change the tag 'verification-needed-jammy' to
'verification-failed-jammy'.

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: kernel-spammed-jammy-linux-nvidia

-- 
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/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-12-07 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux-
bluefield/5.15.0-1010.12 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-jammy' to 'verification-
done-jammy'. If the problem still exists, change the tag 'verification-
needed-jammy' to 'verification-failed-jammy'.

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 removed: verification-done-jammy
** Tags added: kernel-spammed-jammy-linux-bluefield verification-needed-jammy

-- 
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/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Jammy:
  Fix Released
Status in linux source package in Kinetic:
  Fix Released

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-11-15 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.15.0-53.59

---
linux (5.15.0-53.59) jammy; urgency=medium

  * Fix blank screen on Thinkpad ADL 4K+ panel (LP: #1980621)
- drm/i915: Implement WaEdpLinkRateDataReload

  * Kernel regresses openjdk on riscv64 (LP: #1992484)
- SAUCE: Revert "riscv: mmap with PROT_WRITE but no PROT_READ is invalid"

  * iavf: SR-IOV VFs error with no traffic flow when MTU greater than 1500
(LP: #1983656)
- iavf: Fix set max MTU size with port VLAN and jumbo frames
- i40e: Fix VF set max MTU size

  * [Ubuntu 22.04] mpt3sas: Request to include latest bug fix patches
(LP: #1965927)
- scsi: mpt3sas: Remove scsi_dma_map() error messages
- scsi: mpt3sas: Update persistent trigger pages from sysfs interface

  * ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel
systems (LP: #1990985)
- ACPI: processor idle: Practically limit "Dummy wait" workaround to old 
Intel
  systems

  * Fix resume on AMD platforms when TBT monitor is plugged (LP: #1990920)
- SAUCE: Revert "drm/amd/display: Add helper for blanking all dp displays"
- drm/amd/display: Detect dpcd_rev when hotplug mst monitor
- drm/amd/display: Release remote dc_sink under mst scenario

  * LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot (LP: #1987998)
- SAUCE: LSM: Change Landlock from LSMBLOB_NEEDED to LSMBLOB_NOT_NEEDED

  * To support Intel Maple Ridge Thunderbolt [8086:1134] (LP: #1990240)
- thunderbolt: Add support for Intel Maple Ridge single port controller

  * Intel graphic driver is not probing[8086:468b] (LP: #1990242)
- drm/i915/adl_s: Update ADL-S PCI IDs
- drm/i915: Add new ADL-S pci id

  * Add HDMI codec ID for Intel Raptor Lake (LP: #1989578)
- ALSA: hda: Add PCI and HDMI IDs for Intel Raptor Lake

  * Jammy update: v5.15.64 upstream stable release (LP: #1991717)
- wifi: rtlwifi: remove always-true condition pointed out by GCC 12
- eth: sun: cassini: remove dead code
- audit: fix potential double free on error path from 
fsnotify_add_inode_mark
- cgroup: Fix race condition at rebind_subsystems()
- parisc: Make CONFIG_64BIT available for ARCH=parisc64 only
- parisc: Fix exception handler for fldw and fstw instructions
- kernel/sys_ni: add compat entry for fadvise64_64
- x86/entry: Move CLD to the start of the idtentry macro
- block: add a bdev_max_zone_append_sectors helper
- block: add bdev_max_segments() helper
- btrfs: zoned: revive max_zone_append_bytes
- btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size
- btrfs: convert count_max_extents() to use fs_info->max_extent_size
- Input: i8042 - move __initconst to fix code styling warning
- Input: i8042 - merge quirk tables
- Input: i8042 - add TUXEDO devices to i8042 quirk tables
- Input: i8042 - add additional TUXEDO devices to i8042 quirk tables
- drivers/base: fix userspace break from using bin_attributes for cpumap and
  cpulist
- scsi: qla2xxx: Fix response queue handler reading stale packets
- scsi: qla2xxx: edif: Fix dropped IKE message
- btrfs: put initial index value of a directory in a constant
- btrfs: pass the dentry to btrfs_log_new_name() instead of the inode
- btrfs: remove unnecessary parameter delalloc_start for 
writepage_delalloc()
- riscv: lib: uaccess: fold fixups into body
- riscv: lib: uaccess: fix CSR_STATUS SR_SUM bit
- xfrm: fix refcount leak in __xfrm_policy_check()
- xfrm: clone missing x->lastused in xfrm_do_migrate
- xfrm: policy: fix metadata dst->dev xmit null pointer dereference
- fs: require CAP_SYS_ADMIN in target namespace for idmapped mounts
- net: use eth_hw_addr_set() instead of ether_addr_copy()
- Revert "net: macsec: update SCI upon MAC address change."
- NFS: Don't allocate nfs_fattr on the stack in __nfs42_ssc_open()
- NFSv4.2 fix problems with __nfs42_ssc_open
- SUNRPC: RPC level errors should set task->tk_rpc_status
- mm/smaps: don't access young/dirty bit if pte unpresent
- ntfs: fix acl handling
- rose: check NULL rose_loopback_neigh->loopback
- r8152: fix the units of some registers for RTL8156A
- r8152: fix the RX FIFO settings when suspending
- nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout
- ice: xsk: Force rings to be sized to power of 2
- ice: xsk: prohibit usage of non-balanced queue id
- net/mlx5e: Properly disable vlan strip on non-UL reps
- net/mlx5: Avoid false positive lockdep warning by adding lock_class_key
- net/mlx5e: Fix wrong application of the LRO state
- net/mlx5e: Fix wrong tc flag used when set hw-tc-offload off
- net: ipa: don't assume SMEM is page-aligned
- net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume()
- net: moxa: get rid of asymmetry in DMA mapping/unmapping
- bonding: 802.3ad: fix no transmission of LACPDUs
- net: 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-10-26 Thread Matthew Ruffell
Performing verification for Kinetic.

I installed the 5.19.0-23-generic kernel from -updates, and edited
/etc/default/grub to set GRUB_CMDLINE_LINUX_DEFAULT to
"lsm=landlock,bpf,apparmor", updated grub, and rebooted.

The system came up as expected and all LSM modules loaded.

[0.264264] LSM: Security Framework initializing
[0.265198] landlock: Up and running.
[0.266816] LSM support for eBPF active
[0.267630] AppArmor: AppArmor initialized

Marking Kinetic as verified.

** Tags added: verification-done-kinetic

** Changed in: linux (Ubuntu Kinetic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Released

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-10-26 Thread Matthew Ruffell
Performing verification for Jammy

I started a fresh Jammy VM, running 5.15.0-52-generic from -updates.

I edited /etc/default/grub and set GRUB_CMDLINE_LINUX_DEFAULT to
"lsm=landlock,bpf,apparmor", updated grub, and rebooted.

The system panicked with the usual splat:

[0.355151] LSM: Security Framework initializing
[0.356309] landlock: Up and running.
[0.357186] LSM support for eBPF active
[0.358143] Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered.
[0.359849] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-52-generic 
#58-Ubuntu
[0.360292] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.15.0-1 04/01/2014
[0.360292] Call Trace:
[0.360292]  
[0.360292]  show_stack+0x52/0x5c
[0.360292]  dump_stack_lvl+0x4a/0x63
[0.360292]  dump_stack+0x10/0x16
[0.360292]  panic+0x149/0x321
[0.360292]  security_add_hooks+0x45/0x13a
[0.360292]  apparmor_init+0x189/0x1ef
[0.360292]  initialize_lsm+0x54/0x74
[0.360292]  ordered_lsm_init+0x379/0x392
[0.360292]  security_init+0x40/0x49
[0.360292]  start_kernel+0x454/0x4ca
[0.360292]  x86_64_start_reservations+0x24/0x2a
[0.360292]  x86_64_start_kernel+0xfb/0x106
[0.360292]  secondary_startup_64_no_verify+0xc2/0xcb
[0.360292]  
[0.360292] ---[ end Kernel panic - not syncing: security_add_hooks Too many 
LSMs registered. ]---

I then rebooted, enabled -proposed, and installed 5.15.0-53-generic, and
rebooted again.

The system came up fine, with all the LSMs enabled:

[0.312038] LSM: Security Framework initializing
[0.313217] landlock: Up and running.
[0.314065] LSM support for eBPF active
[0.314999] AppArmor: AppArmor initialized

The 5.15.0-53-generic kernel in -proposed fixes the issue, happy to mark
verified for Jammy.

** Tags added: verification-done-jammy

-- 
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/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-10-25 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the linux/5.15.0-53.59 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-jammy' to 'verification-done-jammy'. If the problem
still exists, change the tag 'verification-needed-jammy' to
'verification-failed-jammy'.

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/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-10-05 Thread Stefan Bader
** Changed in: linux (Ubuntu Jammy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/

  The fix is to change Landlock from LSMBLOB_NEEDED to
  LSMBLOB_NOT_NEEDED.

  Due to the "LSM: Module stacking for AppArmor" patchset being 25
  patches long, it was impractical to revert just the below patch and
  reapply with the fix, due to a large amount of conflicts:

  commit f17b27a2790e72198d2aaf45242453e5a9043049
  Author: Casey Schaufler 
  Date:   Mon Aug 17 16:02:56 2020 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-09-27 Thread Matthew Ruffell
** Changed in: linux (Ubuntu Kinetic)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1987998

Title:
  LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Jammy:
  In Progress
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1987998

  [Impact]

  The Ubuntu kernel carries an out of tree patchet, known as "LSM:
  Module stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one,
  from 2020, and has some slight divergences from the latest revision in
  development.

  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.

  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have
  been LSMBLOB_NOT_NEEDED.

  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.

  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an
  entry in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by
  one to fit the entry into the secid array:

  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))

  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };

  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.

  If you try and configure three LSMs like so and reboot:

  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"

  You will receive the following panic:

  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---

  There is a check added in security_add_hooks() that makes sure that
  you cannot configure too many LSMs:

  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }

  A workaround is to enable no more than 2 LSMs until this is fixed.

  [Fix]

  If you read the following mailing list thread on linux-security-
  modules from May 2021:

  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/

  It is explained that Landlock does not provide any of the hooks that
  use a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.

  I verified this with:

  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/

  The fix is to change Landlock from LSMBLOB_NEEDED to
  LSMBLOB_NOT_NEEDED.

  Due to the "LSM: Module stacking for AppArmor" patchset being 25
  patches long, it was impractical to revert just the below patch and
  reapply with the fix, due to a large amount of conflicts:

  commit f17b27a2790e72198d2aaf45242453e5a9043049
  Author: Casey Schaufler 
  Date:   Mon Aug 17 16:02:56 2020 

[Kernel-packages] [Bug 1987998] Re: LSM: Configuring Too Many LSMs Causes Kernel Panic on Boot

2022-09-27 Thread Matthew Ruffell
** Description changed:

  BugLink: https://bugs.launchpad.net/bugs/1987998
  
  [Impact]
  
  The Ubuntu kernel carries an out of tree patchet, known as "LSM: Module
  stacking for AppArmor" upstream, to enable stackable LSMs for
  containers. The revision the Ubuntu kernel carries is an older one, from
  2020, and has some slight divergences from the latest revision in
  development.
  
  One such divergence, is support for Landlock as a stackable LSM. When
  the stackable LSM patchset was applied, Landlock was still in
  development and not mainlined yet, and wasn't present in the earlier
  revision of the "LSM: Module stacking for AppArmor" patchset. Support
  for this was added by us.
  
  There was a minor omission made during enabling support for Landlock.
  The LSM slot type was marked as LSMBLOB_NEEDED, when it should have been
  LSMBLOB_NOT_NEEDED.
  
  Landlock itself does not provide any of the hooks that use a struct
  lsmblob, such as secid_to_secctx, secctx_to_secid, inode_getsecid,
  cred_getsecid, kernel_act_as task_getsecid_subj task_getsecid_obj and
  ipc_getsecid.
  
  When we set .slot = LSMBLOB_NEEDED, this indicates that we need an entry
  in struct lsmblob, and we need to increment LSMBLOB_ENTRIES by one to
  fit the entry into the secid array:
  
  #define LSMBLOB_ENTRIES ( \
     (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
     (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0))
  
  struct lsmblob {
     u32 secid[LSMBLOB_ENTRIES];
  };
  
  Currently, we don't increment LSMBLOB_ENTRIES by one to make an entry
  for Landlock, so for the Ubuntu kernel, we can fit a maximum of two
  entries, one for Apparmor and one for bpf.
  
  If you try and configure three LSMs like so and reboot:
  
  GRUB_CMDLINE_LINUX_DEFAULT="lsm=landlock,bpf,apparmor"
  
  You will receive the following panic:
  
  LSM: Security Framework initializing
  landlock: Up and running.
  LSM support for eBPF active
  Kernel panic - not syncing: security_add_hooks Too many LSMs registered.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-46-generic #49-Ubuntu
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   
   show_stack+0x52/0x5c
   dump_stack_lvl+0x4a/0x63
   dump_stack+0x10/0x16
   panic+0x149/0x321
   security_add_hooks+0x45/0x13a
   apparmor_init+0x189/0x1ef
   initialize_lsm+0x54/0x74
   ordered_lsm_init+0x379/0x392
   security_init+0x40/0x49
   start_kernel+0x466/0x4dc
   x86_64_start_reservations+0x24/0x2a
   x86_64_start_kernel+0xe4/0xef
   secondary_startup_64_no_verify+0xc2/0xcb
   
  ---[ end Kernel panic - not syncing: security_add_hooks Too many LSMs 
registered. ]---
  
  There is a check added in security_add_hooks() that makes sure that you
  cannot configure too many LSMs:
  
  if (lsmid->slot == LSMBLOB_NEEDED) {
   if (lsm_slot >= LSMBLOB_ENTRIES)
    panic("%s Too many LSMs registered.\n", __func__);
   lsmid->slot = lsm_slot++;
   init_debug("%s assigned lsmblob slot %d\n", lsmid->lsm,
   lsmid->slot);
  }
  
  A workaround is to enable no more than 2 LSMs until this is fixed.
  
  [Fix]
  
  If you read the following mailing list thread on linux-security-modules
  from May 2021:
  
  https://lore.kernel.org/selinux/202105141224.942DE93@keescook/T/
  
  It is explained that Landlock does not provide any of the hooks that use
  a struct lsmblob, such as secid_to_secctx, secctx_to_secid,
  inode_getsecid, cred_getsecid, kernel_act_as task_getsecid_subj
  task_getsecid_obj and ipc_getsecid.
  
  I verified this with:
  
  ubuntu-jammy$ grep -Rin "secid_to_secctx" security/landlock/
  ubuntu-jammy$ grep -Rin "secctx_to_secid" security/landlock/
  ubuntu-jammy$ grep -Rin "inode_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "cred_getsecid" security/landlock/
  ubuntu-jammy$ grep -Rin "kernel_act_as" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_subj" security/landlock/
  ubuntu-jammy$ grep -Rin "task_getsecid_obj" security/landlock/
  ubuntu-jammy$ grep -Rin "ipc_getsecid" security/landlock/
  
  The fix is to change Landlock from LSMBLOB_NEEDED to LSMBLOB_NOT_NEEDED.
  
  Due to the "LSM: Module stacking for AppArmor" patchset being 25 patches
  long, it was impractical to revert just the below patch and reapply with
  the fix, due to a large amount of conflicts:
  
  commit f17b27a2790e72198d2aaf45242453e5a9043049
  Author: Casey Schaufler 
  Date:   Mon Aug 17 16:02:56 2020 -0700
  Subject: UBUNTU: SAUCE: LSM: Create and manage the lsmblob data structure.
  Link: 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?id=f17b27a2790e72198d2aaf45242453e5a9043049
  
  So instead, I wrote up a fix that just changes the Landlock LSM slots to
  follow the latest upstream development, from V37 of the patchset: