| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| bugfix/all/partially-revert-net-socket-implement-64-bit-timestamps.patch | Partially revert "net: socket: implement 64-bit timestamps" The introduction of SIOCGSTAMP{,NS}_OLD and move of SICOGSTAMP{,NS} to a different header has caused build failures for various user-space programs including qemu and suricata. It also causes a test failure for glibc. For now, remove the _OLD suffix on the old ioctl numbers and require programs using 64-bit timestamps to explicitly use SIOCGSTAMP{,NS}_NEW. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-08-20 | ||
| bugfix/all/wireguard-ignore-config_android.patch | wireguard: Clear keys after suspend despite CONFIG_ANDROID=y WireGuard assumes that CONFIG_ANDROID implies Android power management, i.e. user-space suspending the system automatically at short intervals, and so does not clear keys after a suspend/resume cycle. Debian systems don't do that kind of power management but we do set CONFIG_ANDROID on some architectures as a dependency of Binder. In 5.20, CONFIG_PM_USERSPACE_AUTOSLEEP will be introduced to tell the kernel that this kind of power management is in use, and CONFIG_ANDROID will be removed. For now, remove this one test that does the wrong thing for us. |
Ben Hutchings <benh@debian.org> | not-needed | 2022-07-07 | ||
| debian/gitignore.patch | Tweak gitignore for Debian pkg-kernel using git svn. [bwh: Tweak further for pure git] |
Ian Campbell <ijc@hellion.org.uk> | not-needed | 2013-01-17 | ||
| debian/dfsg/arch-powerpc-platforms-8xx-ucode-disable.patch | Remove microcode patches for mgsuvd (not enabled in Debian configs) diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig index 48a920a..81570b6 100644 |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2009-04-13 | ||
| debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch | dvb-usb-af9005: mark as broken | Ben Hutchings <ben@decadent.org.uk> | not-needed | 2009-08-17 | ||
| debian/dfsg/vs6624-disable.patch | vs6624: mark as broken | Ben Hutchings <ben@decadent.org.uk> | not-needed | 2012-05-27 | ||
| debian/dfsg/drivers-net-appletalk-cops.patch | Add removal patches for: 3c359, smctr, keyspan, cops | Frederik Schüler <fs@debian.org> | not-needed | 2007-01-05 | ||
| debian/dfsg/video-remove-nvidiafb-and-rivafb.patch | video: Remove nvidiafb and rivafb These drivers contain register programming code provided by the hardware vendor that appears to have been deliberately obfuscated. This is arguably not the preferred form for modification. These drivers are also largely redundant with nouveau. The RIVA 128 (NV3) is not supported by nouveau but is about 15 years old and probably discontinued 10 years ago. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2012-06-02 | |
| debian/dfsg/documentation-fix-broken-link-to-cipso-draft.patch | Documentation: Fix broken link to CIPSO draft We exclude the CIPSO draft text as its licence is not DFSG compliant. Link to the IETF's online version instead. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2019-08-24 | ||
| debian/version.patch | Include package version along with kernel release in stack traces For distribution binary packages we assume $DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION are set. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2012-07-24 | ||
| debian/uname-version-timestamp.patch | Make mkcompile_h accept an alternate timestamp string We want to include the Debian version in the utsname::version string instead of a full timestamp string. However, we still need to provide a standard timestamp string for gen_initramfs_list.sh to make the kernel image reproducible. Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to $KBUILD_BUILD_TIMESTAMP. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2015-05-12 | ||
| debian/kernelvariables.patch | kbuild: Make the toolchain variables easily overwritable Allow make variables to be overridden for each flavour by a file in the build tree, .kernelvariables. We currently use this for ARCH, KERNELRELEASE, CC, and in some cases also CROSS_COMPILE, KCFLAGS. This file can only be read after we establish the build tree, and all use of $(ARCH) needs to be moved after this. [bwh: Updated for 5.3: include .kernelvariables from current directory rather than using undefined $(obj).] |
Bastian Blank <waldi@debian.org> | not-needed | 2009-02-22 | ||
| debian/ia64-hardcode-arch-script-output.patch | Hardcode arch script output Here's a patch that simply uses hardcoded definitions instead of doing the dynamic tests that require architecture-specific scripts. I don't particularly like this approach because it restricts portability and diverts from upstream. But, it is simpler, and this really needs to be fixed somehow before etch (along with a rebuild of linux-modules-extra-2.6), so I'm willing to live with it if my other patch is deemed unacceptable. My primary concern is that, in the future, the output of these scripts will change and we (or our successors) will either not notice or forget to update the hardcoded values. Including the scripts in linux-kbuild will avoid this manual step altogether, and allow for the possibility of other archs to provide their own scripts in the future. |
dann frazier <dannf@debian.org> | not-needed | debian | 2007-03-26 | |
| debian/mips-disable-werror.patch | [PATCH] Partially revert "MIPS: Add -Werror to arch/mips/Kbuild" This reverts commits 66f9ba101f54bda63ab1db97f9e9e94763d0651b and 5373633cc9253ba82547473e899cab141c54133e. We really don't want to add -Werror anywhere. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2010-09-13 | ||
| debian/mips-boston-disable-its.patch | Disable uImage generation for mips generic MIPS generic trys to generate uImage when build, which then ask for u-boot-tools. |
YunQiang Su <syq@debian.org> | not-needed | 2018-05-14 | ||
| debian/mips-ieee754-relaxed.patch | Use RELAXED ieee754 mode for Loongson-3 as 3A 4000 is 2008-only There are 2 mode of value of IEEE NaN hardcoded by CPU. Currently, our mipsel/mips64el port is in so-called lagacy mode. Loongson 3A 4000 is set as the so-called 2008 mode. To make Debian workable on Loongson 3A 4000, we need set the kerenl in RELAXED mode. https://web.archive.org/web/20180830093617/https://dmz-portal.mips.com/wiki/MIPS_ABI_-_NaN_Interlinking diff --git a/arch/mips/kernel/fpu-probe.c b/arch/mips/kernel/fpu-probe.c index e689d6a83..667226f94 100644 |
YunQiang Su <syq@debian.org> | not-needed | 2020-11-16 | ||
| debian/arch-sh4-fix-uimage-build.patch | [sh4] Fix uImage build [bwh: This was added without a description, but I think it is done only to avoid a build-dependency on u-boot-tools.] |
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> | not-needed | debian | ||
| debian/tools-perf-version.patch | Create manpages and binaries including the version [bwh: Fix version insertion in perf man page cross-references and perf man page title. Install bash_completion script for perf with a version-dependent name. And do the same for trace.] |
Bastian Blank <waldi@debian.org> | no | 2011-09-26 | ||
| debian/tools-perf-install.patch | Install perf scripts non-executable [bwh: Forward-ported to 4.13] |
Bastian Blank <waldi@debian.org> | no | 2011-10-07 | ||
| debian/wireless-add-debian-wireless-regdb-certificates.patch | wireless: Add Debian wireless-regdb certificates This hex dump is generated using: { for cert in debian/certs/wireless-regdb-*.pem; do openssl x509 -in $cert -outform der; done } | hexdump -v -e '1/1 "0x%.2x," "\n"' > net/wireless/certs/debian.hex |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2018-04-13 | ||
| debian/export-symbols-needed-by-android-drivers.patch | Export symbols needed by Android drivers We want to enable use of the Android ashmem and binder drivers to support Anbox, but they should not be built-in as that would waste resources and increase security attack surface on systems that don't need them. Export the currently un-exported symbols they depend on. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2020-09-07 | |
| debian/android-enable-building-ashmem-and-binder-as-modules.patch | android: Enable building ashmem and binder as modules We want to enable use of the Android ashmem and binder drivers to support Anbox, but they should not be built-in as that would waste resources and increase security attack surface on systems that don't need them. - Add a MODULE_LICENSE declaration to ashmem - Change the Makefiles to build each driver as an object with the "_linux" suffix (which is what Anbox expects) - Change config symbol types to tristate |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2018-06-22 | |
| debian/documentation-drop-sphinx-version-check.patch | [PATCH 1/2] Documentation: Drop sphinx version check | Bastian Blank <waldi@debian.org> | not-needed | 2020-08-04 | ||
| debian/perf-traceevent-support-asciidoctor-for-documentatio.patch | [PATCH 2/2] perf/traceevent: Support asciidoctor for documentation | Bastian Blank <waldi@debian.org> | not-needed | 2020-08-04 | ||
| debian/kbuild-look-for-module.lds-under-arch-directory-too.patch | kbuild: Look for module.lds under arch directory too The module.lds linker script is now built under the scripts directory, where previously it was under arch/$(SRCARCH). However, we package the scripts directory as linux-kbuild, which is meant to be able to do support native and cross-builds. That means it shouldn't contain files for a specific target architecture without a wrapper to select between them, and it doesn't appear that linker scripts are powerful enough to implement such a wrapper. Building module.lds in a different location would require relatively large changes. Moving it in the package build rules can work, but we need to support custom kernel builds from the same source so we can't assume it's moved. Therefore, we move module.lds under the arch build directory in rules.real and change Makefile.modfinal to look for it in both places. |
Ben Hutchings <benh@debian.org> | not-needed | debian | 2020-12-10 | |
| debian/kbuild-abort-build-if-subdirs-used.patch | kbuild: Abort build if SUBDIRS used DKMS and module-assistant both build OOT modules as root. If they build an old OOT module that still use SUBDIRS this causes Kbuild to try building a full kernel, which obviously fails but not before deleting files from the installed headers package. To avoid such mishaps, detect this situation and abort the build. The error message is based on that used in commit 0126be38d988 "kbuild: announce removal of SUBDIRS if used". |
Ben Hutchings <benh@debian.org> | not-needed | debian | 2021-04-26 | |
| features/all/drivers-media-dvb-usb-af9005-request_firmware.patch | af9005: Use request_firmware() to load register init script Read the register init script from the Windows driver. This is sick but should avoid the potential copyright infringement in distributing a version of the script which is directly derived from the driver. |
Ben Hutchings <ben@decadent.org.uk> | no | 2009-08-24 | ||
| debian/iwlwifi-do-not-request-unreleased-firmware.patch | iwlwifi: Do not request unreleased firmware for IWL6000 The iwlwifi driver currently supports firmware API versions 4-6 for these devices. It will request the file for the latest supported version and then fall back to earlier versions. However, the latest version that has actually been released is 4, so we expect the requests for versions 6 and then 5 to fail. The installer appears to report any failed request, and it is probably not easy to detect that this particular failure is harmless. So stop requesting the unreleased firmware. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | debian | ||
| bugfix/all/firmware_class-log-every-success-and-failure.patch | firmware_class: Log every success and failure against given device The hundreds of users of request_firmware() have nearly as many different log formats for reporting failures. They also have only the vaguest hint as to what went wrong; only firmware_class really knows that. Therefore, add specific log messages for the failure modes that aren't currently logged. In case of a driver that tries multiple names, this may result in the impression that it failed to initialise. Therefore, also log successes. This makes many error messages in drivers redundant, which will be removed in later patches. This does not cover the case where we fall back to a user-mode helper (which is no longer enabled in Debian). format to detect missing firmware. |
Ben Hutchings <ben@decadent.org.uk> | no | 2012-12-09 | ||
| bugfix/all/firmware-remove-redundant-log-messages-from-drivers.patch | firmware: Remove redundant log messages from drivers Now that firmware_class logs every success and failure consistently, many other log messages can be removed from drivers. This will probably need to be split up into multiple patches prior to upstream submission. |
Ben Hutchings <ben@decadent.org.uk> | no | 2012-12-09 | ||
| bugfix/all/radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch | radeon, amdgpu: Firmware is required for DRM and KMS on R600 onward radeon requires firmware/microcode for the GPU in all chips, but for newer chips (apparently R600 'Evergreen' onward) it also expects firmware for the memory controller and other sub-blocks. radeon attempts to gracefully fall back and disable some features if the firmware is not available, but becomes unstable - the framebuffer and/or system memory may be corrupted, or the display may stay black. Therefore, perform a basic check for the existence of /lib/firmware/{radeon,amdgpu} when a device is probed, and abort if it is missing, except for the pre-R600 case. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2013-01-08 | |
| debian/firmware_class-refer-to-debian-wiki-firmware-page.patch | firmware_class: Refer to Debian wiki page when logging missing firmware If firmware loading fails due to a missing file, log a second error message referring to our wiki page about firmware. This will explain why some firmware is in non-free, or can't be packaged at all. Only do this once per boot. Do something similar in the radeon and amdgpu drivers, where we have an early check to avoid failing at a point where we cannot display anything. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | debian | 2018-03-12 | |
| debian/af_802154-Disable-auto-loading-as-mitigation-against.patch | [PATCH 2/3] af_802154: Disable auto-loading as mitigation against local exploits Recent review has revealed several bugs in obscure protocol implementations that can be exploited by local users for denial of service or privilege escalation. We can mitigate the effect of any remaining vulnerabilities in such protocols by preventing unprivileged users from loading the modules, so that they are only exploitable on systems where the administrator has chosen to load the protocol. The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was not present in the 'lenny' kernel, and seems to receive only sporadic maintenance. Therefore disable auto-loading. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2010-11-19 | ||
| debian/rds-Disable-auto-loading-as-mitigation-against-local.patch | [PATCH 1/3] rds: Disable auto-loading as mitigation against local exploits Recent review has revealed several bugs in obscure protocol implementations that can be exploited by local users for denial of service or privilege escalation. We can mitigate the effect of any remaining vulnerabilities in such protocols by preventing unprivileged users from loading the modules, so that they are only exploitable on systems where the administrator has chosen to load the protocol. The 'rds' protocol is one such protocol that has been found to be vulnerable, and which was not present in the 'lenny' kernel. Therefore disable auto-loading. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2010-11-19 | ||
| debian/dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch | dccp: Disable auto-loading as mitigation against local exploits We can mitigate the effect of vulnerabilities in obscure protocols by preventing unprivileged users from loading the modules, so that they are only exploitable on systems where the administrator has chosen to load the protocol. The 'dccp' protocol is not actively maintained or widely used. Therefore disable auto-loading. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2017-02-16 | ||
| debian/hamradio-disable-auto-loading-as-mitigation-against-local-exploits.patch | hamradio: Disable auto-loading as mitigation against local exploits We can mitigate the effect of vulnerabilities in obscure protocols by preventing unprivileged users from loading the modules, so that they are only exploitable on systems where the administrator has chosen to load the protocol. The 'ham' radio protocols (ax25, netrom, rose) are not actively maintained or widely used. Therefore disable auto-loading. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2019-08-05 | ||
| debian/fs-enable-link-security-restrictions-by-default.patch | fs: Enable link security restrictions by default This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415 ('VFS: don't do protected {sym,hard}links by default'). |
Ben Hutchings <ben@decadent.org.uk> | not-needed | debian | 2012-11-02 | |
| debian/sched-autogroup-disabled.patch | sched: Do not enable autogrouping by default We want to provide the option of autogrouping but without enabling it by default yet. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2011-03-16 | ||
| debian/yama-disable-by-default.patch | yama: Disable by default | Ben Hutchings <ben@decadent.org.uk> | not-needed | debian | 2013-06-19 | |
| debian/add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch | add sysctl to disallow unprivileged CLONE_NEWUSER by default add sysctl to disallow unprivileged CLONE_NEWUSER by default This is a short-term patch. Unprivileged use of CLONE_NEWUSER is certainly an intended feature of user namespaces. However for at least saucy we want to make sure that, if any security issues are found, we have a fail-safe. [bwh: Remove unneeded binary sysctl bits] [bwh: Keep this sysctl, but change the default to enabled] |
Serge Hallyn <serge.hallyn@canonical.com> | no | http://kernel.ubuntu.com/git?p=serge%2Fubuntu-saucy.git;a=commit;h=5c847404dcb2e3195ad0057877e1422ae90892b8 | 2013-05-31 | |
| features/all/security-perf-allow-further-restriction-of-perf_event_open.patch | security,perf: Allow further restriction of perf_event_open When kernel.perf_event_open is set to 3 (or greater), disallow all access to performance events by users without CAP_SYS_ADMIN. Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that makes this value the default. This is based on a similar feature in grsecurity (CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making the variable read-only. It also allows enabling further restriction at run-time regardless of whether the default is changed. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2016-01-11 | ||
| features/x86/intel-iommu-add-option-to-exclude-integrated-gpu-only.patch | intel-iommu: Add option to exclude integrated GPU only There is still laptop firmware that touches the integrated GPU behind the operating system's back, and doesn't say so in the RMRR table. Enabling the IOMMU for all devices causes breakage, but turning it off for all graphics devices seems like a major weakness. Add an option, intel_iommu=igpu_off, to exclude only integrated GPUs from remapping. This is a narrower exclusion than igfx_off: it only affects Intel devices on the root bus. Devices attached through an external port (Thunderbolt or ExpressCard) won't be on the root bus. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2019-08-21 | |
| features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch | intel-iommu: Add Kconfig option to exclude iGPU by default There is still laptop firmware that touches the integrated GPU behind the operating system's back, and doesn't say so in the RMRR table. Enabling the IOMMU for all devices causes breakage. Replace CONFIG_INTEL_IOMMU_DEFAULT_ON with a 3-way choice corresponding to "on", "off", and "on,intgpu_off". |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2019-08-21 | |
| debian/cdc_ncm-cdc_mbim-use-ncm-by-default.patch | cdc_ncm,cdc_mbim: Use NCM by default Devices that support both NCM and MBIM modes should be kept in NCM mode unless there is userland support for MBIM. Set the default value of cdc_ncm.prefer_mbim to false and leave it to userland (modem-manager) to override this with a modprobe.conf file once it's ready to speak MBIM. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2013-03-31 | ||
| debian/snd-pcsp-disable-autoload.patch | snd-pcsp: Disable autoload There are two drivers claiming the platform:pcspkr device: - pcspkr creates an input(!) device that can only beep - snd-pcsp creates an equivalent input device plus a PCM device that can play barely recognisable renditions of sampled sound snd-pcsp is blacklisted by the alsa-base package, but not everyone installs that. On PCs where no sound is wanted at all, both drivers will still be loaded and one or other will complain that it couldn't claim the relevant I/O range. In case anyone finds snd-pcsp useful, we continue to build it. But remove the alias, to ensure it's not loaded where it's not wanted. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | debian | 2014-02-05 | |
| bugfix/x86/viafb-autoload-on-olpc-xo1.5-only.patch | viafb: Autoload on OLPC XO 1.5 only It appears that viafb won't work automatically on all the boards for which it has a PCI device ID match. Currently, it is blacklisted by udev along with most other framebuffer drivers, so this doesn't matter much. However, this driver is required for console support on the XO 1.5. We need to allow it to be autoloaded on this model only, and then un-blacklist it in udev. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2013-04-20 | |
| debian/fjes-disable-autoload.patch | fjes: Disable auto-loading fjes matches a generic ACPI device ID, and relies on its probe function to distinguish whether that really corresponds to a supported device. Very few system will need the driver and it wastes memory on all the other systems where the same device ID appears, so disable auto-loading. |
Ben Hutchings <ben@decadent.org.uk> | no | debian | 2017-03-18 | |
| debian/fanotify-taint-on-use-of-fanotify_access_permissions.patch | fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS Various free and proprietary AV products use this feature and users apparently want it. But punting access checks to userland seems like an easy way to deadlock the system, and there will be nothing we can do about that. So warn and taint the kernel if this feature is actually used. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2016-07-13 | ||
| debian/btrfs-warn-about-raid5-6-being-experimental-at-mount.patch | btrfs: warn about RAID5/6 being experimental at mount time Too many people come complaining about losing their data -- and indeed, there's no warning outside a wiki and the mailing list tribal knowledge. Message severity chosen for consistency with XFS -- "alert" makes dmesg produce nice red background which should get the point across. [bwh: Also add_taint() so this is flagged in bug reports] |
Adam Borowski <kilobyte@angband.pl> | no | debian | https://bugs.debian.org/863290#5 | 2017-03-28 |
| bugfix/arm/arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch | ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419 The old board code for the TS419 assigns MPP pins 15 and 16 as SATA activity signals (and none as SATA presence signals). Currently the device tree assigns the SoC's default pinmux groups for SATA, which conflict with the second Ethernet port. |
Ben Hutchings <ben@decadent.org.uk> | yes | debian | 2017-02-17 | |
| bugfix/arm64/dts-rockchip-correct-voltage-selector-firefly-RK3399.patch | arm64: dts: rockchip: correct voltage selector on Firefly-RK3399 Without this patch the Firefly-RK3399 board boot process hangs after these lines: fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! fan53555-reg: supplied by vcc_sys vcc1v8_s3: supplied by vcc_1v8 Blacklisting driver fan53555 allows booting. The device tree uses a value of fcs,suspend-voltage-selector different to any other board. Changing this setting to the usual value is sufficient to enable booting and also matches the value used in the vendor kernel. |
Heinrich Schuchardt <xypron.glpk@gmx.de> | no | debian | https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/patch/?id=710e8c4a54be82ee8a97324e7b4330bf191e08bf | 2018-06-04 |
| bugfix/x86/perf-tools-fix-unwind-build-on-i386.patch | perf tools: Fix unwind build on i386 EINVAL may not be defined when building unwind-libunwind.c with REMOTE_UNWIND_LIBUNWIND, resulting in a compiler error in LIBUNWIND__ARCH_REG_ID(). Its only caller, access_reg(), only checks for a negative return value and doesn't care what it is. So change -EINVAL to -1. |
Ben Hutchings <ben@decadent.org.uk> | no | 2017-07-22 | ||
| bugfix/sh/sh-boot-do-not-use-hyphen-in-exported-variable-name.patch | sh: Do not use hyphen in exported variable names arch/sh/Makefile defines and exports ld-bfd to be used by arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile. Similarly arch/sh/boot/Makefile defines and exports suffix-y to be used by arch/sh/boot/compressed/Makefile. However some shells, including dash, will not pass through environment variables whose name includes a hyphen. Usually GNU make does not use a shell to recurse, but if e.g. $(srctree) contains '~' it will use a shell here. Rename these variables to ld_bfd and suffix_y. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2017-08-19 | ||
| bugfix/arm/arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch | ARM: mm: Export __sync_icache_dcache() for xen-privcmd The xen-privcmd driver, which can be modular, calls set_pte_at() which in turn may call __sync_icache_dcache(). The call to __sync_icache_dcache() may be optimised out because it is conditional on !pte_special(), and xen-privcmd calls pte_mkspecial(). However, in a non-LPAE configuration there is no "special" bit and the call is really unconditional. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2018-07-11 | ||
| bugfix/all/revert-bpf-eliminate-rlimit-based-memory-accounting-for-devmap-maps.patch | Revert "bpf: Eliminate rlimit-based memory accounting for devmap maps" This reverts commit 70294d8bc31f3b7789e5e32f757aa9344556d964 which is commit 844f157f6c0a905d039d2e20212ab3231f2e5eaf upstream. Commit 70294d8bc31f ("bpf: Eliminate rlimit-based memory accounting for devmap maps") is part of the v5.11+ base mechanism of memcg-based memory accounting[0]. The commit cannot be independently backported to the 5.10 stable branch, otherwise the related memory when creating devmap will be unrestricted. Let's roll back to rlimit-based memory accounting mode for devmap. |
Pu Lehui <pulehui@huawei.com> | no | 2024-09-27 | ||
| bugfix/all/bpf-fix-devmap_hash-overflow-check-on-32-bit-arches.patch | bpf: Fix DEVMAP_HASH overflow check on 32-bit arches [ Upstream commit 281d464a34f540de166cee74b723e97ac2515ec3 ] The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. |
Toke Høiland-Jørgensen <toke@redhat.com> | no | 2024-09-27 | ||
| bugfix/all/cgroup-make-operations-on-the-cgroup-root_list-rcu-s.patch | cgroup: Make operations on the cgroup root_list RCU safe [ Upstream commit d23b5c577715892c87533b13923306acc6243f93 ] At present, when we perform operations on the cgroup root_list, we must hold the cgroup_mutex, which is a relatively heavyweight lock. In reality, we can make operations on this list RCU-safe, eliminating the need to hold the cgroup_mutex during traversal. Modifications to the list only occur in the cgroup root setup and destroy paths, which should be infrequent in a production environment. In contrast, traversal may occur frequently. Therefore, making it RCU-safe would be beneficial. |
Yafang Shao <laoar.shao@gmail.com> | no | 2023-10-29 | ||
| bugfix/all/cgroup-move-rcu_head-up-near-the-top-of-cgroup_root.patch | cgroup: Move rcu_head up near the top of cgroup_root commit a7fb0423c201ba12815877a0b5a68a6a1710b23a upstream. Commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe") adds a new rcu_head to the cgroup_root structure and kvfree_rcu() for freeing the cgroup_root. The current implementation of kvfree_rcu(), however, has the limitation that the offset of the rcu_head structure within the larger data structure must be less than 4096 or the compilation will fail. See the macro definition of __is_kvfree_rcu_offset() in include/linux/rcupdate.h for more information. By putting rcu_head below the large cgroup structure, any change to the cgroup structure that makes it larger run the risk of causing build failure under certain configurations. Commit 77070eeb8821 ("cgroup: Avoid false cacheline sharing of read mostly rstat_cpu") happens to be the last straw that breaks it. Fix this problem by moving the rcu_head structure up before the cgroup structure. |
Waiman Long <longman@redhat.com> | no | 2023-12-07 | ||
| bugfix/all/revert-bpf-fix-devmap_hash-overflow-check-on-32-bit-arches.patch | Revert "bpf: Fix DEVMAP_HASH overflow check on 32-bit arches" This reverts commit 225da02acdc97af01b6bc6ce1a3e5362bf01d3fb which is commit 281d464a34f540de166cee74b723e97ac2515ec3 upstream. Commit 225da02acdc9 ("bpf: fix DEVMAP_HASH overflow check on 32-bit architectures") relies on the v5.11+ base mechanism of memcg-based memory accounting[0], which is not yet supported on the 5.10 stable branch, so let's revert this commit in preparation for re-adapting it. |
Pu Lehui <pulehui@huawei.com> | no | 2024-09-27 | ||
| bugfix/powerpc/powerpc-boot-fix-missing-crc32poly.h-when-building-with-kernel_xz.patch | powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ After commit faa16bc404d7 ("lib: Use existing define with polynomial") the lib/xz/xz_crc32.c includes a header from include/linux directory thus any other user of this code should define proper include path. This fixes the build error on powerpc with CONFIG_KERNEL_XZ: In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0, from ../arch/powerpc/boot/decompress.c:42: ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory |
Krzysztof Kozlowski <krzk@kernel.org> | no | https://patchwork.ozlabs.org/patch/963258/ | 2018-08-29 | |
| bugfix/arm64/arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch | arm64/acpi: Add fixup for HPE m400 quirks Adds a new ACPI init routine acpi_fixup_m400_quirks that adds a work-around for HPE ProLiant m400 APEI firmware problems. The work-around disables APEI when CONFIG_ACPI_APEI is set and m400 firmware is detected. Without this fixup m400 systems experience errors like these on startup: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2 [Hardware Error]: event severity: fatal [Hardware Error]: Error 0, type: fatal [Hardware Error]: section_type: memory error [Hardware Error]: error_status: 0x0000000000001300 [Hardware Error]: error_type: 10, invalid address Kernel panic - not syncing: Fatal hardware error! [bwh: Adjust context to apply to Linux 4.19] |
Geoff Levand <geoff@infradead.org> | yes | 2018-06-13 | ||
| bugfix/x86/x86-32-disable-3dnow-in-generic-config.patch | x86-32: Disable 3D-Now in generic config We want the 686 flavour to run on Geode LX and similar AMD family 5 CPUs as well as family 6 and higher CPUs. This used to work with CONFIG_M686=y. However commit 25d76ac88821 "x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig" in Linux 4.16 has made the kernel require family 6 or higher. It looks like a sensible choice would be to enable CONFIG_MGEODE_LX and CONFIG_X86_GENERIC (for more generic optimisations), but this currently enables CONFIG_X86_USE_3D_NOW which will cause the kernel to crash on CPUs without the AMD-specific 3D-Now instructions. Make CONFIG_X86_USE_3DNOW depend on CONFIG_X86_GENERIC being disabled. |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-09-25 | ||
| bugfix/x86/platform-x86-toshiba_haps-Fix-missing-newline-in-pr_.patch | platform/x86: toshiba_haps: Fix missing newline in pr_debug call in toshiba_haps_notify The pr_debug() call in toshiba_haps_notify() is missing a newline at the end of the string, add this. |
Hans de Goede <hdegoede@redhat.com> | no | debian | https://git.kernel.org/linus/7dc4a18d017ca26abd1cea197e486fb3e5cd7632 | 2021-05-19 |
| bugfix/x86/input-goodix-use-the-new-soc_intel_is_byt-helper.patch | Input: goodix - use the new soc_intel_is_byt() helper commit d176708ffc20332d1c730098d2b111e0b77ece82 upstream. Use the new soc_intel_is_byt() helper from linux/platform_data/x86/soc.h. [Ricardo: Resolved minor cherry-pick conflict. The file linux/regulator/ consumer.h is not #included in the upstream version but it is in v5.10.y. ] |
Hans de Goede <hdegoede@redhat.com> | no | 2022-02-28 | ||
| bugfix/x86/powercap-rapl-fix-invalid-initialization-for-pl4_supported-field.patch | powercap: RAPL: fix invalid initialization for pl4_supported field commit d05b5e0baf424c8c4b4709ac11f66ab726c8deaf upstream. The current initialization of the struct x86_cpu_id via pl4_support_ids[] is partial and wrong. It is initializing "stepping" field with "X86_FEATURE_ANY" instead of "feature" field. Use X86_MATCH_INTEL_FAM6_MODEL macro instead of initializing each field of the struct x86_cpu_id for pl4_supported list of CPUs. This X86_MATCH_INTEL_FAM6_MODEL macro internally uses another macro X86_MATCH_VENDOR_FAM_MODEL_FEATURE for X86 based CPU matching with appropriate initialized values. [ Ricardo: I only kept TIGERLAKE in pl4_support_ids as only this model is enumerated before this changeset. ] |
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> | no | 2023-06-08 | ||
| bugfix/x86/x86-mm-switch-to-new-intel-cpu-model-defines.patch | x86/mm: Switch to new Intel CPU model defines commit 2eda374e883ad297bd9fe575a16c1dc850346075 upstream. New CPU #defines encode vendor and family as well as model. [ dhansen: vertically align 0's in invlpg_miss_ids[] ] [ Ricardo: I used the old match macro X86_MATCH_INTEL_FAM6_MODEL() instead of X86_MATCH_VFM() as in the upstream commit. I also kept the ALDERLAKE_N name instead of ATOM_GRACEMONT. Both refer to the same CPU model. ] |
Tony Luck <tony.luck@intel.com> | no | 2024-04-24 | ||
| features/arm64/arm64-dts-rockchip-Add-basic-support-for-Kobol-s-Hel.patch | arm64: dts: rockchip: Add basic support for Kobol's Helios64 The hardware is described in detail on Kobol's wiki at https://wiki.kobol.io/helios64/intro/. Up to now the following peripherals are working: - UART - Micro-SD card - eMMC - ethernet port 1 - status LED - temperature sensor on i2c bus 2 |
Uwe Kleine-König <uwe@kleine-koenig.org> | no | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=09e006cfb43e8ec38afe28278b210dab72e6cac8 | 2020-10-14 | |
| features/arm64/arm64-dts-rockchip-Rely-on-SoC-external-pull-up-on-p.patch | arm64: dts: rockchip: Rely on SoC external pull up on pmic-int-l on Helios64 According to the schematic there is an external pull up, so there is no need to enable the internal one additionally. Using no pull up matches the vendor device tree. |
Uwe Kleine-König <uwe@kleine-koenig.org> | no | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=1e58ba111421375c5948c3e8145bdd84b06ac095 | 2021-01-24 | |
| features/arm64/arm64-dts-rockchip-kobol-helios64-Add-mmc-aliases.patch | arm64: dts: rockchip: kobol-helios64: Add mmc aliases This patch is part of commit 5dcbe7e3862d ("arm64: dts: rockchip: move mmc aliases to board dts on rk3399") upstream. It is applied here only for Kobol's helios64 to simplify conflict resolution for some further patches. It currently is a noop as the same aliases already exist in rk3399.dtsi. |
Uwe Kleine-König <ukleinek@debian.org> | no | 2021-03-29 | ||
| features/arm64/arm64-dts-rockchip-Add-support-for-two-PWM-fans-on-h.patch | arm64: dts: rockchip: Add support for two PWM fans on helios64 On the helios64 board the two connectors P6 and P7 are supposed to power two fans. Add the corresponding pwm-fan devices. |
Uwe Kleine-König <uwe@kleine-koenig.org> | no | https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/patch/?id=271b66414df0b172c936b3cfd1894b7939f84165 | 2021-05-10 | |
| features/arm64/arm64-dts-rockchip-Add-support-for-PCIe-on-helios64.patch | arm64: dts: rockchip: Add support for PCIe on helios64 This is enough to make the SATA controller visible: # lspci 00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port 01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller |
Uwe Kleine-König <uwe@kleine-koenig.org> | no | https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/patch/?id=5a65adfa2ad1542f856fc7de3999d51f3a35d2e2 | 2021-05-10 | |
| features/arm64/arm64-dts-raspberry-Add-support-for-the-CM4.patch | arm64: dts: Add support for Raspberry Pi Compute Module 4 IO Board It was introduced in mainline during the v5.16 release cycle. Since many broadcom includes were reworked since v5.10, adding support would involve more than cherry-picking a DTS addition that uses a few includes. To avoid side effects on other models, introduce a DTS that leverages some existing includes (bcm2711.dtsi and bcm283x-rpi-usb-host.dtsi) and describes the rest without re-using parts of the Raspberry Pi 4 B model. To avoid phandle rotation (0x16, 0x17, and 0x18) across 3 nodes (dma@7e007000, i2c@7e205000, and interrupt-controller@7ef00100), and the related changes in other nodes referencing them, hardcode 0x16 as the phandle for interrupt-controller@7ef00100. This leads to an empty dtdiff between this new DTB and the one produced by a v5.16-rc8 build. |
Cyril Brulebois <cyril@debamax.com> | no | 2022-01-03 | ||
| features/arm64/arm64-compat-Implement-misalignment-fixups-for-multi.patch | arm64: compat: Implement misalignment fixups for multiword loads The 32-bit ARM kernel implements fixups on behalf of user space when using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit aligned. This is not something that is supported by the architecture, but was done anyway to increase compatibility with user space software, which mostly targeted x86 at the time and did not care about aligned accesses. This feature is one of the remaining impediments to being able to switch to 64-bit kernels on 64-bit capable hardware running 32-bit user space, so let's implement it for the arm64 compat layer as well. Note that the intent is to implement the exact same handling of misaligned multi-word loads and stores as the 32-bit kernel does, including what appears to be missing support for user space programs that rely on SETEND to switch to a different byte order and back. Also, like the 32-bit ARM version, we rely on the faulting address reported by the CPU to infer the memory address, instead of decoding the instruction fully to obtain this information. This implementation is taken from the 32-bit ARM tree, with all pieces removed that deal with instructions other than LDRD/STRD and LDM/STM, or that deal with alignment exceptions taken in kernel mode. [catalin.marinas@arm.com: change the option to 'default n'] |
Ard Biesheuvel <ardb@kernel.org> | no | https://git.kernel.org/linus/3fc24ef32d3b9368f4c103dcd21d6a3f959b4870 | 2022-07-01 | |
| features/x86/x86-memtest-WARN-if-bad-RAM-found.patch | x86: memtest: WARN if bad RAM found Since this is not a particularly thorough test, if we find any bad bits of RAM then there is a fair chance that there are other bad bits we fail to detect. |
Ben Hutchings <ben@decadent.org.uk> | yes | debian | 2011-12-05 | |
| features/x86/x86-make-x32-syscall-support-conditional.patch | x86: Make x32 syscall support conditional on a kernel parameter Enabling x32 in the standard amd64 kernel would increase its attack surface while provide no benefit to the vast majority of its users. No-one seems interested in regularly checking for vulnerabilities specific to x32 (at least no-one with a white hat). Still, adding another flavour just to turn on x32 seems wasteful. And the only differences on syscall entry are a few instructions that mask out the x32 flag and compare the syscall number. Use a static key to control whether x32 syscalls are really enabled, a Kconfig parameter to set its default value and a kernel parameter "syscall.x32" to change it at boot time. |
Ben Hutchings <ben@decadent.org.uk> | yes | debian | 2018-02-12 | |
| bugfix/all/disable-some-marvell-phys.patch | phy/marvell: disable 4-port phys The Marvell PHY was originally disabled because it can cause networking failures on some systems. According to Lennert Buytenhek this is because some of the variants added did not share the same register layout. Since the known cases are all 4-ports disable those variants (indicated by a 4 in the penultimate position of the model name) until they can be audited for correctness. [bwh: Also #if-out the init functions for these PHYs to avoid compiler warnings] |
Ian Campbell <ijc@hellion.org.uk> | yes | debian | 2013-11-20 | |
| bugfix/all/fs-add-module_softdep-declarations-for-hard-coded-cr.patch | fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers This helps initramfs builders and other tools to find the full dependencies of a module. [Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream] |
Ben Hutchings <ben@decadent.org.uk> | yes | debian | 2016-04-13 | |
| debian/makefile-do-not-check-for-libelf-when-building-oot-module.patch | Makefile: Do not check for libelf when building OOT module When building out-of-tree modules, the necessary tools should have already been built. We therefore do not need libelf-dev to be installed. This effectively reverts commit 9f0c18aec620 "objtool: Fix CONFIG_STACK_VALIDATION=y warning for out-of-tree modules", and similarly moves the check introduced by commit 33a57ce0a54d "bpf: Compile resolve_btfids tool at kernel compilation start". |
Ben Hutchings <ben@decadent.org.uk> | no | 2020-09-07 | ||
| features/all/lockdown/efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch | [28/30] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT flag that can be passed to efi_enabled() to find out whether secure boot is enabled. Move the switch-statement in x86's setup_arch() that inteprets the secure_boot boot parameter to generic code and set the bit there. [rperier: Forward-ported to 5.5: - Use pr_warn() - Adjust context] [bwh: Forward-ported to 5.6: adjust context] [bwh: Forward-ported to 5.7: - Use the next available bit in efi.flags - Adjust context] |
David Howells <dhowells@redhat.com> | no | https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit?id=a5d70c55c603233c192b375f72116a395909da28 | 2019-02-18 | |
| features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch | efi: Lock down the kernel if booted in secure boot mode Based on an earlier patch by David Howells, who wrote the following description: > UEFI Secure Boot provides a mechanism for ensuring that the firmware will > only load signed bootloaders and kernels. Certain use cases may also > require that all kernel modules also be signed. Add a configuration option > that to lock down the kernel - which includes requiring validly signed > modules - if the kernel is secure-booted. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-09-10 | ||
| features/all/lockdown/mtd-disable-slram-and-phram-when-locked-down.patch | mtd: phram,slram: Disable when the kernel is locked down These drivers allow mapping arbitrary memory ranges as MTD devices. This should be disabled to preserve the kernel's integrity when it is locked down. * Add the HWPARAM flag to the module parameters * When slram is built-in, it uses __setup() to read kernel parameters, so add an explicit check security_locked_down() check |
Ben Hutchings <ben@decadent.org.uk> | yes | 2019-08-30 | ||
| features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch | arm64: add kernel config option to lock down when in Secure Boot mode Add a kernel configuration option to lock down the kernel, to restrict userspace's ability to modify the running kernel when UEFI Secure Boot is enabled. Based on the x86 patch by Matthew Garrett. Determine the state of Secure Boot in the EFI stub and pass this to the kernel using the FDT. [bwh: Forward-ported to 4.10: adjust context] [Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream] [bwh: Forward-ported to 4.15 and lockdown patch set: - Pass result of efi_get_secureboot() in stub through to efi_set_secure_boot() in main kernel - Use lockdown API and naming] [bwh: Forward-ported to 4.19.3: adjust context in update_fdt()] [dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection] [bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this] [bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a sys_table parameter] [bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so: - Add Secure Boot mode to the parameter enumeration in fdtparams.c - Add a parameter to efi_get_fdt_params() to return the Secure Boot mode - Since Xen does not have a property name defined for Secure Boot mode, change efi_get_fdt_prop() to handle a missing property name by clearing the output variable] [Salvatore Bonaccorso: Forward-ported to 5.10: f30f242fb131 ("efi: Rename arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c] |
Linn Crosetto <linn@hpe.com> | no | debian | 2016-08-30 | |
| features/all/db-mok-keyring/0001-MODSIGN-do-not-load-mok-when-secure-boot-disabled.patch | [PATCH 1/5] MODSIGN: do not load mok when secure boot disabled The mok can not be trusted when the secure boot is disabled. Which means that the kernel embedded certificate is the only trusted key. Due to db/dbx are authenticated variables, they needs manufacturer's KEK for update. So db/dbx are secure when secureboot disabled. [Rebased by Luca Boccassi] [bwh: Forward-ported to 5.5.9: - get_cert_list() takes a pointer to status and returns the cert list - Adjust filename] [Salvatore Bonaccorso: Forward-ported to 5.10: Refresh for changes in 38a1f03aa240 ("integrity: Move import of MokListRT certs to a separate routine"). Refresh in context for change in ebd9c2ae369a ("integrity: Load mokx variables into the blacklist keyring")] |
"Lee, Chun-Yi" <joeyli.kernel@gmail.com> | no | https://lore.kernel.org/patchwork/patch/933173/ | 2018-03-13 | |
| features/all/db-mok-keyring/0003-MODSIGN-checking-the-blacklisted-hash-before-loading-a-kernel-module.patch | [PATCH 3/4] MODSIGN: checking the blacklisted hash before loading a kernel module This patch adds the logic for checking the kernel module's hash base on blacklist. The hash must be generated by sha256 and enrolled to dbx/mokx. For example: sha256sum sample.ko mokutil --mokx --import-hash $HASH_RESULT Whether the signature on ko file is stripped or not, the hash can be compared by kernel. [Rebased by Luca Boccassi] |
"Lee, Chun-Yi" <joeyli.kernel@gmail.com> | no | https://lore.kernel.org/patchwork/patch/933175/ | 2018-03-13 | |
| features/all/db-mok-keyring/0004-MODSIGN-check-the-attributes-of-db-and-mok.patch | [PATCH 4/4] MODSIGN: check the attributes of db and mok That's better for checking the attributes of db and mok variables before loading certificates to kernel keyring. For db and dbx, both of them are authenticated variables. Which means that they can only be modified by manufacturer's key. So the kernel should checks EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute before we trust it. For mok-rt and mokx-rt, both of them are created by shim boot loader to forward the mok/mokx content to runtime. They must be runtime-volatile variables. So kernel should checks that the attributes map did not set EFI_VARIABLE_NON_VOLATILE bit before we trust it. [Rebased by Luca Boccassi] [bwh: Forward-ported to 5.5.9: - get_cert_list() takes a pointer to status and returns the cert list - Adjust filename, context] [bwh: Forward-ported to 5.10: MokListRT and MokListXRT are now both loaded through a single code path.] |
"Lee, Chun-Yi" <joeyli.kernel@gmail.com> | no | https://lore.kernel.org/patchwork/patch/933176/ | 2018-03-13 | |
| features/all/db-mok-keyring/modsign-make-shash-allocation-failure-fatal.patch | MODSIGN: Make shash allocation failure fatal mod_is_hash_blacklisted() currently returns 0 (suceess) if crypto_alloc_shash() fails. This should instead be a fatal error, so unwrap and pass up the error code. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-05-05 | ||
| features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch | [PATCH] KEYS: Make use of platform keyring for module signature verify This patch completes commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify") which, while adding the platform keyring for bzImage verification, neglected to also add this keyring for module verification. As such, kernel modules signed with keys from the MokList variable were not successfully verified. |
Robert Holmes <robeholmes@gmail.com> | no | debian | https://src.fedoraproject.org/rpms/kernel/raw/master/f/KEYS-Make-use-of-platform-keyring-for-module-signature.patch | 2019-04-23 |
| debian/i386-686-pae-pci-set-pci-nobios-by-default.patch | [i386/686-pae] PCI: Set pci=nobios by default CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped W+X, which is undesirable for security reasons and will result in a warning at boot now that we enable CONFIG_DEBUG_WX. This can be overridden using the kernel parameter "pci=nobios", but we want to disable W+X by default. Disable PCI BIOS probing by default; it can still be enabled using "pci=bios". |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2016-02-16 | ||
| debian/ntfs-mark-it-as-broken.patch | ntfs: mark it as broken NTFS has unfixed issues CVE-2018-12929, CVE-2018-12930, and CVE-2018-12931. ntfs-3g is a better supported alternative. Make sure it can't be enabled even in custom kernels. |
Ben Hutchings <ben@decadent.org.uk> | no | 2019-04-25 | ||
| bugfix/all/vfs-move-cap_convert_nscap-call-into-vfs_setxattr.patch | vfs: move cap_convert_nscap() call into vfs_setxattr() cap_convert_nscap() does permission checking as well as conversion of the xattr value conditionally based on fs's user-ns. This is needed by overlayfs and probably other layered fs (ecryptfs) and is what vfs_foo() is supposed to do anyway. |
Miklos Szeredi <mszeredi@redhat.com> | no | https://git.kernel.org/linus/7c03e2cda4a584cadc398e8f6641ca9988a39d52 | 2020-12-14 | |
| bugfix/all/ovl-fail-on-invalid-uid-gid-mapping-at-copy-up.patch | ovl: fail on invalid uid/gid mapping at copy up If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then copy-up should fail, just like it would fail if the mounter task was doing the copy using "cp -a". There's a corner case where the "cp -a" would succeed but copy up fail: if there's a mapping of the invalid uid/gid (65534 by default) in the user namespace. This is because stat(2) will return this value if the mapping doesn't exist in the current user_ns and "cp -a" will in turn be able to create a file with this uid/gid. This behavior would be inconsistent with POSIX ACL's, which return -1 for invalid uid/gid which result in a failed copy. For consistency and simplicity fail the copy of the st_uid/st_gid are invalid. |
Miklos Szeredi <mszeredi@redhat.com> | no | https://git.kernel.org/linus/4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 | 2023-01-24 | |
| bugfix/all/module-disable-matching-missing-version-crc.patch | module: Disable matching missing version CRC This partly reverts commit cd3caefb4663e3811d37cc2afad3cce642d60061. We want to fail closed if a symbol version CRC is missing, as the alternative may allow subverting module signing. |
Ben Hutchings <ben@decadent.org.uk> | not-needed | 2016-12-02 | ||
| bugfix/all/usbip-document-tcp-wrappers.patch | usbip: Document TCP wrappers Add references to TCP wrappers configuration in the manual page. |
Ben Hutchings <ben@decadent.org.uk> | no | 2012-06-24 | ||
| bugfix/all/kbuild-fix-recordmcount-dependency.patch | kbuild: Fix recordmcount dependency for OOT modules We never rebuild anything in-tree when building an out-of-tree modules, so external modules should not depend on the recordmcount sources. |
Ben Hutchings <ben@decadent.org.uk> | no | 2014-09-08 | ||
| bugfix/all/tools-perf-man-date.patch | perf tools: Use $KBUILD_BUILD_TIMESTAMP as man page date This allows man pages to be built reproducibly. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2015-07-13 | ||
| bugfix/all/tools-perf-remove-shebangs.patch | tools/perf: Remove shebang lines from perf scripts perf scripts need to be invoked through perf, not directly through perl (or other language interpreter). So including shebang lines in them is useless and possibly misleading. |
Ben Hutchings <ben@decadent.org.uk> | no | 2015-09-25 | ||
| bugfix/x86/revert-perf-build-fix-libunwind-feature-detection-on.patch | Revert "perf build: Fix libunwind feature detection on 32-bit x86" This reverts commit 05b41775e2edd69a83f592e3534930c934d4038e. It broke feature detection that was working just fine for us. |
Ben Hutchings <ben@decadent.org.uk> | no | 2015-09-25 | ||
| bugfix/all/tools-build-remove-bpf-run-time-check-at-build-time.patch | tools/build: Remove bpf() run-time check at build time It is not correct to test that a syscall works on the build system's kernel. We might be building on an earlier kernel version or with security restrictions that block bpf(). |
Ben Hutchings <ben@decadent.org.uk> | no | 2016-02-21 | ||
| bugfix/all/cpupower-bump-soname-version.patch | cpupower: Bump soname version Several functions in the libcpupower API are renamed or removed in Linux 4.7. This is an backward-incompatible ABI change, so the library soname should change from libcpupower.so.0 to libcpupower.so.1. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2016-06-09 | ||
| bugfix/all/libcpupower-hide-private-function.patch | libcpupower: Hide private function cpupower_read_sysfs() (previously known as sysfs_read_file()) is an internal function in libcpupower and should not be exported when libcpupower is a shared library. Change its visibility to "hidden". |
Ben Hutchings <ben@decadent.org.uk> | no | 2018-12-01 | ||
| bugfix/all/cpupower-fix-checks-for-cpu-existence.patch | cpupower: Fix checks for CPU existence Calls to cpufreq_cpu_exists(cpu) were converted to cpupower_is_cpu_online(cpu) when libcpupower was introduced and the former function was deleted. However, cpupower_is_cpu_online() does not distinguish physically absent and offline CPUs, and does not set errno. cpufreq-set has already been fixed (commit c25badc9ceb6). In cpufreq-bench, which prints an error message for offline CPUs, properly distinguish and report the zero and negative cases. [carnil: Update/Refresh patch for 4.14.17: The issue with the incorrect check has been fixed with upstream commit 53d1cd6b125f. Keep in the patch the distinction and report for the zero and negative cases.] |
Ben Hutchings <ben@decadent.org.uk> | yes | 2016-11-03 | ||
| bugfix/all/tools-perf-pmu-events-fix-reproducibility.patch | tools/perf: pmu-events: Fix reproducibility jevents.c uses nftw() to enumerate files and outputs the corresponding C structs in the order they are found. This makes it sensitive to directory ordering, so that the perf executable is not reproducible. To avoid this, store all the files and directories found and then sort them by their (relative) path. (This maintains the parent-first ordering that nftw() promises.) Then apply the existing callbacks to them in the sorted order. Don't both storing the stat buffers as we don't need them. |
Ben Hutchings <ben@decadent.org.uk> | yes | 2019-08-25 | ||
| bugfix/all/bpftool-fix-version-string-in-recursive-builds.patch | bpftool: Fix version string in recursive builds When bpftool is built as part of a Debian package build, which itself uses make, "bpftool version" shows: bpftool vmake[4]: Entering directory /build/linux-5.8/tools/bpf/bpftool 5.8.8.0 make[4]: Leaving directory /build/linux-5.8 Although we pass the "--no-print-directory" option, this is overridden by the environment variable "MAKEFLAGS=w". Clear MAKEFLAGS for the "make kernelversion" command. I have no explanation for the doubled ".8" in the version string, but this seems to fix that as well. |
Ben Hutchings <benh@debian.org> | yes | 2020-08-14 | ||
| debian/overlayfs-permit-mounts-in-userns.patch | ovl: permit overlayfs mounts in user namespaces (taints kernel) Permit overlayfs mounts within user namespaces to allow utilisation of e.g. unprivileged LXC overlay snapshots. Except by the Ubuntu community [1], overlayfs mounts in user namespaces are expected to be a security risk [2] and thus are not enabled on upstream Linux kernels. For the non-Ubuntu users that have to stick to unprivileged overlay-based LXCs, this meant to patch and compile the kernel manually. Instead, adding the kernel tainting 'permit_mounts_in_userns' module parameter allows a kind of a user-friendly way to enable the feature. Testable with: sudo modprobe overlay permit_mounts_in_userns=1 sudo sysctl -w kernel.unprivileged_userns_clone=1 mkdir -p lower upper work mnt unshare --map-root-user --mount \ mount -t overlay none mnt \ -o lowerdir=lower,upperdir=upper,workdir=work [1]: Ubuntu allows unprivileged mounting of overlay filesystem https://lists.ubuntu.com/archives/kernel-team/2014-February/038091.html [2]: User namespaces + overlayfs = root privileges https://lwn.net/Articles/671641/ [bwh: Forward-ported to 5.6: adjust context] |
Nicolas Schier <nicolas@fjasle.eu> | no | 2018-11-19 |