From a1fe76173b9acfd0592c43bbfdb8af2996fcebc5 Mon Sep 17 00:00:00 2001 From: "Justin M. Forbes" Date: Wed, 18 Mar 2020 09:02:02 -0500 Subject: Linux v5.5.10 --- ...-clarify-and-fix-platform-device-DMA-mask.patch | 136 ----------------- iommu-WARN_TAINT-fixes.patch | 164 --------------------- kernel.spec | 15 +- sources | 3 +- v2_20200128_dmoulding_me_com.patch | 51 ------- 5 files changed, 5 insertions(+), 364 deletions(-) delete mode 100644 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch delete mode 100644 iommu-WARN_TAINT-fixes.patch delete mode 100644 v2_20200128_dmoulding_me_com.patch diff --git a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch b/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch deleted file mode 100644 index 873509eb0..000000000 --- a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch +++ /dev/null @@ -1,136 +0,0 @@ -From e3a36eb6dfaeea8175c05d5915dcf0b939be6dab Mon Sep 17 00:00:00 2001 -From: Christoph Hellwig -Date: Wed, 11 Mar 2020 17:07:10 +0100 -Subject: [PATCH] driver code: clarify and fix platform device DMA mask - allocation - -This does three inter-related things to clarify the usage of the -platform device dma_mask field. In the process, fix the bug introduced -by cdfee5623290 ("driver core: initialize a default DMA mask for -platform device") that caused Artem Tashkinov's laptop to not boot with -newer Fedora kernels. - -This does: - - - First off, rename the field to "platform_dma_mask" to make it - greppable. - - We have way too many different random fields called "dma_mask" in - various data structures, where some of them are actual masks, and - some of them are just pointers to the mask. And the structures all - have pointers to each other, or embed each other inside themselves, - and "pdev" sometimes means "platform device" and sometimes it means - "PCI device". - - So to make it clear in the code when you actually use this new field, - give it a unique name (it really should be something even more unique - like "platform_device_dma_mask", since it's per platform device, not - per platform, but that gets old really fast, and this is unique - enough in context). - - To further clarify when the field gets used, initialize it when we - actually start using it with the default value. - - - Then, use this field instead of the random one-off allocation in - platform_device_register_full() that is now unnecessary since we now - already have a perfectly fine allocation for it in the platform - device structure. - - - The above then allows us to fix the actual bug, where the error path - of platform_device_register_full() would unconditionally free the - platform device DMA allocation with 'kfree()'. - - That kfree() was dont regardless of whether the allocation had been - done earlier with the (now removed) kmalloc, or whether - setup_pdev_dma_masks() had already been used and the dma_mask pointer - pointed to the mask that was part of the platform device. - -It seems most people never triggered the error path, or only triggered -it from a call chain that set an explicit pdevinfo->dma_mask value (and -thus caused the unnecessary allocation that was "cleaned up" in the -error path) before calling platform_device_register_full(). - -Robin Murphy points out that in Artem's case the wdat_wdt driver failed -in platform_device_add(), and that was the one that had called -platform_device_register_full() with pdevinfo.dma_mask = 0, and would -have caused that kfree() of pdev.dma_mask corrupting the heap. - -A later unrelated kmalloc() then oopsed due to the heap corruption. - -Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device") -Reported-bisected-and-tested-by: Artem S. Tashkinov -Reviewed-by: Robin Murphy -Cc: Greg Kroah-Hartman -Signed-off-by: Christoph Hellwig -Signed-off-by: Linus Torvalds ---- - drivers/base/platform.c | 25 ++++++------------------- - include/linux/platform_device.h | 2 +- - 2 files changed, 7 insertions(+), 20 deletions(-) - -diff --git a/drivers/base/platform.c b/drivers/base/platform.c -index 7fa654f1288b..b5ce7b085795 100644 ---- a/drivers/base/platform.c -+++ b/drivers/base/platform.c -@@ -363,10 +363,10 @@ static void setup_pdev_dma_masks(struct platform_device *pdev) - { - if (!pdev->dev.coherent_dma_mask) - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); -- if (!pdev->dma_mask) -- pdev->dma_mask = DMA_BIT_MASK(32); -- if (!pdev->dev.dma_mask) -- pdev->dev.dma_mask = &pdev->dma_mask; -+ if (!pdev->dev.dma_mask) { -+ pdev->platform_dma_mask = DMA_BIT_MASK(32); -+ pdev->dev.dma_mask = &pdev->platform_dma_mask; -+ } - }; - - /** -@@ -662,20 +662,8 @@ struct platform_device *platform_device_register_full( - pdev->dev.of_node_reused = pdevinfo->of_node_reused; - - if (pdevinfo->dma_mask) { -- /* -- * This memory isn't freed when the device is put, -- * I don't have a nice idea for that though. Conceptually -- * dma_mask in struct device should not be a pointer. -- * See http://thread.gmane.org/gmane.linux.kernel.pci/9081 -- */ -- pdev->dev.dma_mask = -- kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); -- if (!pdev->dev.dma_mask) -- goto err; -- -- kmemleak_ignore(pdev->dev.dma_mask); -- -- *pdev->dev.dma_mask = pdevinfo->dma_mask; -+ pdev->platform_dma_mask = pdevinfo->dma_mask; -+ pdev->dev.dma_mask = &pdev->platform_dma_mask; - pdev->dev.coherent_dma_mask = pdevinfo->dma_mask; - } - -@@ -700,7 +688,6 @@ struct platform_device *platform_device_register_full( - if (ret) { - err: - ACPI_COMPANION_SET(&pdev->dev, NULL); -- kfree(pdev->dev.dma_mask); - platform_device_put(pdev); - return ERR_PTR(ret); - } -diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h -index 276a03c24691..041bfa412aa0 100644 ---- a/include/linux/platform_device.h -+++ b/include/linux/platform_device.h -@@ -24,7 +24,7 @@ struct platform_device { - int id; - bool id_auto; - struct device dev; -- u64 dma_mask; -+ u64 platform_dma_mask; - u32 num_resources; - struct resource *resource; - --- -2.25.1 - diff --git a/iommu-WARN_TAINT-fixes.patch b/iommu-WARN_TAINT-fixes.patch deleted file mode 100644 index 34668f9ad..000000000 --- a/iommu-WARN_TAINT-fixes.patch +++ /dev/null @@ -1,164 +0,0 @@ -From 2f2265a8cbc6b43deb169c525204ea7df02e9363 Mon Sep 17 00:00:00 2001 -From: Hans de Goede -Date: Mon, 9 Mar 2020 13:55:02 +0100 -Subject: [PATCH 1/2] iommu/vt-d: dmar: replace WARN_TAINT with pr_warn + - add_taint - -Quoting from the comment describing the WARN functions in -include/asm-generic/bug.h: - - * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report - * significant kernel issues that need prompt attention if they should ever - * appear at runtime. - * - * Do not use these macros when checking for invalid external inputs - -The (buggy) firmware tables which the dmar code was calling WARN_TAINT -for really are invalid external inputs. They are not under the kernel's -control and the issues in them cannot be fixed by a kernel update. -So logging a backtrace, which invites bug reports to be filed about this, -is not helpful. - -Some distros, e.g. Fedora, have tools watching for the kernel backtraces -logged by the WARN macros and offer the user an option to file a bug for -this when these are encountered. The WARN_TAINT in warn_invalid_dmar() -+ another iommu WARN_TAINT, addressed in another patch, have lead to over -a 100 bugs being filed this way. - -This commit replaces the WARN_TAINT("...") calls, with -pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) calls -avoiding the backtrace and thus also avoiding bug-reports being filed -about this against the kernel. - -BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1564895 -Fixes: e625b4a95d50 ("iommu/vt-d: Parse ANDD records") -Fixes: fd0c8894893c ("intel-iommu: Set a more specific taint flag for invalid BI -Cc: stable@vger.kernel.org -Signed-off-by: Hans de Goede ---- - drivers/iommu/dmar.c | 11 ++++++----- - 1 file changed, 6 insertions(+), 5 deletions(-) - -diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c -index 071bb42bbbc5..87194a46cb0b 100644 ---- a/drivers/iommu/dmar.c -+++ b/drivers/iommu/dmar.c -@@ -440,12 +440,13 @@ static int __init dmar_parse_one_andd(struct acpi_dmar_header *header, - - /* Check for NUL termination within the designated length */ - if (strnlen(andd->device_name, header->length - 8) == header->length - 8) { -- WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn(FW_BUG - "Your BIOS is broken; ANDD object name is not NUL-terminated\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - return -EINVAL; - } - pr_info("ANDD device: %x name: %s\n", andd->device_number, -@@ -471,14 +472,14 @@ static int dmar_parse_one_rhsa(struct acpi_dmar_header *header, void *arg) - return 0; - } - } -- WARN_TAINT( -- 1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn(FW_BUG - "Your BIOS is broken; RHSA refers to non-existent DMAR unit at %llx\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - drhd->reg_base_addr, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - - return 0; - } -@@ -827,14 +828,14 @@ int __init dmar_table_init(void) - - static void warn_invalid_dmar(u64 addr, const char *message) - { -- WARN_TAINT_ONCE( -- 1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn_once(FW_BUG - "Your BIOS is broken; DMAR reported at address %llx%s!\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - addr, message, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - } - - static int __ref --- -2.25.1 - -From 038ebd8952c5fb3ba3b5e09b0b55a4e617ae22bf Mon Sep 17 00:00:00 2001 -From: Hans de Goede -Date: Mon, 9 Mar 2020 14:12:37 +0100 -Subject: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with - pr_warn + add_taint - -Quoting from the comment describing the WARN functions in -include/asm-generic/bug.h: - - * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report - * significant kernel issues that need prompt attention if they should ever - * appear at runtime. - * - * Do not use these macros when checking for invalid external inputs - -The (buggy) firmware tables which the dmar code was calling WARN_TAINT -for really are invalid external inputs. They are not under the kernel's -control and the issues in them cannot be fixed by a kernel update. -So logging a backtrace, which invites bug reports to be filed about this, -is not helpful. - -Some distros, e.g. Fedora, have tools watching for the kernel backtraces -logged by the WARN macros and offer the user an option to file a bug for -this when these are encountered. The WARN_TAINT in dmar_parse_one_rmrr -+ another iommu WARN_TAINT, addressed in another patch, have lead to over -a 100 bugs being filed this way. - -This commit replaces the WARN_TAINT("...") call, with a -pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) call -avoiding the backtrace and thus also avoiding bug-reports being filed -about this against the kernel. - -BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1808874 -Fixes: f5a68bb0752e ("iommu/vt-d: Mark firmware tainted if RMRR fails sanity check") -Cc: Barret Rhoden -Cc: stable@vger.kernel.org -Signed-off-by: Hans de Goede ---- - drivers/iommu/intel-iommu.c | 6 ++++-- - 1 file changed, 4 insertions(+), 2 deletions(-) - -diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c -index 6fa6de2b6ad5..3857a5cd1a75 100644 ---- a/drivers/iommu/intel-iommu.c -+++ b/drivers/iommu/intel-iommu.c -@@ -4460,14 +4460,16 @@ int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg) - struct dmar_rmrr_unit *rmrru; - - rmrr = (struct acpi_dmar_reserved_memory *)header; -- if (arch_rmrr_sanity_check(rmrr)) -- WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND, -+ if (arch_rmrr_sanity_check(rmrr)) { -+ pr_warn(FW_BUG - "Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - rmrr->base_address, rmrr->end_address, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); -+ } - - rmrru = kzalloc(sizeof(*rmrru), GFP_KERNEL); - if (!rmrru) --- -2.25.1 - diff --git a/kernel.spec b/kernel.spec index 29ee80e9b..788a0c9ba 100644 --- a/kernel.spec +++ b/kernel.spec @@ -56,7 +56,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 9 +%define stable_update 10 # Set rpm version accordingly %if 0%{?stable_update} %define stablerev %{stable_update} @@ -568,16 +568,6 @@ Patch508: 20200310_chris_chris_wilson_co_uk.patch # Backport vboxsf from 5.6, can be dropped when we move to 5.6 Patch510: 0001-fs-Add-VirtualBox-guest-shared-folder-vboxsf-support.patch -# rhbz 1800335 -Patch511: v2_20200128_dmoulding_me_com.patch - -# Fix backtraces triggered by warnings about buggy BIOS (rhbz 1564895, 1808874) -# Submitted upstream -Patch512: iommu-WARN_TAINT-fixes.patch - -# Fix some HP x360 models not booting (rhbz 1790115) (in mainline now) -Patch513: 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch - # Fix UCSI oopses, (rhbz 1785972) (in gkh's usb-linus, heading towards mainline) Patch514: ucsi-oops-fixes.patch @@ -1821,6 +1811,9 @@ fi # # %changelog +* Wed Mar 18 2020 Justin M. Forbes - 5.5.10-100 +- Linux v5.5.10 + * Sat Mar 14 2020 Hans de Goede - Fix UCSI oopses (rhbz 1785972) diff --git a/sources b/sources index 4d3dad408..dcd889cb4 100644 --- a/sources +++ b/sources @@ -1,3 +1,2 @@ SHA512 (linux-5.5.tar.xz) = fa74fdabb5e63384a39e54da05b86a9ae9ea16179524b041fbbdffc7177e80b53600ae98d76be127ba216148f9dc55fe07ab20637e22c6d6030cb4aa09eb2f86 -SHA512 (patch-5.5.8.xz) = 8daaea68d2eaa51966bae5de14c253daf6ae6dd65cf0541e2f94459df99031d3d4355f436d182b2b9cea5fbfee3c053ac2bc91030dfa23a9f4575996528fd508 -SHA512 (patch-5.5.9.xz) = 44f26e7bce86c149fb4ddae20306ae58dead5a4797c268409f12284c695de80bde4a1b8bb1492f51db0f36210543d4a277024481e43acda10c3bb03470bf5270 +SHA512 (patch-5.5.10.xz) = 7b83ce898dfab2fe67c8c931890470615b181b2b64b686103c0776a95f302cbca5f4b4e576dbde28af1408692ec6e7c18fb23dbec8f6255e935a137fc0b055d8 diff --git a/v2_20200128_dmoulding_me_com.patch b/v2_20200128_dmoulding_me_com.patch deleted file mode 100644 index 2cb28be39..000000000 --- a/v2_20200128_dmoulding_me_com.patch +++ /dev/null @@ -1,51 +0,0 @@ -From MAILER-DAEMON Mon Feb 24 19:54:49 2020 -From: Dan Moulding -To: linux-wireless@vger.kernel.org -Cc: johannes.berg@intel.com, emmanuel.grumbach@intel.com, luciano.coelho@intel.com, linuxwifi@intel.com, Dan Moulding -Subject: [PATCH v2 5.5] iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devices -Date: Tue, 28 Jan 2020 02:31:07 -0700 -Message-Id: <20200128093107.9740-1-dmoulding@me.com> -Sender: linux-wireless-owner@vger.kernel.org -List-ID: -X-Mailing-List: linux-wireless@vger.kernel.org -MIME-Version: 1.0 -Content-Type: text/plain; charset="utf-8" -Content-Transfer-Encoding: 7bit - -The logic for checking required NVM sections was recently fixed in -commit b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 -devices"). However, with that fixed the else is now taken for 3168 -devices and within the else clause there is a mandatory check for the -PHY_SKU section. This causes the parsing to fail for 3168 devices. - -The PHY_SKU section is really only mandatory for the IWL_NVM_EXT -layout (the phy_sku parameter of iwl_parse_nvm_data is only used when -the NVM type is IWL_NVM_EXT). So this changes the PHY_SKU section -check so that it's only mandatory for IWL_NVM_EXT. - -Fixes: b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 devices") -Signed-off-by: Dan Moulding ---- -v2: Fixed incorrect commit title in commit references in the commit message - - drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - -diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -index 46128a2a9c6e..e98ce380c7b9 100644 ---- a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -+++ b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -@@ -308,7 +308,8 @@ iwl_parse_nvm_sections(struct iwl_mvm *mvm) - } - - /* PHY_SKU section is mandatory in B0 */ -- if (!mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) { -+ if (mvm->trans->cfg->nvm_type == IWL_NVM_EXT && -+ !mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) { - IWL_ERR(mvm, - "Can't parse phy_sku in B0, empty sections\n"); - return NULL; --- -2.24.1 - - -- cgit From 5902b3e0f2d04e57f0d9920a557d8f06be2c2964 Mon Sep 17 00:00:00 2001 From: "Justin M. Forbes" Date: Fri, 20 Mar 2020 14:17:19 -0500 Subject: Fix CVE-2019-19769 (rhbz 1786174 1786175) --- ...-potential-use-after-free-problem-when-wa.patch | 77 ++++++++++++++++++++++ kernel.spec | 7 ++ 2 files changed, 84 insertions(+) create mode 100644 0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch diff --git a/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch b/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch new file mode 100644 index 000000000..65c6ba487 --- /dev/null +++ b/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch @@ -0,0 +1,77 @@ +From 6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da Mon Sep 17 00:00:00 2001 +From: yangerkun +Date: Wed, 4 Mar 2020 15:25:56 +0800 +Subject: [PATCH] locks: fix a potential use-after-free problem when wakeup a + waiter +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +'16306a61d3b7 ("fs/locks: always delete_block after waiting.")' add the +logic to check waiter->fl_blocker without blocked_lock_lock. And it will +trigger a UAF when we try to wakeup some waiter： + +Thread 1 has create a write flock a on file, and now thread 2 try to +unlock and delete flock a, thread 3 try to add flock b on the same file. + +Thread2 Thread3 + flock syscall(create flock b) + ...flock_lock_inode_wait + flock_lock_inode(will insert + our fl_blocked_member list + to flock a's fl_blocked_requests) + sleep +flock syscall(unlock) +...flock_lock_inode_wait + locks_delete_lock_ctx + ...__locks_wake_up_blocks + __locks_delete_blocks( + b->fl_blocker = NULL) + ... + break by a signal + locks_delete_block + b->fl_blocker == NULL && + list_empty(&b->fl_blocked_requests) + success, return directly + locks_free_lock b + wake_up(&b->fl_waiter) + trigger UAF + +Fix it by remove this logic, and this patch may also fix CVE-2019-19769. + +Cc: stable@vger.kernel.org +Fixes: 16306a61d3b7 ("fs/locks: always delete_block after waiting.") +Signed-off-by: yangerkun +Signed-off-by: Jeff Layton +--- + fs/locks.c | 14 -------------- + 1 file changed, 14 deletions(-) + +diff --git a/fs/locks.c b/fs/locks.c +index 44b6da032842..426b55d333d5 100644 +--- a/fs/locks.c ++++ b/fs/locks.c +@@ -753,20 +753,6 @@ int locks_delete_block(struct file_lock *waiter) + { + int status = -ENOENT; + +- /* +- * If fl_blocker is NULL, it won't be set again as this thread +- * "owns" the lock and is the only one that might try to claim +- * the lock. So it is safe to test fl_blocker locklessly. +- * Also if fl_blocker is NULL, this waiter is not listed on +- * fl_blocked_requests for some lock, so no other request can +- * be added to the list of fl_blocked_requests for this +- * request. So if fl_blocker is NULL, it is safe to +- * locklessly check if fl_blocked_requests is empty. If both +- * of these checks succeed, there is no need to take the lock. +- */ +- if (waiter->fl_blocker == NULL && +- list_empty(&waiter->fl_blocked_requests)) +- return status; + spin_lock(&blocked_lock_lock); + if (waiter->fl_blocker) + status = 0; +-- +2.25.2 + diff --git a/kernel.spec b/kernel.spec index 788a0c9ba..3f2d2fffd 100644 --- a/kernel.spec +++ b/kernel.spec @@ -571,6 +571,10 @@ Patch510: 0001-fs-Add-VirtualBox-guest-shared-folder-vboxsf-support.patch # Fix UCSI oopses, (rhbz 1785972) (in gkh's usb-linus, heading towards mainline) Patch514: ucsi-oops-fixes.patch +# CVE-2019-19769 rhbz 1786174 1786175 +Patch515: 0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch + + # END OF PATCH DEFINITIONS %endif @@ -1811,6 +1815,9 @@ fi # # %changelog +* Fri Mar 20 2020 Justin M. Forbes +- Fix CVE-2019-19769 (rhbz 1786174 1786175) + * Wed Mar 18 2020 Justin M. Forbes - 5.5.10-100 - Linux v5.5.10 -- cgit From abd266769c1dbab4025cb8d026dbfa0148357271 Mon Sep 17 00:00:00 2001 From: Jeremy Cline Date: Fri, 20 Mar 2020 17:56:53 -0400 Subject: Switch Secure Boot to lock down in integrity mode (rhbz 1815571) --- efi-secureboot.patch | 2 +- kernel.spec | 3 +++ s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch | 4 ++-- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/efi-secureboot.patch b/efi-secureboot.patch index cda57a471..227805e8c 100644 --- a/efi-secureboot.patch +++ b/efi-secureboot.patch @@ -303,7 +303,7 @@ index 77ea96b794bd..a119e1bc9623 100644 + +#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT + if (efi_enabled(EFI_SECURE_BOOT)) -+ security_lock_kernel_down("EFI Secure Boot mode", LOCKDOWN_CONFIDENTIALITY_MAX); ++ security_lock_kernel_down("EFI Secure Boot mode", LOCKDOWN_INTEGRITY_MAX); +#endif + dmi_setup(); diff --git a/kernel.spec b/kernel.spec index 3f2d2fffd..a6cbe960f 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1815,6 +1815,9 @@ fi # # %changelog +* Fri Mar 20 2020 Jeremy Cline +- Switch Secure Boot to lock down to integrity mode (rhbz 1815571) + * Fri Mar 20 2020 Justin M. Forbes - Fix CVE-2019-19769 (rhbz 1786174 1786175) diff --git a/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch b/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch index 0779418b4..70e3f76a8 100644 --- a/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch +++ b/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch @@ -3,7 +3,7 @@ From: Jeremy Cline Date: Wed, 30 Oct 2019 14:37:49 +0000 Subject: [PATCH] s390: Lock down the kernel when the IPL secure flag is set -Automatically lock down the kernel to LOCKDOWN_CONFIDENTIALITY_MAX if +Automatically lock down the kernel to LOCKDOWN_INTEGRITY_MAX if the IPL secure flag is set. Suggested-by: Philipp Rudo @@ -56,7 +56,7 @@ index 9cbf490fd162..0510ecdfc3f6 100644 log_component_list(); + if (ipl_get_secureboot()) -+ security_lock_kernel_down("Secure IPL mode", LOCKDOWN_CONFIDENTIALITY_MAX); ++ security_lock_kernel_down("Secure IPL mode", LOCKDOWN_INTEGRITY_MAX); + /* Have one command line that is parsed and saved in /proc/cmdline */ /* boot_command_line has been already set up in early.c */ -- cgit