| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| olpc-prefix-hack.patch | Hack prefix for OLPC This sucks, but it's better than what OFW was giving us. |
Colin Watson <cjwatson@debian.org> | no | 2014-01-13 | ||
| core-in-fs.patch | Write marker if core.img was written to filesystem The Debian bug reporting script includes a warning in this case. |
Colin Watson <cjwatson@debian.org> | no | 2014-01-13 | ||
| dpkg-version-comparison.patch | Improve handling of Debian kernel version numbers | Robert Millan <rmh@aybabtu.com> | not-needed | 2013-12-20 | ||
| grub-legacy-0-based-partitions.patch | Support running grub-probe in grub-legacy's update-grub | Colin Watson <cjwatson@debian.org> | not-needed | 2013-12-25 | ||
| disable-floppies.patch | Disable use of floppy devices An ugly kludge. Should this be merged upstream? |
Robert Millan | no | 2014-01-13 | ||
| grub.cfg-400.patch | Make grub.cfg world-readable if it contains no passwords | Colin Watson <cjwatson@debian.org> | no | 2014-01-13 | ||
| gfxpayload-keep-default.patch | Disable gfxpayload=keep by default Setting gfxpayload=keep has been known to cause efifb to be inappropriately enabled. In any case, with the current Linux kernel the result of this option is that early kernelspace will be unable to print anything to the console, so (for example) if boot fails and you end up dumped to an initramfs prompt, you won't be able to see anything on the screen. As such it shouldn't be enabled by default in Debian, no matter what kernel options are enabled. gfxpayload=keep is a good idea but rather ahead of its time ... |
Colin Watson <cjwatson@debian.org> | no | debian | 2013-12-25 | |
| install-stage2-confusion.patch | If GRUB Legacy is still around, tell packaging to ignore it | Colin Watson <cjwatson@debian.org> | not-needed | debian | 2021-09-24 | |
| mkrescue-efi-modules.patch | Build vfat into EFI boot images | Colin Watson <cjwatson@ubuntu.com> | yes | 2016-09-18 | ||
| mkconfig-loopback.patch | Handle filesystems loop-mounted on file images Improve prepare_grub_to_access_device to emit appropriate commands for such filesystems, and ignore them in Linux grub.d scripts. This is needed for Ubuntu's Wubi installation method. This patch isn't inherently Debian/Ubuntu-specific. losetup and /proc/mounts are Linux-specific, though, so we might need to refine this before sending it upstream. The changes to the Linux grub.d scripts might be better handled by integrating 10_lupin properly instead. |
Colin Watson <cjwatson@debian.org> | no | 2014-01-13 | ||
| restore-mkdevicemap.patch | Restore grub-mkdevicemap This is kind of a mess, requiring lots of OS-specific code to iterate over all possible devices. However, we use it in a number of scripts to discover devices and reimplementing those in terms of something else would be very complicated. |
Dimitri John Ledkov <dimitri.ledkov@canonical.com> | no | 2021-09-24 | ||
| gettext-quiet.patch | Silence error messages when translations are unavailable | Colin Watson <cjwatson@ubuntu.com> | yes | upstream | 2013-11-14 | |
| install-efi-fallback.patch | Fall back to non-EFI if booted using EFI but -efi is missing It may be possible, particularly in recovery situations, to be booted using EFI on x86 when only the i386-pc target is installed, or on ARM when only the arm-uboot target is installed. There's nothing actually stopping us installing i386-pc or arm-uboot from an EFI environment, and it's better than returning a confusing error. |
Steve McIntyre <93sam@debian.org> | no | 2019-05-24 | ||
| mkconfig-ubuntu-recovery.patch | "single" -> "recovery" when friendly-recovery is installed If configured with --enable-ubuntu-recovery, also set nomodeset for recovery mode, and disable 'set gfxpayload=keep' even if the system normally supports it. See https://launchpad.net/ubuntu/+spec/desktop-o-xorg-tools-and-processes. |
Stphane Graber <stgraber@ubuntu.com> | no | 2013-12-25 | ||
| install-locale-langpack.patch | Prefer translations from Ubuntu language packs if available | Colin Watson <cjwatson@ubuntu.com> | not-needed | 2013-12-25 | ||
| mkconfig-nonexistent-loopback.patch | Avoid getting confused by inaccessible loop device backing paths | Colin Watson <cjwatson@ubuntu.com> | no | 2021-09-24 | ||
| default-grub-d.patch | Read /etc/default/grub.d/*.cfg after /etc/default/grub | Colin Watson <cjwatson@ubuntu.com> | no | 2021-09-24 | ||
| blacklist-1440x900x32.patch | Blacklist 1440x900x32 from VBE preferred mode handling | Colin Watson <cjwatson@ubuntu.com> | no | 2013-11-14 | ||
| mkconfig-ubuntu-distributor.patch | Remove GNU/Linux from default distributor string for Ubuntu Ubuntu is called "Ubuntu", not "Ubuntu GNU/Linux". |
Harald Sitter <apachelogger@kubuntu.org> | not-needed | 2013-12-25 | ||
| linuxefi.patch | Add "linuxefi" loader which avoids ExitBootServices | Linn Crosetto <linn@hpe.com> | no | vendor, http://pkgs.fedoraproject.org/cgit/grub2.git/tree/grub2-linuxefi.patch | 2021-09-24 | |
| mkconfig-signed-kernel.patch | Generate configuration for signed UEFI kernels if available | Colin Watson <cjwatson@ubuntu.com> | no | 2013-12-25 | ||
| install-signed.patch | Install signed images if UEFI Secure Boot is enabled | Mathieu Trudel-Lapierre <cyphermox@ubuntu.com> | no | 2023-01-15 | ||
| wubi-no-windows.patch | Skip Windows os-prober entries on Wubi systems Since we're already being booted from the Windows boot loader, including entries that take us back to it mostly just causes confusion, and stops us from being able to hide the menu if there are no other OSes installed. https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-wubi |
Colin Watson <cjwatson@ubuntu.com> | not-needed | 2013-11-26 | ||
| maybe-quiet.patch | Add configure option to reduce visual clutter at boot time If this option is enabled, then do all of the following: Don't display introductory message about line editing unless we're actually offering a shell prompt. (This is believed to be a workaround for a different bug. We'll go with this for now, but will drop this in favour of a better fix upstream if somebody figures out what that is.) Don't clear the screen just before booting if we never drew the menu in the first place. Remove verbose messages printed before reading configuration. In some ways this is awkward because it makes debugging harder, but it's a requirement for a smooth-looking boot process; we may be able to do better in future. Upstream doesn't want this, though. Disable the cursor as well, for similar reasons of tidiness. Suppress kernel/initrd progress messages, except in recovery mode. Suppress "GRUB loading" message unless Shift is held down. Upstream doesn't want this, as it makes debugging harder. Ubuntu wants it to provide a cleaner boot experience. |
Will Thompson <will@willthompson.co.uk> | invalid | 2021-09-24 | ||
| install-efi-adjust-distributor.patch | Adjust efi_distributor for some distributions This is not a very good approach, and certainly not sanely upstreamable; we probably need to split GRUB_DISTRIBUTOR into a couple of different variables. |
Colin Watson <cjwatson@ubuntu.com> | not-needed | debian | 2019-08-06 | |
| quick-boot.patch | Add configure option to bypass boot menu if possible If other operating systems are installed, then automatically unhide the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if available to check whether Shift is pressed. If it is, show the menu, otherwise boot immediately. If keystatus is not available, then fall back to a short delay interruptible with Escape. This may or may not remain Ubuntu-specific, although it's not obviously wanted upstream. It implements a requirement of https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader. If the previous boot failed (defined as failing to get to the end of one of the normal runlevels), then show the boot menu regardless. |
Robie Basak <robie.basak@ubuntu.com> | no | 2015-09-04 | ||
| quick-boot-lvm.patch | If we don't have writable grubenv and we're on EFI, always show the menu If we don't have writable grubenv, recordfail doesn't work, which means our quickboot behavior - with a timeout of 0 - leaves the user without a reliable way to access the boot menu if they're on UEFI, because unlike BIOS, UEFI does not support checking the state of modifier keys (i.e. holding down shift at boot is not detectable). Handle this corner case by always using a non-zero timeout on EFI when save_env doesn't work. Reuse GRUB_RECORDFAIL_TIMEOUT to avoid introducing another variable. |
Steve Langasek <steve.langasek@ubuntu.com> | no | 2019-06-24 | ||
| gfxpayload-dynamic.patch | Add configure option to enable gfxpayload=keep dynamically Set GRUB_GFXPAYLOAD_LINUX=keep unless it's known to be unsupported on the current hardware. See https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer. |
Colin Watson <cjwatson@ubuntu.com> | no | 2019-05-25 | ||
| vt-handoff.patch | Add configure option to use vt.handoff=7 This is used for non-recovery Linux entries only; it enables flicker-free booting if gfxpayload=keep is in use and a suitable kernel is present. |
Andy Whitcroft <apw@canonical.com> | not-needed | 2013-12-25 | ||
| probe-fusionio.patch | Probe FusionIO devices | Colin Watson <cjwatson@ubuntu.com> | no | 2016-09-18 | ||
| ignore-grub_func_test-failures.patch | Ignore functional test failures for now as they are broken | Colin Watson <cjwatson@debian.org> | not-needed | 2013-11-19 | ||
| mkconfig-recovery-title.patch | Add GRUB_RECOVERY_TITLE option This allows the controversial "recovery mode" text to be customised. |
Colin Watson <cjwatson@ubuntu.com> | no | 2013-12-25 | ||
| install-powerpc-machtypes.patch | Port yaboot logic for various powerpc machine types Some powerpc machines require not updating the NVRAM. This can be handled by existing grub-install command-line options, but it's friendlier to detect this automatically. On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This is possibly suitable for other machines too, but that needs to be verified.) |
Colin Watson <cjwatson@debian.org> | no | 2014-10-15 | ||
| ieee1275-clear-reset.patch | Include a text attribute reset in the clear command for ppc Always clear text attribute for clear command in order to avoid problems after it boots. * grub-core/term/terminfo.c: Add escape for text attribute reset |
Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> | no | other, https://lists.gnu.org/archive/html/grub-devel/2014-09/msg00076.html | 2014-09-26 | |
| ppc64el-disable-vsx.patch | Disable VSX instruction VSX bit is enabled by default for Power7 and Power8 CPU models, so we need to disable them in order to avoid instruction exceptions. Kernel will activate it when necessary. * grub-core/kern/powerpc/ieee1275/startup.S: Disable VSX. |
Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> | no | other, https://lists.gnu.org/archive/html/grub-devel/2014-09/msg00078.html | 2015-01-27 | |
| grub-install-pvxen-paths.patch | grub-install: Install PV Xen binaries into the upstream specified path Upstream have defined a specification for where guests ought to place their xenpv grub binaries in order to facilitate chainloading from a stage 1 grub loaded from dom0. http://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html The spec calls for installation into /boot/xen/pvboot-i386.elf or /boot/xen/pvboot-x86_64.elf. |
Ian Campbell <ijc@hellion.org.uk> | yes | debian | 2014-10-24 | |
| insmod-xzio-and-lzopio-on-xen.patch | Arrange to insmod xzio and lzopio when booting a kernel as a Xen guest This is needed in case the Linux kernel is compiled with CONFIG_KERNEL_XZ or CONFIG_KERNEL_LZO rather than CONFIG_KERNEL_GZ (gzio is already loaded by grub.cfg today). |
Ian Campbell <ijc@debian.org> | yes | debian | 2014-11-30 | |
| grub-install-extra-removable.patch | Add support for forcing EFI installation to the removable media path Add an extra option to grub-install "--force-extra-removable". On EFI platforms, this will cause an extra copy of the grub-efi image to be written to the appropriate removable media patch /boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken UEFI implementations where the firmware does not work when configured with new boot paths. |
Steve McIntyre <93sam@debian.org> | invalid | debian | 2021-09-24 | |
| mkconfig-other-inits.patch | Generate alternative init entries in advanced menu Add fallback boot entries for alternative installed init systems. Based on patches from Michael Biebl and Didier Roche. |
Colin Watson <cjwatson@debian.org> | no | debian | 2017-06-23 | |
| zpool-full-device-name.patch | Tell zpool to emit full device names zfs-initramfs currently provides extraneous, undesired symlinks to devices directly underneath /dev/ to satisfy zpool's historical output of unqualified device names. By including this environment variable to signal our intent to zpool, zfs-linux packages can drop the symlink behavior when updating to its upstream or backported output behavior. |
Chad MILLER <chad.miller@canonical.com> | yes | debian upstream | 2016-11-01 | |
| net-read-bracketed-ipv6-addr.patch | net: read bracketed ipv6 addrs and port numbers Allow specifying port numbers for http and tftp paths, and allow ipv6 addresses to be recognized with brackets around them, which is required to specify a port number |
Aaron Miller <aaronmiller@fb.com> | no | 2021-09-24 | ||
| bootp-new-net_bootp6-command.patch | bootp: New net_bootp6 command Implement new net_bootp6 command for IPv6 network auto configuration via the DHCPv6 protocol (RFC3315). |
Michael Chang <mchang@suse.com> | no | 2021-09-24 | ||
| efinet-uefi-ipv6-pxe-support.patch | efinet: UEFI IPv6 PXE support When grub2 image is booted from UEFI IPv6 PXE, the DHCPv6 Reply packet is cached in firmware buffer which can be obtained by PXE Base Code protocol. The network interface can be setup through the parameters in that obtained packet. |
Michael Chang <mchang@suse.com> | no | 2016-10-27 | ||
| bootp-process-dhcpack-http-boot.patch | bootp: Add processing DHCPACK packet from HTTP Boot The vendor class identifier with the string "HTTPClient" is used to denote the packet as responding to HTTP boot request. In DHCP4 config, the filename for HTTP boot is the URL of the boot file while for PXE boot it is the path to the boot file. As a consequence, the next-server becomes obseleted because the HTTP URL already contains the server address for the boot file. For DHCP6 config, there's no difference definition in existing config as dhcp6.bootfile-url can be used to specify URL for both HTTP and PXE boot file. This patch adds processing for "HTTPClient" vendor class identifier in DHCPACK packet by treating it as HTTP format, not as the PXE format. |
Michael Chang <mchang@suse.com> | no | 2021-09-24 | ||
| efinet-set-network-from-uefi-devpath.patch | efinet: Setting network from UEFI device path The PXE Base Code protocol used to obtain cached PXE DHCPACK packet is no longer provided for HTTP Boot. Instead, we have to get the HTTP boot information from the device path nodes defined in following UEFI Specification sections. 9.3.5.12 IPv4 Device Path 9.3.5.13 IPv6 Device Path 9.3.5.23 Uniform Resource Identifiers (URI) Device Path This patch basically does: include/grub/efi/api.h: Add new structure of Uniform Resource Identifiers (URI) Device Path grub-core/net/drivers/efi/efinet.c: Check if PXE Base Code is available, if not it will try to obtain the netboot information from the device path where the image booted from. The DHCPACK packet is recoverd from the information in device patch and feed into the same DHCP packet processing functions to ensure the network interface is setting up the same way it used to be. |
Michael Chang <mchang@suse.com> | no | 2016-10-27 | ||
| efinet-set-dns-from-uefi-proto.patch | efinet: Setting DNS server from UEFI protocol In the URI device path node, any name rahter than address can be used for looking up the resources so that DNS service become needed to get answer of the name's address. Unfortunately the DNS is not defined in any of the device path nodes so that we use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain it. These two protcols are defined the sections of UEFI specification. 27.5 EFI IPv4 Configuration II Protocol 27.7 EFI IPv6 Configuration Protocol include/grub/efi/api.h: Add new structure and protocol UUID of EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL. grub-core/net/drivers/efi/efinet.c: Use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain the list of DNS server address for IPv4 and IPv6 respectively. The address of DNS servers is structured into DHCPACK packet and feed into the same DHCP packet processing functions to ensure the network interface is setting up the same way it used to be. |
Michael Chang <mchang@suse.com> | no | 2021-09-24 | ||
| fix-lockdown.patch | Do not overwrite sentinel byte in boot_params, breaks lockdown grub currently copies the entire boot_params, which includes setting sentinel byte to 0xff, which triggers sanitize_boot_params in the kernel which in turn clears various boot_params variables, including the indication that the bootloader chain is verified and thus the kernel disables lockdown mode. According to the information on the Fedora bug tracker, only the information from byte 0x1f1 is necessary, so start copying from there instead. |
Luca Boccassi <bluca@debian.org> | no | 2018-05-15 | ||
| skip-grub_cmd_set_date.patch | Skip flaky grub_cmd_set_date test | Colin Watson <cjwatson@debian.org> | no | debian | 2018-10-28 | |
| bash-completion-drop-have-checks.patch | bash-completion: Drop "have" checks These don't work with and aren't needed by dynamically-loaded completions. |
Colin Watson <cjwatson@debian.org> | no | debian | 2018-11-16 | |
| at_keyboard-module-init.patch | at_keyboard: initialize keyboard in module init if keyboard is ready The change in 0c62a5b2 caused at_keyboard to fail on some machines. Immediately initializing the keyboard in the module init if the keyboard is ready makes the problem go away. |
Jeroen Dekkers <jeroen@dekkers.ch> | no | debian | 2019-02-09 | |
| uefi-secure-boot-cryptomount.patch | Fix setup on Secure Boot systems where cryptodisk is in use On full-encrypted systems, including /boot, the current code omits cryptodisk commands needed to open the drives if Secure Boot is enabled. This prevents grub2 from reading any further configuration residing on the encrypted disk. This patch fixes this issue by adding the needed "cryptomount" commands in the load.cfg file that is then copied in the EFI partition. |
=?UTF-8?q?Herv=C3=A9=20Werner?= <dud225@hotmail.com> | no | debian | 2019-02-10 | |
| efi-variable-storage-minimise-writes.patch | Minimise writes to EFI variable storage Some UEFI firmware is easily provoked into running out of space in its variable storage. This is usually due to certain kernel drivers (e.g. pstore), but regardless of the cause it can cause grub-install to fail because it currently asks efibootmgr to delete and re-add entries, and the deletion often doesn't result in an immediate garbage collection. Writing variables frequently also increases wear on the NVRAM which may have limited write cycles. For these reasons, it's desirable to find a way to minimise writes while still allowing grub-install to ensure that a suitable boot entry exists. Unfortunately, efibootmgr doesn't offer an interface that would let grub-install do this. It doesn't in general make very much effort to minimise writes; it doesn't allow modifying an existing Boot* variable entry, except in certain limited ways; and current versions don't have a way to export the expected variable data so that grub-install can compare it to the current data. While it would be possible (and perhaps desirable?) to add at least some of this to efibootmgr, that would still leave the problem that there isn't a good upstreamable way for grub-install to guarantee that it has a new enough version of efibootmgr. In any case, it's cumbersome and slow for grub-install to have to fork efibootmgr to get things done. Fortunately, a few years ago Peter Jones helpfully factored out a substantial part of efibootmgr to the efivar and efiboot libraries, and so it's now possible to have grub-install use those directly. We still have to use some code from efibootmgr, but much less than would previously have been necessary. grub-install now reuses existing boot entries where possible, and avoids writing to variables when the new contents are the same as the old contents. In the common upgrade case where nothing needs to change, it no longer writes to NVRAM at all. It's also now slightly faster, since using libefivar is faster than forking efibootmgr. Fixes Debian bug #891434. |
Colin Watson <cjwatson@ubuntu.com> | yes | debian | 2019-03-23 | |
| grub-install-removable-shim.patch | Deal with --force-extra-removable with signed shim too In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI and signed Grub as /EFI/BOOT/grubXXX.efi. Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into /EFI/BOOT/ so that it can work when needed (*iff* we're updating the NVRAM). [cjwatson: Refactored also_install_removable somewhat for brevity and so that we're using consistent case-insensitive logic.] |
Steve McIntyre <93sam@debian.org> | no | debian | 2021-09-24 | |
| dejavu-font-path.patch | add /u/s/fonts/truetype/dejavu to the DejaVu fonts search paths | Fabian Greffrath <fabian@greffrath.com> | no | 2020-05-19 | ||
| xen-no-xsm-policy-in-non-xsm-options.patch | 20_linux_xen: Do not load XSM policy in non-XSM options For complicated reasons, even if you have XSM/FLASK disabled (as is the default) the Xen build system still builds a policy file and puts it in /boot. Even so, we shouldn't be loading this in the usual non-"XSM enabled" entries. It doesn't do any particular harm but it is quite confusing. |
Ian Jackson <ian.jackson@eu.citrix.com> | no | debian | 2020-05-29 | |
| pc-verifiers-module.patch | i386-pc: build verifiers API as module Given no core functions on i386-pc would require verifiers to work and the only consumer of the verifier API is the pgp module, it looks good to me that we can move the verifiers out of the kernel image and let moddep.lst to auto-load it when pgp is loaded on i386-pc platform. This helps to reduce the size of core image and thus can relax the tension of exploding on some i386-pc system with very short MBR gap size. See also a very comprehensive summary from Colin [1] about the details. [1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00240.html V2: Drop COND_NOT_i386_pc and use !COND_i386_pc. Add comment in kern/verifiers.c to help understanding what's going on without digging into the commit history. |
Michael Chang <mchang@suse.com> | no | debian | other, https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html | 2021-09-24 |
| debug_verifiers.patch | Add debug to display what's going on with verifiers | Steve McIntyre <93sam@debian.org> | no | 2021-04-17 | ||
| mkimage-fix-section-sizes.patch | util/mkimage: Some fixes to PE binaries section size calculation Commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper) added a helper function to setup PE sections, but it caused regressions in some arches where the natural alignment lead to wrong section sizes. This patch fixes a few things that were caused the section sizes to be calculated wrongly. These fixes are: * Only align the virtual memory addresses but not the raw data offsets. * Use aligned sizes for virtual memory sizes but not for raw data sizes. * Always align the sizes to set the virtual memory sizes. These seems to not cause problems for x64 and aa64 EFI platforms but was a problem for ia64. Because the size of the ".data" and "mods" sections were wrong and didn't have the correct content. Which lead to GRUB not being able to load any built-in module. |
Javier Martinez Canillas <javierm@redhat.com> | no | debian | 2021-04-16 | |
| tpm-unknown-error-non-fatal.patch | tpm: Pass unknown error as non-fatal, but debug print the error we got | Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com> | no | debian | 2021-09-24 | |
| xfs-fix-v4-superblock.patch | fs/xfs: Fix unreadable filesystem with v4 superblock The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support) introduced the bigtime support by adding some features in v3 inodes. This change extended grub_xfs_inode struct by 76 bytes but also changed the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes XFS_V2_INODE_SIZE becomes 16 bytes too small. As a result, the data structures aren't properly aligned and the GRUB generates "attempt to read or write outside of partition" errors when trying to read the XFS filesystem: GNU GRUB version 2.11 .... grub> set debug=efi,gpt,xfs grub> insmod part_gpt grub> ls (hd0,gpt1)/ partmap/gpt.c:93: Read a valid GPT header partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840 error: attempt to read or write outside of partition. This commit change the XFS_V2_INODE_SIZE computation by subtracting 76 bytes instead of 92 bytes from the actual size of grub_xfs_inode struct. This 76 bytes value comes from added members: 20 grub_uint8_t unused5 1 grub_uint64_t flags2 48 grub_uint8_t unused6 This patch explicitly splits the v2 and v3 parts of the structure. The unused4 is still ending of the v2 structures and the v3 starts at unused5. Thanks to this we will avoid future corruptions of v2 or v3 inodes. The XFS_V2_INODE_SIZE is returning to its expected size and the filesystem is back to a readable state: GNU GRUB version 2.11 .... grub> set debug=efi,gpt,xfs grub> insmod part_gpt grub> ls (hd0,gpt1)/ partmap/gpt.c:93: Read a valid GPT header partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (131) - 64, 768 efi/ fs/xfs.c:515: Reading inode (3145856) - 1464904, 0 grub2/ fs/xfs.c:515: Reading inode (132) - 64, 1024 grub/ fs/xfs.c:515: Reading inode (139) - 64, 2816 grub> |
Erwan Velu <erwanaliasr1@gmail.com> | no | upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a4b495520e4dc41a896a8b916a64eda9970c50ea | 2021-09-24 | |
| tests-ahci-update-qemu-device-name.patch | tests/ahci: Change "ide-drive" deprecated QEMU device name to "ide-hd" The "ide-drive" device was removed in QEMU 6.0. The "ide-hd" has been available for more than 10 years now in QEMU. Thus there shouldn't be any need for backwards compatible names. |
Marius Bakke <marius@gnu.org> | no | upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=aaea244a6ddd1e35aed60a5c7a08ddc41f51805b | 2021-09-24 | |
| minilzo-2.10.patch | minilzo: Update to minilzo-2.10 minilzo fails to build on a number of Debian release architectures (armel, mips64el, mipsel, ppc64el) with errors such as: ../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16': ../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 3479 | * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 'LZO_MEMOPS_COPY2' 3530 | LZO_MEMOPS_COPY2(&v, ss); | ^~~~~~~~~~~~~~~~ The latest upstream version is 2.10, so updating to it seems like a good idea on general principles, and it fixes builds on all the above architectures. The update procedure documented in the GRUB Developers Manual worked; I just updated the version numbers to make it clear that it's been executed recently. |
Colin Watson <cjwatson@debian.org> | yes | 2021-11-29 | ||
| 0063-loader-efi-chainloader-Simplify-the-loader-state.patch | loader/efi/chainloader: Simplify the loader state The chainloader command retains the source buffer and device path passed to LoadImage(), requiring the unload hook passed to grub_loader_set() to free them. It isn't required to retain this state though - they aren't required by StartImage() or anything else in the boot hook, so clean them up before grub_cmd_chainloader() finishes. |
Chris Coulson <chris.coulson@canonical.com> | no | 2022-04-05 | ||
| 0064-commands-boot-Add-API-to-pass-context-to-loader.patch | commands/boot: Add API to pass context to loader Loaders rely on global variables for saving context which is consumed in the boot hook and freed in the unload hook. In the case where a loader command is executed twice, calling grub_loader_set a second time executes the unload hook, but in some cases this runs when the loader's global context has already been updated, resulting in the updated context being freed and potential use-after-free bugs when the boot hook is subsequently called. This adds a new API (grub_loader_set_ex) which allows a loader to specify context that is passed to its boot and unload hooks. This is an alternative to requiring that loaders call grub_loader_unset before mutating their global context. (cherry picked from commit 4322a64dde7e8fedb58e50b79408667129d45dd3) |
Chris Coulson <chris.coulson@canonical.com> | no | 2022-04-29 | ||
| 0065-loader-efi-chainloader-Use-grub_loader_set_ex.patch | loader/efi/chainloader: Use grub_loader_set_ex() This ports the EFI chainloader to use grub_loader_set_ex() in order to fix a use-after-free bug that occurs when grub_cmd_chainloader() is executed more than once before a boot attempt is performed. |
Chris Coulson <chris.coulson@canonical.com> | no | 2022-04-05 | ||
| 0066-kern-efi-sb-Reject-non-kernel-files-in-the-shim_lock.patch | kern/efi/sb: Reject non-kernel files in the shim_lock verifier We must not allow other verifiers to pass things like the GRUB modules. Instead of maintaining a blocklist, maintain an allowlist of things that we do not care about. This allowlist really should be made reusable, and shared by the lockdown verifier, but this is the minimal patch addressing security concerns where the TPM verifier was able to mark modules as verified (or the OpenPGP verifier for that matter), when it should not do so on shim-powered secure boot systems. |
Julian Andres Klode <julian.klode@canonical.com> | no | 2021-12-02 | ||
| 0067-kern-file-Do-not-leak-device_name-on-error-in-grub_f.patch | kern/file: Do not leak device_name on error in grub_file_open() If we have an error in grub_file_open() before we free device_name, we will leak it. Free device_name in the error path and null out the pointer in the good path once we free it there. |
Daniel Axtens <dja@axtens.net> | no | 2021-06-25 | ||
| 0068-video-readers-png-Abort-sooner-if-a-read-operation-f.patch | video/readers/png: Abort sooner if a read operation fails Fuzzing revealed some inputs that were taking a long time, potentially forever, because they did not bail quickly upon encountering an I/O error. Try to catch I/O errors sooner and bail out. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-06 | ||
| 0069-video-readers-png-Refuse-to-handle-multiple-image-he.patch | video/readers/png: Refuse to handle multiple image headers This causes the bitmap to be leaked. Do not permit multiple image headers. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-06 | ||
| 0070-video-readers-png-Drop-greyscale-support-to-fix-heap.patch | video/readers/png: Drop greyscale support to fix heap out-of-bounds write A 16-bit greyscale PNG without alpha is processed in the following loop: for (i = 0; i < (data->image_width * data->image_height); i++, d1 += 4, d2 += 2) { d1[R3] = d2[1]; d1[G3] = d2[1]; d1[B3] = d2[1]; } The increment of d1 is wrong. d1 is incremented by 4 bytes per iteration, but there are only 3 bytes allocated for storage. This means that image data will overwrite somewhat-attacker-controlled parts of memory - 3 bytes out of every 4 following the end of the image. This has existed since greyscale support was added in 2013 in commit 3ccf16dff98f (grub-core/video/readers/png.c: Support grayscale). Saving starfield.png as a 16-bit greyscale image without alpha in the gimp and attempting to load it causes grub-emu to crash - I don't think this code has ever worked. Delete all PNG greyscale support. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-06 | ||
| 0071-video-readers-png-Avoid-heap-OOB-R-W-inserting-huff-.patch | video/readers/png: Avoid heap OOB R/W inserting huff table items In fuzzing we observed crashes where a code would attempt to be inserted into a huffman table before the start, leading to a set of heap OOB reads and writes as table entries with negative indices were shifted around and the new code written in. Catch the case where we would underflow the array and bail. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-06 | ||
| 0072-video-readers-png-Sanity-check-some-huffman-codes.patch | video/readers/png: Sanity check some huffman codes ASAN picked up two OOB global reads: we weren't checking if some code values fit within the cplens or cpdext arrays. Check and throw an error if not. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-06 | ||
| 0073-video-readers-jpeg-Abort-sooner-if-a-read-operation-.patch | video/readers/jpeg: Abort sooner if a read operation fails Fuzzing revealed some inputs that were taking a long time, potentially forever, because they did not bail quickly upon encountering an I/O error. Try to catch I/O errors sooner and bail out. |
Daniel Axtens <dja@axtens.net> | no | 2021-06-28 | ||
| 0074-video-readers-jpeg-Do-not-reallocate-a-given-huff-ta.patch | video/readers/jpeg: Do not reallocate a given huff table Fix a memory leak where an invalid file could cause us to reallocate memory for a huffman table we had already allocated memory for. |
Daniel Axtens <dja@axtens.net> | no | 2021-06-28 | ||
| 0075-video-readers-jpeg-Refuse-to-handle-multiple-start-o.patch | video/readers/jpeg: Refuse to handle multiple start of streams An invalid file could contain multiple start of stream blocks, which would cause us to reallocate and leak our bitmap. Refuse to handle multiple start of streams. Additionally, fix a grub_error() call formatting. |
Daniel Axtens <dja@axtens.net> | no | 2021-06-28 | ||
| 0076-video-readers-jpeg-Block-int-underflow-wild-pointer-.patch | video/readers/jpeg: Block int underflow -> wild pointer write Certain 1 px wide images caused a wild pointer write in grub_jpeg_ycrcb_to_rgb(). This was caused because in grub_jpeg_decode_data(), we have the following loop: for (; data->r1 < nr1 && (!data->dri || rst); data->r1++, data->bitmap_ptr += (vb * data->image_width - hb * nc1) * 3) We did not check if vb * width >= hb * nc1. On a 64-bit platform, if that turns out to be negative, it will underflow, be interpreted as unsigned 64-bit, then be added to the 64-bit pointer, so we see data->bitmap_ptr jump, e.g.: 0x6180_0000_0480 to 0x6181_0000_0498 ^ ~--- carry has occurred and this pointer is now far away from any object. On a 32-bit platform, it will decrement the pointer, creating a pointer that won't crash but will overwrite random data. Catch the underflow and error out. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-07 | ||
| 0077-normal-charset-Fix-array-out-of-bounds-formatting-un.patch | normal/charset: Fix array out-of-bounds formatting unicode for display In some cases attempting to display arbitrary binary strings leads to ASAN splats reading the widthspec array out of bounds. Check the index. If it would be out of bounds, return a width of 1. I don't know if that's strictly correct, but we're not really expecting great display of arbitrary binary data, and it's certainly not worse than an OOB read. |
Daniel Axtens <dja@axtens.net> | no | 2021-07-13 | ||
| 0078-net-netbuff-Block-overly-large-netbuff-allocs.patch | net/netbuff: Block overly large netbuff allocs A netbuff shouldn't be too huge. It's bounded by MTU and TCP segment reassembly. This helps avoid some bugs (and provides a spot to instrument to catch them at their source). |
Daniel Axtens <dja@axtens.net> | no | 2022-03-08 | ||
| 0079-net-ip-Do-IP-fragment-maths-safely.patch | net/ip: Do IP fragment maths safely This avoids an underflow and subsequent unpleasantness. |
Daniel Axtens <dja@axtens.net> | no | 2021-12-20 | ||
| 0080-net-dns-Fix-double-free-addresses-on-corrupt-DNS-res.patch | net/dns: Fix double-free addresses on corrupt DNS response grub_net_dns_lookup() takes as inputs a pointer to an array of addresses ("addresses") for the given name, and pointer to a number of addresses ("naddresses"). grub_net_dns_lookup() is responsible for allocating "addresses", and the caller is responsible for freeing it if "naddresses" > 0. The DNS recv_hook will sometimes set and free the addresses array, for example if the packet is too short: if (ptr + 10 >= nb->tail) { if (!*data->naddresses) grub_free (*data->addresses); grub_netbuff_free (nb); return GRUB_ERR_NONE; } Later on the nslookup command code unconditionally frees the "addresses" array. Normally this is fine: the array is either populated with valid data or is NULL. But in these sorts of error cases it is neither NULL nor valid and we get a double-free. Only free "addresses" if "naddresses" > 0. It looks like the other use of grub_net_dns_lookup() is not affected. |
Daniel Axtens <dja@axtens.net> | no | 2021-09-16 | ||
| 0081-net-dns-Don-t-read-past-the-end-of-the-string-we-re-.patch | net/dns: Don't read past the end of the string we're checking against I don't really understand what's going on here but fuzzing found a bug where we read past the end of check_with. That's a C string, so use grub_strlen() to make sure we don't overread it. |
Daniel Axtens <dja@axtens.net> | no | 2021-12-20 | ||
| 0082-net-tftp-Prevent-a-UAF-and-double-free-from-a-failed.patch | net/tftp: Prevent a UAF and double-free from a failed seek A malicious tftp server can cause UAFs and a double free. An attempt to read from a network file is handled by grub_net_fs_read(). If the read is at an offset other than the current offset, grub_net_seek_real() is invoked. In grub_net_seek_real(), if a backwards seek cannot be satisfied from the currently received packets, and the underlying transport does not provide a seek method, then grub_net_seek_real() will close and reopen the network protocol layer. For tftp, the ->close() call goes to tftp_close() and frees the tftp_data_t file->data. The file->data pointer is not nulled out after the free. If the ->open() call fails, the file->data will not be reallocated and will continue point to a freed memory block. This could happen from a server refusing to send the requisite ack to the new tftp request, for example. The seek and the read will then fail, but the grub_file continues to exist: the failed seek does not necessarily cause the entire file to be thrown away (e.g. where the file is checked to see if it is gzipped/lzio/xz/etc., a read failure is interpreted as a decompressor passing on the file, not as an invalidation of the entire grub_file_t structure). This means subsequent attempts to read or seek the file will use the old file->data after free. Eventually, the file will be close()d again and file->data will be freed again. Mark a net_fs file that doesn't reopen as broken. Do not permit read() or close() on a broken file (seek is not exposed directly to the file API - it is only called as part of read, so this blocks seeks as well). As an additional defence, null out the ->data pointer if tftp_open() fails. That would have lead to a simple null pointer dereference rather than a mess of UAFs. This may affect other protocols, I haven't checked. |
Daniel Axtens <dja@axtens.net> | no | 2021-09-20 | ||
| 0083-net-tftp-Avoid-a-trivial-UAF.patch | net/tftp: Avoid a trivial UAF Under tftp errors, we print a tftp error message from the tftp header. However, the tftph pointer is a pointer inside nb, the netbuff. Previously, we were freeing the nb and then dereferencing it. Don't do that, use it and then free it later. This isn't really _bad_ per se, especially as we're single-threaded, but it trips up fuzzers. |
Daniel Axtens <dja@axtens.net> | no | 2022-01-18 | ||
| 0084-net-http-Do-not-tear-down-socket-if-it-s-already-bee.patch | net/http: Do not tear down socket if it's already been torn down It's possible for data->sock to get torn down in tcp error handling. If we unconditionally tear it down again we will end up doing writes to an offset of the NULL pointer when we go to tear it down again. Detect if it has been torn down and don't do it again. |
Daniel Axtens <dja@axtens.net> | no | 2022-03-01 | ||
| 0085-net-http-Fix-OOB-write-for-split-http-headers.patch | net/http: Fix OOB write for split http headers GRUB has special code for handling an http header that is split across two packets. The code tracks the end of line by looking for a "\n" byte. The code for split headers has always advanced the pointer just past the end of the line, whereas the code that handles unsplit headers does not advance the pointer. This extra advance causes the length to be one greater, which breaks an assumption in parse_line(), leading to it writing a NUL byte one byte past the end of the buffer where we reconstruct the line from the two packets. It's conceivable that an attacker controlled set of packets could cause this to zero out the first byte of the "next" pointer of the grub_mm_region structure following the current_line buffer. Do not advance the pointer in the split header case. |
Daniel Axtens <dja@axtens.net> | no | 2022-03-08 | ||
| 0086-net-http-Error-out-on-headers-with-LF-without-CR.patch | net/http: Error out on headers with LF without CR In a similar vein to the previous patch, parse_line() would write a NUL byte past the end of the buffer if there was an HTTP header with a LF rather than a CRLF. RFC-2616 says: Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6). We don't support quoted sections or continuation lines, etc. If we see an LF that's not part of a CRLF, bail out. |
Daniel Axtens <dja@axtens.net> | no | 2022-03-08 | ||
| 0087-fs-f2fs-Do-not-read-past-the-end-of-nat-journal-entr.patch | fs/f2fs: Do not read past the end of nat journal entries A corrupt f2fs file system could specify a nat journal entry count that is beyond the maximum NAT_JOURNAL_ENTRIES. Check if the specified nat journal entry count before accessing the array, and throw an error if it is too large. |
Sudhakar Kuppusamy <sudhakar@linux.ibm.com> | no | 2022-04-06 | ||
| 0088-fs-f2fs-Do-not-read-past-the-end-of-nat-bitmap.patch | fs/f2fs: Do not read past the end of nat bitmap A corrupt f2fs filesystem could have a block offset or a bitmap offset that would cause us to read beyond the bounds of the nat bitmap. Introduce the nat_bitmap_size member in grub_f2fs_data which holds the size of nat bitmap. Set the size when loading the nat bitmap in nat_bitmap_ptr(), and catch when an invalid offset would create a pointer past the end of the allocated space. Check against the bitmap size in grub_f2fs_test_bit() test bit to avoid reading past the end of the nat bitmap. |
Sudhakar Kuppusamy <sudhakar@linux.ibm.com> | no | 2022-04-06 | ||
| 0089-fs-f2fs-Do-not-copy-file-names-that-are-too-long.patch | fs/f2fs: Do not copy file names that are too long A corrupt f2fs file system might specify a name length which is greater than the maximum name length supported by the GRUB f2fs driver. We will allocate enough memory to store the overly long name, but there are only F2FS_NAME_LEN bytes in the source, so we would read past the end of the source. While checking directory entries, do not copy a file name with an invalid length. |
Sudhakar Kuppusamy <sudhakar@linux.ibm.com> | no | 2022-04-06 | ||
| 0090-fs-btrfs-Fix-several-fuzz-issues-with-invalid-dir-it.patch | fs/btrfs: Fix several fuzz issues with invalid dir item sizing According to the btrfs code in Linux, the structure of a directory item leaf should be of the form: |struct btrfs_dir_item|name|data| in GRUB the name len and data len are in the grub_btrfs_dir_item structure's n and m fields respectively. The combined size of the structure, name and data should be less than the allocated memory, a difference to the Linux kernel's struct btrfs_dir_item is that the grub_btrfs_dir_item has an extra field for where the name is stored, so we adjust for that too. |
Darren Kenny <darren.kenny@oracle.com> | no | 2022-03-29 | ||
| 0091-fs-btrfs-Fix-more-ASAN-and-SEGV-issues-found-with-fu.patch | fs/btrfs: Fix more ASAN and SEGV issues found with fuzzing The fuzzer is generating btrfs file systems that have chunks with invalid combinations of stripes and substripes for the given RAID configurations. After examining the Linux kernel fs/btrfs/tree-checker.c code, it appears that sub-stripes should only be applied to RAID10, and in that case there should only ever be 2 of them. Similarly, RAID single should only have 1 stripe, and RAID1/1C3/1C4 should have 2. 3 or 4 stripes respectively, which is what redundancy corresponds. Some of the chunks ended up with a size of 0, which grub_malloc() still returned memory for and in turn generated ASAN errors later when accessed. While it would be possible to specifically limit the number of stripes, a more correct test was on the combination of the chunk item, and the number of stripes by the size of the chunk stripe structure in comparison to the size of the chunk itself. |
Darren Kenny <darren.kenny@oracle.com> | no | 2022-03-29 | ||
| 0092-fs-btrfs-Fix-more-fuzz-issues-related-to-chunks.patch | fs/btrfs: Fix more fuzz issues related to chunks The corpus was generating issues in grub_btrfs_read_logical() when attempting to iterate over stripe entries in the superblock's bootmapping. In most cases the reason for the failure was that the number of stripes in chunk->nstripes exceeded the possible space statically allocated in superblock bootmapping space. Each stripe entry in the bootmapping block consists of a grub_btrfs_key followed by a grub_btrfs_chunk_stripe. Another issue that came up was that while calculating the chunk size, in an earlier piece of code in that function, depending on the data provided in the btrfs file system, it would end up calculating a size that was too small to contain even 1 grub_btrfs_chunk_item, which is obviously invalid too. |
Darren Kenny <darren.kenny@oracle.com> | no | 2022-04-07 | ||
| fs-tester-time-fail.patch | Explicitly unset SOURCE_DATE_EPOCH before running fs tests. In some filesystem utils like mksquashfs, it will silently change behaviour and cause timestamps to unexpectedly change. Reproducible builds are good and useful for shipped artifacts, but this causes build-time tests to fail. |
Steve McIntyre | no | |||
| cve_2022_2601/0001-video-readers-Add-artificial-limit-to-image-dimensio.patch | [PATCH 01/14] video/readers: Add artificial limit to image dimensions In grub-core/video/readers/jpeg.c, the height and width of a JPEG image don't have an upper limit for how big the JPEG image can be. In Coverity, this is getting flagged as an untrusted loop bound. This issue can also seen in PNG and TGA format images as well but Coverity isn't flagging it. To prevent this, the constant IMAGE_HW_MAX_PX is being added to include/grub/bitmap.h, which has a value of 16384, to act as an artificial limit and restrict the height and width of images. This value was picked as it is double the current max resolution size, which is 8K. |
Alec Brown <alec.r.brown@oracle.com> | no | 2022-10-26 | ||
| cve_2022_2601/0002-font-Reject-glyphs-exceeds-font-max_glyph_width-or-f.patch | [PATCH 02/14] font: Reject glyphs exceeds font->max_glyph_width or font->max_glyph_height Check glyph's width and height against limits specified in font's metadata. Reject the glyph (and font) if such limits are exceeded. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-03 | ||
| cve_2022_2601/0003-font-Fix-size-overflow-in-grub_font_get_glyph_intern.patch | [PATCH 03/14] font: Fix size overflow in grub_font_get_glyph_internal() The length of memory allocation and file read may overflow. This patch fixes the problem by using safemath macros. There is a lot of code repetition like "(x * y + 7) / 8". It is unsafe if overflow happens. This patch introduces grub_video_bitmap_calc_1bpp_bufsz(). It is safe replacement for such code. It has safemath-like prototype. This patch also introduces grub_cast(value, pointer), it casts value to typeof(*pointer) then store the value to *pointer. It returns true when overflow occurs or false if there is no overflow. The semantics of arguments and return value are designed to be consistent with other safemath macros. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-05 | ||
| cve_2022_2601/0004-font-Fix-several-integer-overflows-in-grub_font_cons.patch | [PATCH 04/14] font: Fix several integer overflows in grub_font_construct_glyph() This patch fixes several integer overflows in grub_font_construct_glyph(). Glyphs of invalid size, zero or leading to an overflow, are rejected. The inconsistency between "glyph" and "max_glyph_size" when grub_malloc() returns NULL is fixed too. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-05 | ||
| cve_2022_2601/0005-font-Remove-grub_font_dup_glyph.patch | [PATCH 05/14] font: Remove grub_font_dup_glyph() Remove grub_font_dup_glyph() since nobody is using it since 2013, and I'm too lazy to fix the integer overflow problem in it. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-05 | ||
| cve_2022_2601/0006-font-Fix-integer-overflow-in-ensure_comb_space.patch | [PATCH 06/14] font: Fix integer overflow in ensure_comb_space() In fact it can't overflow at all because glyph_id->ncomb is only 8-bit wide. But let's keep safe if somebody changes the width of glyph_id->ncomb in the future. This patch also fixes the inconsistency between render_max_comb_glyphs and render_combining_glyphs when grub_malloc() returns NULL. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-05 | ||
| cve_2022_2601/0007-font-Fix-integer-overflow-in-BMP-index.patch | [PATCH 07/14] font: Fix integer overflow in BMP index The BMP index (font->bmp_idx) is designed as a reverse lookup table of char entries (font->char_index), in order to speed up lookups for BMP chars (i.e. code < 0x10000). The values in BMP index are the subscripts of the corresponding char entries, stored in grub_uint16_t, while 0xffff means not found. This patch fixes the problem of large subscript truncated to grub_uint16_t, leading BMP index to return wrong char entry or report false miss. The code now checks for bounds and uses BMP index as a hint, and fallbacks to binary-search if necessary. On the occasion add a comment about BMP index is initialized to 0xffff. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-15 | ||
| cve_2022_2601/0008-font-Fix-integer-underflow-in-binary-search-of-char-.patch | [PATCH 08/14] font: Fix integer underflow in binary search of char index If search target is less than all entries in font->index then "hi" variable is set to -1, which translates to SIZE_MAX and leads to errors. This patch fixes the problem by replacing the entire binary search code with the libstdc++'s std::lower_bound() implementation. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-14 | ||
| cve_2022_2601/0009-kern-efi-sb-Enforce-verification-of-font-files.patch | [PATCH 09/14] kern/efi/sb: Enforce verification of font files As a mitigation and hardening measure enforce verification of font files. Then only trusted font files can be load. This will reduce the attack surface at cost of losing the ability of end-users to customize fonts if e.g. UEFI Secure Boot is enabled. Vendors can always customize fonts because they have ability to pack fonts into their GRUB bundles. This goal is achieved by: * Removing GRUB_FILE_TYPE_FONT from shim lock verifier's skip-verification list. * Adding GRUB_FILE_TYPE_FONT to lockdown verifier's defer-auth list, so font files must be verified by a verifier before they can be loaded. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-08-14 | ||
| cve_2022_2601/0010-fbutil-Fix-integer-overflow.patch | [PATCH 10/14] fbutil: Fix integer overflow Expressions like u64 = u32 * u32 are unsafe because their products are truncated to u32 even if left hand side is u64. This patch fixes all problems like that one in fbutil. To get right result not only left hand side have to be u64 but it's also necessary to cast at least one of the operands of all leaf operators of right hand side to u64, e.g. u64 = u32 * u32 + u32 * u32 should be u64 = (u64)u32 * u32 + (u64)u32 * u32. For 1-bit bitmaps grub_uint64_t have to be used. It's safe because any combination of values in (grub_uint64_t)u32 * u32 + u32 expression will not overflow grub_uint64_t. Other expressions like ptr + u32 * u32 + u32 * u32 are also vulnerable. They should be ptr + (grub_addr_t)u32 * u32 + (grub_addr_t)u32 * u32. This patch also adds a comment to grub_video_fb_get_video_ptr() which says it's arguments must be valid and no sanity check is performed (like its siblings in grub-core/video/fb/fbutil.c). |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-09-06 | ||
| cve_2022_2601/0011-font-Fix-an-integer-underflow-in-blit_comb.patch | [PATCH 11/14] font: Fix an integer underflow in blit_comb() The expression (ctx.bounds.height - combining_glyphs[i]->height) / 2 may evaluate to a very big invalid value even if both ctx.bounds.height and combining_glyphs[i]->height are small integers. For example, if ctx.bounds.height is 10 and combining_glyphs[i]->height is 12, this expression evaluates to 2147483647 (expected -1). This is because coordinates are allowed to be negative but ctx.bounds.height is an unsigned int. So, the subtraction operates on unsigned ints and underflows to a very big value. The division makes things even worse. The quotient is still an invalid value even if converted back to int. This patch fixes the problem by casting ctx.bounds.height to int. As a result the subtraction will operate on int and grub_uint16_t which will be promoted to an int. So, the underflow will no longer happen. Other uses of ctx.bounds.height (and ctx.bounds.width) are also casted to int, to ensure coordinates are always calculated on signed integers. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-10-24 | ||
| cve_2022_2601/0012-font-Harden-grub_font_blit_glyph-and-grub_font_blit_.patch | [PATCH 12/14] font: Harden grub_font_blit_glyph() and grub_font_blit_glyph_mirror() As a mitigation and hardening measure add sanity checks to grub_font_blit_glyph() and grub_font_blit_glyph_mirror(). This patch makes these two functions do nothing if target blitting area isn't fully contained in target bitmap. Therefore, if complex calculations in caller overflows and malicious coordinates are given, we are still safe because any coordinates which result in out-of-bound-write are rejected. However, this patch only checks for invalid coordinates, and doesn't provide any protection against invalid source glyph or destination glyph, e.g. mismatch between glyph size and buffer size. This hardening measure is designed to mitigate possible overflows in blit_comb(). If overflow occurs, it may return invalid bounding box during dry run and call grub_font_blit_glyph() with malicious coordinates during actual blitting. However, we are still safe because the scratch glyph itself is valid, although its size makes no sense, and any invalid coordinates are rejected. It would be better to call grub_fatal() if illegal parameter is detected. However, doing this may end up in a dangerous recursion because grub_fatal() would print messages to the screen and we are in the progress of drawing characters on the screen. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-10-24 | ||
| cve_2022_2601/0013-font-Assign-null_font-to-glyphs-in-ascii_font_glyph.patch | [PATCH 13/14] font: Assign null_font to glyphs in ascii_font_glyph[] The calculations in blit_comb() need information from glyph's font, e.g. grub_font_get_xheight(main_glyph->font). However, main_glyph->font is NULL if main_glyph comes from ascii_font_glyph[]. Therefore grub_font_get_*() crashes because of NULL pointer. There is already a solution, the null_font. So, assign it to those glyphs in ascii_font_glyph[]. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-10-28 | ||
| cve_2022_2601/0014-normal-charset-Fix-an-integer-overflow-in-grub_unico.patch | [PATCH 14/14] normal/charset: Fix an integer overflow in grub_unicode_aglomerate_comb() The out->ncomb is a bit-field of 8 bits. So, the max possible value is 255. However, code in grub_unicode_aglomerate_comb() doesn't check for an overflow when incrementing out->ncomb. If out->ncomb is already 255, after incrementing it will get 0 instead of 256, and cause illegal memory access in subsequent processing. This patch introduces GRUB_UNICODE_NCOMB_MAX to represent the max acceptable value of ncomb. The code now checks for this limit and ignores additional combining characters when limit is reached. |
Zhang Boyang <zhangboyang.id@gmail.com> | no | 2022-10-28 | ||
| font-Try-opening-fonts-from-the-bundled-memdisk.patch | font: Try opening fonts from the bundled memdisk | Chris Coulson <chris.coulson@canonical.com> | no | 2022-11-16 | ||
| kern-file-Fix-error-handling-in-grub_file_open.patch | [PATCH] kern/file: Fix error handling in grub_file_open() grub_file_open() calls grub_file_get_device_name(), but doesn't check the return. Instead, it checks if grub_errno is set. However, nothing initialises grub_errno here when grub_file_open() starts. This means that trying to open one file that doesn't exist and then trying to open another file that does will (incorrectly) also fail to open that second file. Let's fix that. |
Steve McIntyre <steve@einval.com> | no | 2022-12-05 | ||
| gcc12_build_dangling_pointer.patch | Borrowed and tweaked fix from: commit be8eb0eed69f8bc9ac20837eae58e55218011880 util/mkimage: Fix dangling pointer may be used error diff --git a/util/mkimage.c b/util/mkimage.c index a26cf76f7..58c199f7c 100644 |
Michael Chang <mchang@suse.com> | no | 2022-03-28 | ||
| gcc12_build_array_bounds.patch | Borrowed and tweaked fix from: commit acffb81485e35e1f28152949a1c6e1d4dbf5172e diff --git a/grub-core/bus/cs5536.c b/grub-core/bus/cs5536.c index 8c90ed598..cd0a45e58 100644 |
Michael Chang <mchang@suse.com> | no | 2022-03-28 | ||
| gcc12_build_array_bounds2.patch | commit 3ce13d974b887338ae972c79b41ff6fc0eee6388 lib/reed_solomon: Fix array subscript 0 is outside array bounds The grub_absolute_pointer() is a compound expression that can only work within a function. We are out of luck here when the pointer variables require global definition due to ATTRIBUTE_TEXT that have to use fully initialized global definition because of the way linkers work. static gf_single_t * const gf_powx ATTRIBUTE_TEXT = (void *) 0x100000; For the reason given above, use GCC diagnostic pragmas to suppress the array-bounds warning. Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> diff --git a/grub-core/lib/reed_solomon.c b/grub-core/lib/reed_solomon.c index 82779a296..562bd2e3e 100644 |
Michael Chang <mchang@suse.com> | no | 2022-03-28 | ||
| arm64_remove_magic_number_check.patch | commit 69edb31205602c29293a8c6e67363bba2a4a1e66 loader/arm64/linux: Remove magic number header field check The "ARM\x64" magic number in the file header identifies an image as one that implements the bare metal boot protocol, allowing the loader to simply move the file to a suitably aligned address in memory, with sufficient headroom for the trailing .bss segment (the required memory size is described in the header as well). Note of this matters for GRUB, as it only supports EFI boot. EFI does not care about this magic number, and nor should GRUB: this prevents us from booting other PE linux images, such as the generic EFI zboot decompressor, which is a pure PE/COFF image, and does not implement the bare metal boot protocol. So drop the magic number check. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c index ef3e9f944..4c92e48ac 100644 |
Ard Biesheuvel <ardb@kernel.org> | no | 2022-08-11 | ||
| grub_mkconfig_restore_umask.patch | commit 0adec29674561034771c13e446069b41ef41e4d4 grub-mkconfig: Restore umask for the grub.cfg The commit ab2e53c8a (grub-mkconfig: Honor a symlink when generating configuration by grub-mkconfig) has inadvertently discarded umask for creating grub.cfg in the process of running grub-mkconfig. The resulting wrong permission (0644) would allow unprivileged users to read GRUB configuration file content. This presents a low confidentiality risk as grub.cfg may contain non-secured plain-text passwords. This patch restores the missing umask and sets the creation file mode to 0600 preventing unprivileged access. Fixes: CVE-2021-3981 Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in index c3ea7612e..62335d027 100644 |
Michael Chang <mchang@suse.com> | no | 2021-12-03 | ||
| ignore_checksum_seed_incompat_feature.patch | commit 7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 fs/ext2: Ignore checksum seed incompat feature This incompat feature is used to denote that the filesystem stored its metadata checksum seed in the superblock. This is used to allow tune2fs changing the UUID on a mounted metdata_csum filesystem without having to rewrite all the disk metadata. However, the GRUB doesn't use the metadata checksum at all. So, it can just ignore this feature if it is enabled. This is consistent with the GRUB filesystem code in general which just does a best effort to access the filesystem's data. The checksum seed incompat feature has to be removed from the ignore list if the support for metadata checksum verification is added to the GRUB ext2 driver later. Suggested-by: Eric Sandeen <esandeen@redhat.com> Suggested-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Lukas Czerner <lczerner@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> diff --git a/grub-core/fs/ext2.c b/grub-core/fs/ext2.c index e7dd78e66..4953a1591 100644 |
Javier Martinez Canillas <javierm@redhat.com> | no | 2021-06-11 | ||
| ignore_the_large_dir_incompat_feature.patch | commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b fs/ext2: Ignore the large_dir incompat feature Recently, ext4 added the large_dir feature, which adds support for a 3 level htree directory support. The GRUB supports existing file systems with htree directories by ignoring their existence, and since the index nodes for the hash tree look like deleted directory entries (by design), the GRUB can simply do a brute force O(n) linear search of directories. The same is true for 3 level deep htrees indicated by large_dir feature flag. Hence, it is safe for the GRUB to ignore the large_dir incompat feature. Fixes: https://savannah.gnu.org/bugs/?61606 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> diff --git a/grub-core/fs/ext2.c b/grub-core/fs/ext2.c index 0989e26e1..e1cc5e62a 100644 |
Theodore Ts'o <tytso@mit.edu> | no | 2022-08-30 | ||
| 987008-lvrename-boot-fail.patch | fix renamed LV detection It looks like the detection of the LVM logical volumes fails in certain edge conditions. In particular, it was reported that renaming an LV will make grub fail to boot from the system as it cannot properly detect it anymore. . I have looked at the code surrounding the patch and cannot claim to understand the entire function here, as it is huge and quite cryptic. But it seems sane: the `ptr` we're inspecting here starts at the `rlocn->offset`, but we were adding `mda_size` to the (somewhat) unrelated metadatabuf instead. Now we're marking the `mda_end` correctly, based on the rlocn->offsite and ->size. . I have not tested this myself as the test setup is quite involved, but it seems others (e.g. "Hoyer, David" <David.Hoyer@netapp.com>) have tested the patch and confirmed it worked. |
Rogier <rogier777@gmail.com> | yes | debian upstream | other | 2023-02-25 |
| disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch | disk/cryptodisk: When cheatmounting, use the sector info of the cheat device When using grub-probe with cryptodisk, the mapped block device from the host is used directly instead of decrypting the source device in GRUB code. In that case, the sector size and count of the host device needs to be used. This is especially important when using LUKS2, which does not assign total_sectors and log_sector_size when scanning, but only later when the segments in the JSON area are evaluated. With an unset log_sector_size, grub_device_open() complains. This fixes grub-probe failing with "error: sector sizes of 1 bytes aren't supported yet.". |
Fabian Vogt <fvogt@suse.de> | no | debian | https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739 | 2023-01-12 |
| osdep-devmapper-getroot-have-devmapper-recognize-luks2.patch | osdep/devmapper/getroot: Have devmapper recognize LUKS2 Changes UUID comparisons so that LUKS1 and LUKS2 are both recognized as being LUKS cryptodisks. |
Josselin Poiret <dev@jpoiret.xyz> | no | debian | https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9022a48dd9984fc3e90a5b42c3b5483d6061ccfb | 2023-01-12 |
| osdep-devmapper-getroot-set-up-cheated-luks2-cryptodisk-mount-from-dm-parameters.patch | osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM parameters This lets a LUKS2 cryptodisk have its cipher and hash filled out, otherwise they wouldn't be initialized if cheat mounted. |
Josselin Poiret <dev@jpoiret.xyz> | no | debian | https://git.savannah.gnu.org/cgit/grub.git/commit/?id=aa5172a55cfabdd0bed3161ad44fc228b9d019f7 | 2023-01-12 |
| arm64-handover-to-kernel-if-sb-enabled.patch | Cherry-pick parts of "Load arm with SB enabled." Fix Secure Boot on arm64 by cherry-picking the relevant parts of upstream patch "Load arm with SB enabled." |
Emanuele Rocca <ema@debian.org> | no | vendor, https://github.com/rhboot/grub2/commit/2786ab864cf00c15123320671f653e9a36ba12b4 | 2023-03-31 | |
| grub_os-prober.patch | diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in index 225a3baf7..ea3f3f804 100644 |
no | ||||
| os-prober-Allow-initrd-to-contain-spaces.patch | [PATCH] os-prober: Allow initrd to contain spaces linux-boot-prober produces structured output with newline-terminated rows representing kernels, each with colon-delimited columns. We translate this into a sequence of space-separated words representing kernels, each containing colon-delimited fields where spaces are represented by carets. When we parse each of those words into colon-delimited fields, if the field could conceivably contain spaces then we need to translate carets back into spaces. We did this for label and parameters, but not for the initrd. In particular, when CPU microcode is installed on Arch Linux or its derivatives, they write CPU microcode into one initrd archive and the rest of early user-space into another, instead of concatenating the archives into a single file like Debian derivatives do. To boot Arch successfully from the grub menu, we need to add all of their initrds to the grub menu entry (detecting this situation requires an os-prober patch, for which see <https://bugs.debian.org/820838>). [Commit message added by Simon McVittie <smcv@collabora.com>] |
General Chaos <debianbugs@toeai.com> | yes | debian upstream | 2016-04-12 | |
| ntfs-cve-fixes/fs-ntfs-Fix-an-OOB-write-when-parsing-the-ATTRIBUTE_LIST-.patch | fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute for the $MFT file When parsing an extremely fragmented $MFT file, i.e., the file described using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer containing bytes read from the underlying drive to store sector numbers, which are consumed later to read data from these sectors into another buffer. These sectors numbers, two 32-bit integers, are always stored at predefined offsets, 0x10 and 0x14, relative to first byte of the selected entry within the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem. However, when parsing a specially-crafted file system image, this may cause the NTFS code to write these integers beyond the buffer boundary, likely causing the GRUB memory allocator to misbehave or fail. These integers contain values which are controlled by on-disk structures of the NTFS file system. Such modification and resulting misbehavior may touch a memory range not assigned to the GRUB and owned by firmware or another EFI application/driver. This fix introduces checks to ensure that these sector numbers are never written beyond the boundary. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 | ||
| ntfs-cve-fixes/fs-ntfs-Fix-an-OOB-read-when-reading-data-from-the-reside.patch | fs/ntfs: Fix an OOB read when reading data from the resident $DATA attribute When reading a file containing resident data, i.e., the file data is stored in the $DATA attribute within the NTFS file record, not in external clusters, there are no checks that this resident data actually fits the corresponding file record segment. When parsing a specially-crafted file system image, the current NTFS code will read the file data from an arbitrary, attacker-chosen memory offset and of arbitrary, attacker-chosen length. This allows an attacker to display arbitrary chunks of memory, which could contain sensitive information like password hashes or even plain-text, obfuscated passwords from BS EFI variables. This fix implements a check to ensure that resident data is read from the corresponding file record segment only. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 | ||
| ntfs-cve-fixes/fs-ntfs-Fix-an-OOB-read-when-parsing-directory-entries-fr.patch | fs/ntfs: Fix an OOB read when parsing directory entries from resident and non-resident index attributes This fix introduces checks to ensure that index entries are never read beyond the corresponding directory index. The lack of this check is a minor issue, likely not exploitable in any way. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 | ||
| ntfs-cve-fixes/fs-ntfs-Fix-an-OOB-read-when-parsing-bitmaps-for-index-at.patch | fs/ntfs: Fix an OOB read when parsing bitmaps for index attributes This fix introduces checks to ensure that bitmaps for directory indices are never read beyond their actual sizes. The lack of this check is a minor issue, likely not exploitable in any way. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 | ||
| ntfs-cve-fixes/fs-ntfs-Fix-an-OOB-read-when-parsing-a-volume-label.patch | fs/ntfs: Fix an OOB read when parsing a volume label This fix introduces checks to ensure that an NTFS volume label is always read from the corresponding file record segment. The current NTFS code allows the volume label string to be read from an arbitrary, attacker-chosen memory location. However, the bytes read are always treated as UTF-16LE. So, the final string displayed is mostly unreadable and it can't be easily converted back to raw bytes. The lack of this check is a minor issue, likely not causing a significant data leak. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 | ||
| ntfs-cve-fixes/fs-ntfs-Make-code-more-readable.patch | fs/ntfs: Make code more readable Move some calls used to access NTFS attribute header fields into functions with human-readable names. |
Maxim Suhanov <dfirblog@gmail.com> | no | 2023-08-28 |