From 49200eeb3996e373e506d4b1ba224819f5efd0ee Mon Sep 17 00:00:00 2001 From: "Jan Alexander Steffens (heftig)" Date: Mon, 16 Sep 2019 04:53:20 +0200 Subject: [PATCH 1/6] ZEN: Add sysctl and CONFIG to disallow unprivileged CLONE_NEWUSER Our default behavior continues to match the vanilla kernel. --- include/linux/user_namespace.h | 4 ++++ init/Kconfig | 16 ++++++++++++++++ kernel/fork.c | 14 ++++++++++++++ kernel/sysctl.c | 12 ++++++++++++ kernel/user_namespace.c | 7 +++++++ 5 files changed, 53 insertions(+) diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h index 33a4240e6..82213f9c4 100644 --- a/include/linux/user_namespace.h +++ b/include/linux/user_namespace.h @@ -139,6 +139,8 @@ static inline void set_rlimit_ucount_max(struct user_namespace *ns, #ifdef CONFIG_USER_NS +extern int unprivileged_userns_clone; + static inline struct user_namespace *get_user_ns(struct user_namespace *ns) { if (ns) @@ -172,6 +174,8 @@ extern bool current_in_userns(const struct user_namespace *target_ns); struct ns_common *ns_get_owner(struct ns_common *ns); #else +#define unprivileged_userns_clone 0 + static inline struct user_namespace *get_user_ns(struct user_namespace *ns) { return &init_user_ns; diff --git a/init/Kconfig b/init/Kconfig index 11f8a845f..02b7a0e45 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1226,6 +1226,22 @@ config USER_NS If unsure, say N. +config USER_NS_UNPRIVILEGED + bool "Allow unprivileged users to create namespaces" + default y + depends on USER_NS + help + When disabled, unprivileged users will not be able to create + new namespaces. Allowing users to create their own namespaces + has been part of several recent local privilege escalation + exploits, so if you need user namespaces but are + paranoid^Wsecurity-conscious you want to disable this. + + This setting can be overridden at runtime via the + kernel.unprivileged_userns_clone sysctl. + + If unsure, say Y. + config PID_NS bool "PID Namespaces" default y diff --git a/kernel/fork.c b/kernel/fork.c index 10885c649..e0fe98e1a 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -98,6 +98,10 @@ #include #include +#ifdef CONFIG_USER_NS +#include +#endif + #include #include #include @@ -1950,6 +1954,10 @@ static __latent_entropy struct task_struct *copy_process( if ((clone_flags & (CLONE_NEWUSER|CLONE_FS)) == (CLONE_NEWUSER|CLONE_FS)) return ERR_PTR(-EINVAL); + if ((clone_flags & CLONE_NEWUSER) && !unprivileged_userns_clone) + if (!capable(CAP_SYS_ADMIN)) + return ERR_PTR(-EPERM); + /* * Thread groups must share signals as well, and detached threads * can only be started up within the thread group. @@ -3056,6 +3064,12 @@ int ksys_unshare(unsigned long unshare_flags) if (unshare_flags & CLONE_NEWNS) unshare_flags |= CLONE_FS; + if ((unshare_flags & CLONE_NEWUSER) && !unprivileged_userns_clone) { + err = -EPERM; + if (!capable(CAP_SYS_ADMIN)) + goto bad_unshare_out; + } + err = check_unshare_flags(unshare_flags); if (err) goto bad_unshare_out; diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 083be6af2..42aa3c783 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -105,6 +105,9 @@ #ifdef CONFIG_LOCKUP_DETECTOR #include #endif +#ifdef CONFIG_USER_NS +#include +#endif #if defined(CONFIG_SYSCTL) @@ -1949,6 +1952,15 @@ static struct ctl_table kern_table[] = { .proc_handler = proc_dointvec, }, #endif +#ifdef CONFIG_USER_NS + { + .procname = "unprivileged_userns_clone", + .data = &unprivileged_userns_clone, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec, + }, +#endif #ifdef CONFIG_PROC_SYSCTL { .procname = "tainted", diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index 6b2e3ca7e..025300218 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -21,6 +21,13 @@ #include #include +/* sysctl */ +#ifdef CONFIG_USER_NS_UNPRIVILEGED +int unprivileged_userns_clone = 1; +#else +int unprivileged_userns_clone; +#endif + static struct kmem_cache *user_ns_cachep __read_mostly; static DEFINE_MUTEX(userns_state_mutex); -- 2.34.1.75.gabe6bb3905 From 70cf9bde1a3d9ffe1d0302347af790d6a9c4b221 Mon Sep 17 00:00:00 2001 From: "Jan Alexander Steffens (heftig)" Date: Thu, 18 Nov 2021 22:53:31 +0100 Subject: [PATCH 2/6] PCI: Add more NVIDIA controllers to the MSI masking quirk For: https://bugs.archlinux.org/task/72734 For: https://bugs.archlinux.org/task/72777 --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 208fa03ac..7fdb7e9c2 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5802,3 +5802,5 @@ static void nvidia_ion_ahci_fixup(struct pci_dev *pdev) pdev->dev_flags |= PCI_DEV_FLAGS_HAS_MSI_MASKING; } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0ab8, nvidia_ion_ahci_fixup); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0ab9, nvidia_ion_ahci_fixup); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, 0x0d88, nvidia_ion_ahci_fixup); -- 2.34.1.75.gabe6bb3905 From 94ae4eafa0a14eeb310181197ae26e6c540d85ee Mon Sep 17 00:00:00 2001 From: Ajay Garg Date: Tue, 12 Oct 2021 19:26:53 +0530 Subject: [PATCH 3/6] iommu: intel: do deep dma-unmapping, to avoid kernel-flooding. Origins at : https://lists.linuxfoundation.org/pipermail/iommu/2021-October/thread.html === Changes from v1 => v2 === a) Improved patch-description. b) A more root-level fix, as suggested by 1. Alex Williamson 2. Lu Baolu === Issue === Kernel-flooding is seen, when an x86_64 L1 guest (Ubuntu-21) is booted in qemu/kvm on a x86_64 host (Ubuntu-21), with a host-pci-device attached. Following kind of logs, along with the stacktraces, cause the flood : ...... DMAR: ERROR: DMA PTE for vPFN 0x428ec already set (to 3f6ec003 not 3f6ec003) DMAR: ERROR: DMA PTE for vPFN 0x428ed already set (to 3f6ed003 not 3f6ed003) DMAR: ERROR: DMA PTE for vPFN 0x428ee already set (to 3f6ee003 not 3f6ee003) DMAR: ERROR: DMA PTE for vPFN 0x428ef already set (to 3f6ef003 not 3f6ef003) DMAR: ERROR: DMA PTE for vPFN 0x428f0 already set (to 3f6f0003 not 3f6f0003) ...... === Current Behaviour, leading to the issue === Currently, when we do a dma-unmapping, we unmap/unlink the mappings, but the pte-entries are not cleared. Thus, following sequencing would flood the kernel-logs : i) A dma-unmapping makes the real/leaf-level pte-slot invalid, but the pte-content itself is not cleared. ii) Now, during some later dma-mapping procedure, as the pte-slot is about to hold a new pte-value, the intel-iommu checks if a prior pte-entry exists in the pte-slot. If it exists, it logs a kernel-error, along with a corresponding stacktrace. iii) Step ii) runs in abundance, and the kernel-logs run insane. === Fix === We ensure that as part of a dma-unmapping, each (unmapped) pte-slot is also cleared of its value/content (at the leaf-level, where the real mapping from a iova => pfn mapping is stored). This completes a "deep" dma-unmapping. Signed-off-by: Ajay Garg Link: https://lore.kernel.org/linux-iommu/20211012135653.3852-1-ajaygargnsit@gmail.com/ --- drivers/iommu/intel/iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 78f8c8e68..d8da48a91 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -5092,6 +5092,8 @@ static size_t intel_iommu_unmap(struct iommu_domain *domain, gather->freelist = domain_unmap(dmar_domain, start_pfn, last_pfn, gather->freelist); + dma_pte_clear_range(dmar_domain, start_pfn, last_pfn); + if (dmar_domain->max_addr == iova + size) dmar_domain->max_addr = iova; -- 2.34.1.75.gabe6bb3905 From 1013d5481e2c135ca4e86193ccc30b10c61ee91c Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Thu, 18 Nov 2021 21:18:01 -0800 Subject: [PATCH 4/6] cpufreq: intel_pstate: ITMT support for overclocked system On systems with overclocking enabled, CPPC Highest Performance can be hard coded to 0xff. In this case even if we have cores with different highest performance, ITMT can't be enabled as the current implementation depends on CPPC Highest Performance. On such systems we can use MSR_HWP_CAPABILITIES maximum performance field when CPPC.Highest Performance is 0xff. Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as in some older systems CPPC Highest Performance is the only way to identify different performing cores. Reported-by: Michael Larabel Signed-off-by: Srinivas Pandruvada --- drivers/cpufreq/intel_pstate.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index e15c3bc17..8a2c6b58b 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -335,6 +335,8 @@ static void intel_pstste_sched_itmt_work_fn(struct work_struct *work) static DECLARE_WORK(sched_itmt_work, intel_pstste_sched_itmt_work_fn); +#define CPPC_MAX_PERF U8_MAX + static void intel_pstate_set_itmt_prio(int cpu) { struct cppc_perf_caps cppc_perf; @@ -345,6 +347,14 @@ static void intel_pstate_set_itmt_prio(int cpu) if (ret) return; + /* + * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff. + * In this case we can't use CPPC.highest_perf to enable ITMT. + * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide. + */ + if (cppc_perf.highest_perf == CPPC_MAX_PERF) + cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached)); + /* * The priorities can be set regardless of whether or not * sched_set_itmt_support(true) has been called and it is valid to -- 2.34.1.75.gabe6bb3905 From 9f0a10461f6f5f134354da5c19a9548187484072 Mon Sep 17 00:00:00 2001 From: Kiran K Date: Wed, 13 Oct 2021 13:35:11 +0530 Subject: [PATCH 5/6] Bluetooth: btintel: Fix bdaddress comparison with garbage value Intel Read Verision(TLV) data is parsed into a local structure variable and it contains a field for bd address. Bd address is returned only in bootloader mode and hence bd address in TLV structure needs to be validated only if controller is present in boot loader mode. Signed-off-by: Kiran K Reviewed-by: Tedd Ho-Jeong An --- drivers/bluetooth/btintel.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c index f1705b46f..b9055a3e6 100644 --- a/drivers/bluetooth/btintel.c +++ b/drivers/bluetooth/btintel.c @@ -2006,14 +2006,16 @@ static int btintel_prepare_fw_download_tlv(struct hci_dev *hdev, if (ver->img_type == 0x03) { btintel_clear_flag(hdev, INTEL_BOOTLOADER); btintel_check_bdaddr(hdev); - } - - /* If the OTP has no valid Bluetooth device address, then there will - * also be no valid address for the operational firmware. - */ - if (!bacmp(&ver->otp_bd_addr, BDADDR_ANY)) { - bt_dev_info(hdev, "No device address configured"); - set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks); + } else { + /* + * Check for valid bd address in boot loader mode. Device + * will be marked as unconfigured if empty bd address is + * found. + */ + if (!bacmp(&ver->otp_bd_addr, BDADDR_ANY)) { + bt_dev_info(hdev, "No device address configured"); + set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks); + } } btintel_get_fw_name_tlv(ver, fwname, sizeof(fwname), "sfi"); @@ -2303,6 +2305,10 @@ static int btintel_setup_combined(struct hci_dev *hdev) goto exit_error; } + /* memset ver_tlv to start with clean state as few fields are exclusive + * to bootloader mode and are not populated in operational mode + */ + memset(&ver_tlv, 0, sizeof(ver_tlv)); /* For TLV type device, parse the tlv data */ err = btintel_parse_version_tlv(hdev, &ver_tlv, skb); if (err) { -- 2.34.1.75.gabe6bb3905 From 4fcc80f5ae27a1c283c1415cfc806838a4ac045d Mon Sep 17 00:00:00 2001 From: Matan Ziv-Av Date: Tue, 23 Nov 2021 22:14:55 +0200 Subject: [PATCH 6/6] lg-laptop: Recognize more models LG uses 5 instead of 0 in the third digit (second digit after 2019) of the year string to indicate newer models in the same year. Handle this case as well. Signed-off-by: Matan Ziv-Av For: https://bugs.archlinux.org/task/71772 --- drivers/platform/x86/lg-laptop.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/platform/x86/lg-laptop.c b/drivers/platform/x86/lg-laptop.c index 88b551cae..d6f74d3a7 100644 --- a/drivers/platform/x86/lg-laptop.c +++ b/drivers/platform/x86/lg-laptop.c @@ -658,6 +658,18 @@ static int acpi_add(struct acpi_device *device) if (product && strlen(product) > 4) switch (product[4]) { case '5': + if (strlen(product) > 5) + switch (product[5]) { + case 'N': + year = 2021; + break; + case '0': + year = 2016; + break; + default: + year = 2022; + } + break; case '6': year = 2016; break; -- 2.34.1.75.gabe6bb3905