Select Git revision
Search by author
- Any Author
- authors
-
Carsten Schoenert
carsten.schoenert
-
Francois Techene
francois.techene
-
Guido Gunther
guido.gunther
-
Jeremiah Foster
jeremiah.foster
-
Jonathon Hall
jonathon.hall
-
Julian Sparber
julian.sparber
-
Matthias Klumpp
matthias.klumpp
-
Nicole Faerber
nicole.faerber
-
Sebastian Krzyszkowiak
sebastian.krzyszkowiak
-
Stelios Milidonis
stelios.milidonis
-
Theodotos Andreou
theodotos.andreou
- Jun 08, 2022
-
-
Daniel Axtens authored
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. Signed-off-by:
Daniel Axtens <dja@axtens.net> Reviewed-by:
-
Daniel Axtens authored
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. Fixes: CVE-2021-3696 Signed-off-by:
-
Daniel Axtens authored
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 3ccf16df (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. Fixes: CVE-2021-3695 Signed-off-by: -
Daniel Axtens authored
This causes the bitmap to be leaked. Do not permit multiple image headers. Signed-off-by:
-
Daniel Axtens authored
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. Signed-off-by:
-
Daniel Axtens authored
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. Signed-off-by:
-
Julian Andres Klode authored
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. Fixes: CVE-2022-28735 Signed-off-by:
-
Chris Coulson authored
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. Fixes: CVE-2022-28736 Signed-off-by:
-
Chris Coulson authored
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. Signed-off-by: -
Chris Coulson authored
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. Signed-off-by:
-
- Nov 29, 2021
-
-
Colin Watson authored
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. Signed-off-by:
-
- Sep 27, 2021
-
-
Marius Bakke authored
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. Signed-off-by:
-
Erwan Velu authored
The commit 8b1e5d19 (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> Fixes: 8b1e5d19 (fs/xfs: Add bigtime incompat feature support) Signed-off-by:
-
Mathieu Trudel-Lapierre authored
Signed-off-by:
-
Javier Martinez Canillas authored
Commit f60ba9e5 (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. Reported-by:
-
Steve McIntyre authored
Patch-Name: debug_verifiers.patch
-
Michael Chang authored
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. Reported-by:
-
Ian Jackson authored
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. Signed-off-by:
-
Fabian Greffrath authored
Patch-Name: dejavu-font-path.patch
-
Steve McIntyre authored
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.] Bug-Debian: https://bugs.debian.org/930531 Last-Update: 2021-09-24 Patch-Name: grub-install-removable-shim.patch
-
Colin Watson authored
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. Signed-off-by:
-
Hervé Werner authored
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. Bug-Debian: https://bugs.debian.org/917117 Last-Update: 2019-02-10 Patch-Name: uefi-secure-boot-cryptomount.patch
-
Jeroen Dekkers authored
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. Bug-Debian: https://bugs.debian.org/741464 Last-Update: 2019-02-09 Patch-Name: at_keyboard-module-init.patch
-
Colin Watson authored
These don't work with and aren't needed by dynamically-loaded completions. Bug-Debian: https://bugs.debian.org/912852 Forwarded: no Last-Update: 2018-11-16 Patch-Name: bash-completion-drop-have-checks.patch
-
Colin Watson authored
Bug-Debian: https://bugs.debian.org/906470 Last-Update: 2018-10-28 Patch-Name: skip-grub_cmd_set_date.patch
-
Luca Boccassi authored
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. Author: Luca Boccassi <bluca@debian.org> Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1418360 Forwarded: no Patch-Name: fix-lockdown.patch
-
Michael Chang authored
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. Signed-off-by:
-
Michael Chang authored
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. Signed-off-by:
-
Michael Chang authored
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. Signed-off-by:
-
Michael Chang authored
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. Signed-off-by:
-
Michael Chang authored
Implement new net_bootp6 command for IPv6 network auto configuration via the DHCPv6 protocol (RFC3315). Signed-off-by:
-
Aaron Miller authored
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 Last-Update: 2021-09-24 Patch-Name: net-read-bracketed-ipv6-addr.patch
-
Chad MILLER authored
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. Bug: https://savannah.gnu.org/bugs/?43653 Bug-Debian: https://bugs.debian.org/824974 Bug-Ubuntu: https://bugs.launchpad.net/bugs/1527727 Last-Update: 2016-11-01 Patch-Name: zpool-full-device-name.patch
-
Colin Watson authored
Add fallback boot entries for alternative installed init systems. Based on patches from Michael Biebl and Didier Roche. Bug-Debian: https://bugs.debian.org/757298 Bug-Debian: https://bugs.debian.org/773173 Forwarded: no Last-Update: 2017-06-23 Patch-Name: mkconfig-other-inits.patch
-
Steve McIntyre authored
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. Signed-off-by:
-
Ian Campbell authored
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). Signed-off-by:
-
Ian Campbell authored
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. Signed-off-by:
-
Paulo Flabiano Smorigo authored
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. Also-By:
-
Paulo Flabiano Smorigo authored
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 Bug-Ubuntu: https://bugs.launchpad.net/bugs/1295255 Origin: other, https://lists.gnu.org/archive/html/grub-devel/2014-09/msg00076.html Last-Update: 2014-09-26 Patch-Name: ieee1275-clear-reset.patch
-
Colin Watson authored
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.) Forwarded: no Last-Update: 2014-10-15 Patch-Name: install-powerpc-machtypes.patch
-