The size passed to grub_utf8_to_utf16() for the source string is
used as a limit for the string if NUL character is not encountered.
However, len, which is "strlen(src) * 2 + 2" is surely greater than
strlen(src). Pass the exact correct length.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the following allocation fails this would leave load_options NULL
while load_options_size not valid. If the allocation succeed
load_options_size is overwritten.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 40e261b89b71 (lib/LzmaEnc: Validate "len" before subtracting)
ensures that the variable len is at least 2. As a result, GetLenToPosState(len)
never returns a value greater than or equal to kNumLenToPosStates,
making the changes introduced in the commit 16c0dbf4bc6a (lzma: Make
sure we don't dereference past array) unreachable and no longer necessary.
This reverts commit 16c0dbf4bc6a (lzma: Make sure we don't dereference past array).
Fixes: CID 481982
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In bidi_line_wrap(), "kk - 1" in the for loop init, "i = kk - 1",
underflows when "kk" (unsigned int) is 0. Assigning the result of
"kk - 1" to signed int "i" may cause overflow. To address both
issues, cast "kk" to a signed type before subtraction to ensure
safe arithmetic and assignment.
Fixed: CID 473874
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
This patch resolved a minor issue spotted by Coverity:
a983d36bd917 (gnulib/regexec: Resolve unused variable)
But, it was removed by the Gnulib update:
2b7902459803 (Update gnulib version and drop most gnulib patches)
It caused Coverity to continue to flag the issue. Daniel Kiper
suggested to bring back the patch a983d36bd917 (gnulib/regexec: Resolve
unused variable).
Fixes: CID 292459
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Pull in Gnulib fix to allow lib/base64.c to compile using GCC 15 or newer.
Pulled from Gnulib commit 25df6dc425 (Silence some
-Wunterminated-string-initialization warnings.)
GCC 15 adds a new compiler warning "-Wunterminated-string-initialization"
that will trigger what is considered a false-positive in lib/base64.c as
this array is not treated as a string but an array of characters so the
lack of NUL string terminator is expected.
GCC team has added ability to flag such instances of arrays that the
compiler may think are strings as "nonstring" arrays to avoid this
warning: __attribute__((nonstring)).
Fixes: https://savannah.gnu.org/bugs/?66470
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function merge_state_with_log(), memory is allocated for the variable
next_nodes when creating a union of the variables table_nodes and log_nodes.
However, if next_state->entrance_nodes is NULL, then table_nodes becomes NULL
and we still allocate memory to copy the content of log_nodes. This can cause
a resource leak since we only free the memory for next_nodes if table_nodes
isn't NULL. To prevent this, we need to check that next_state->entrance_nodes
isn't NULL before allocating memory for the union.
This issue has been fixed in the latest version of gnulib and I've backported
this change to maintain consistency.
This issue was found by a Coverity scan of GRUB2 under the CID 473887.
Fixes: CID 473887
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the functions create_initial_state() and calc_eclosure_iter(), memory
is allocated for the elems member of a re_node_set structure but that
memory isn't freed on error. Before returning an error, a call to
re_node_set_free() should be made to prevent the resource leak.
This issue has been fixed in the latest version of gnulib and I've
backported this change to maintain consistency.
This issue was found by a Coverity scan of GRUB2 under the following
CIDs: 473869, 473888.
Fixes: CID 473869
Fixes: CID 473888
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
TPM 2.0 Key File format stores the PCR selection in the parameters
for TPM2_PolicyPCR and it already contains the selected PCR bank.
Currently, tpm2_key_protector dumped the PCR bank specified by the
--bank option, and it may not be the PCR bank for key unsealing.
To dump the real PCR bank for key unsealing, this commit records the PCR
bank used by TPM2_PolicyPCR and dumps PCR values from that bank when
necessary.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In LzmaEnc_CodeOneBlock(), both GetOptimumFast() and GetOptimum()
returns a value of greater or equal to 1, which is assigned to
"len". But since LZMA_MATCH_LEN_MIN == 2, "len" should be validated
before performing "len - LZMA_MATCH_LEN_MIN" to avoid underflow
when "len" equals to 1.
Fixes: CID 51508
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
The potential overflow issue arises at "size += ret;" because "size"
is of type ssize_t (signed) while "len" is size_t (unsigned). Repeatedly
adding read sizes, "ret", to "size" can potentially exceed the maximum
value of ssize_t, causing it to overflow into a negative or incorrect value.
The fix is to ensure "len" is within the range of SSIZE_MAX.
Fixes: CID 473850
Fixes: CID 473863
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Similarly to Intel IMSM, there are BIOS and UEFI implementations that
support DDF containers natively.
DDF and IMSM are very similar in handling, especially these should not
be considered as RAID abstraction. This fixes the requirement of having
a device map when probing DDF containers.
Fixes: https://issues.redhat.com/browse/RHEL-44336
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid attempting to defererence a NULL pointer to call read_symlink() when
the given filesystem does not provide a read_symlink() function. This could
be triggered if the calling filesystem had a file marked as a symlink.
This appears possible for HFS and was observed during fuzzing of NTFS.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct several infinite loops/hangs found during fuzzing. The issues
fixed here could occur if certain specific malformed NTFS file systems
were presented to GRUB. Currently, GRUB does not allow NTFS file system
access when lockdown mode is enforced, so these should be of minimal
impact.
The changes made in this commit generally correct issues such as attempting
to iterate through a buffer using a length read from the NTFS file system
without confirming the length is larger than 0.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct several memory access violations found during fuzzing.
The issues fixed here could occur if certain specific malformed NTFS
file systems were presented to GRUB. Currently, GRUB does not allow NTFS
file system access when lockdown mode is enforced, so these should be of
minimal impact.
The changes made in this commit generally correct issues where pointers
into data buffers were being calculated using lengths read from the
NTFS file system without sufficient bounds/sanity checking; or
attempting to access elements of a structure to free them, when the
structure pointer is NULL.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct ntfs_test test failures around attempting to validate attribute
list entries as attributes. The NTFS code uses common logic in some
places to parse both attributes and attribute_lists which complicates
validation. Attribute lists contain different headers including a
different size of the length field (2 bytes) at offset 4 instead of the
4 byte length field used in attributes at offset 4. There are other
differences as well, but attempting to validate attribute list types
using attribute header validation was causing failure of the NTFS test
suite. This change restores some of the validation logic which may be
shared between attributes and attribute lists to be closer to the
original logic prior to fixes for previous CVEs. A following commit will
address some of the implications of removing this validation logic by
correcting some fuzzer failures (some which are exposed by removing the
validation in some of the cases).
Fixes: 067b6d225 (fs/ntfs: Implement attribute verification)
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct ntfs_test test failures around attempting to validate attribute
run list values. The calculation was incorrect for the "curr" variable.
With previous calculation, some file systems would fail validation
despite being well-formed and valid. This was caused by incrementing
"curr" by min_size which included both the (already accounted for)
min_size as well as the size of the run list. Correct by making a new
variable "run_size" to denote the current run list size to increment
both "curr" and "min_size" separately.
Fixes: 067b6d225 (fs/ntfs: Implement attribute verification)
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Environment files may contain empty lines, which should be ignored
during parsing. Currently, these lines are not skipped and resulting in
incorrect behavior. This patch adds a check to skip empty lines along
with those starting with "#".
Signed-off-by: Shreenidhi Shedi <shreenidhi.shedi@broadcom.com>
Reviewed-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit b66c6f918 (fs/zfs: Fix a number of memory leaks in ZFS code)
fixes many of the same leaks detected in bug #63846 except one, which
is fixed here.
Fixes: https://savannah.gnu.org/bugs/?63846
Fixes: b66c6f918 (fs/zfs: Fix a number of memory leaks in ZFS code)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Those tests fail depending on the version of unifont. As we don't distribute
our own unifont it fails for most users. Disable them so that they don't mask
real failures. They can be reinstated once we solve unifont problem.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The option can be used to suppress output if we only want to test the
return value of the command.
Also, mention this option in the documentation.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Switching to another EFI boot application while there are secrets in
RAM is dangerous, because not all firmware is wiping memory on free.
To reduce the attack surface, wipe the passphrase acquired when
unlocking an encrypted volume.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit adds the grub_cryptodisk_erasesecrets() function to wipe
master keys from all cryptodisks. This function is EFI-only.
Since there is no easy way to "force unmount" a given encrypted disk,
this function renders all mounted cryptodisks unusable. An attempt to
read them will return garbage.
This is why this function must be used in "no way back" conditions.
Currently, it is used when unloading the cryptodisk module and when
performing the "exit" command (it is often used to switch to the next
EFI application). This function is not called when performing the
"chainloader" command, because the callee may return to GRUB. For this
reason, users are encouraged to use "exit" instead of "chainloader" to
execute third-party boot applications.
This function does not guarantee that all secrets are wiped from RAM.
Console output, chunks from disk read requests and other may remain.
This function does not clear the IV prefix and rekey key for geli disks.
Also, this commit adds the relevant documentation improvements.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the --cryptodisk-only argument is given, also check the target
device using the "cryptocheck" command, if available.
This extends the checks to common layouts like LVM-on-LUKS, so the
--cryptodisk-only argument transparently handles such setups.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This command examines a given diskfilter device, e.g., an LVM disk,
and checks if underlying disks, physical volumes, are cryptodisks,
e.g., LUKS disks, this layout is called "LVM-on-LUKS".
The return value is 0 when all underlying disks (of a given device)
are cryptodisks (1 if at least one disk is unencrypted or in an
unknown state).
Users are encouraged to include the relevant check before loading
anything from an LVM disk that is supposed to be encrypted.
This further supports the CLI authentication, blocking bypass
attempts when booting from an encrypted LVM disk.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows users to restrict the "search" command's scope to
encrypted disks only.
Typically, this command is used to "rebase" $root and $prefix
before loading additional configuration files via "source" or
"configfile". Unfortunately, this leads to security problems,
like CVE-2023-4001, when an unexpected, attacker-controlled
device is chosen by the "search" command.
The --cryptodisk-only argument allows users to ensure that the
file system picked is encrypted.
This feature supports the CLI authentication, blocking bypass
attempts.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This further mitigates potential misuse of the CLI after the
root device has been successfully unlocked via TPM.
Fixes: CVE-2025-4382
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When large extent counter / NREXT64 support was added to GRUB, it missed
a couple of direct reads of nextents which need to be changed to the new
NREXT64-aware helper as well. Without this, we'll have mis-reads of some
directories with this feature enabled.
The large extent counter fix likely raced on merge with commit 07318ee7e
(fs/xfs: Fix XFS directory extent parsing) which added the new direct
nextents reads just prior, causing this issue.
Fixes: aa7c1322671e (fs/xfs: Add large extent counters incompat feature support)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Jon DeVree <nuxi@vault24.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The code goes on to allocate memory in another region on failure, hence
it should discard the error.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Other platforms specify license in platform-specific files but corresponding
code for emu is in kernel, so datetime ends up without license section.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously, NV index mode only supported persistent handles which are
only for TPM objects.
On the other hand, the "NV index" handle allows the user-defined data,
so it can be an alternative to the key file and support TPM 2.0 Key
File format immediately.
The following tpm2-tools commands store the given key file, sealed.tpm,
in either TPM 2.0 Key File format or the raw format into the NV index
handle 0x1000000.
# tpm2_nvdefine -C o \
-a "ownerread|ownerwrite" \
-s $(stat -c %s sealed.tpm) \
0x1000000
# tpm2_nvwrite -C o -i sealed.tpm 0x1000000
To unseal the key in GRUB, add the "tpm2_key_protector_init" command to
grub.cfg:
tpm2_key_protector_init --mode=nv --nvindex=0x1000000
cryptomount -u <UUID> --protector tpm2
To remove the NV index handle:
# tpm2_nvundefine -C o 0x1000000
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extract the logic to handle the file buffer from the SRK recover
function to prepare to load the sealed key from the NV index handle,
so the NV index mode can share the same code path in the later patch.
The SRK recover function now only reads the file and sends the file
buffer to the new function.
Besides this, to avoid introducing more options for the NV index mode,
the file format is detected automatically before unmarshaling the data,
so there is no need to use the command option to specify the file format
anymore. In other words, "-T" and "-k" are the same now.
Also update grub.text to address the change.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following TPM 2.0 commands are introduced to tss2 to access the
TPM non-volatile memory associated with the NV index handles:
- TPM2_NV_DefineSpace,
- TPM2_NV_UndefineSpace,
- TPM2_NV_ReadPublic,
- TPM2_NV_Read,
- TPM2_NV_Write.
The related marshal/unmarshal functions are also introduced.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_tpm2_readpublic() and grub_tpm2_testparms() didn't check
authCommand when marshaling the input data buffer. Currently, there is
no caller using non-NULL authCommand. However, to avoid the potential
issue, the conditional check is added to insert authCommand into the
input buffer if necessary.
Also fix a few pointer checks.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The user may need to inspect the TPM 2.0 PCR values with the GRUB shell,
so the new tpm2_dump_pcr command is added to print all PCRs of the
specified bank.
Also update the document for the new command.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
PCR mismatch is one common cause of TPM key unsealing fail. Since the
system may be compromised, it is not safe to boot into OS to get the PCR
values and TPM eventlog for the further investigation.
To provide some hints, GRUB now dumps PCRs on policy fail, so the user
can check the current PCR values. PCR 0~15 are chosen to cover the
firmware, bootloader, and OS.
The sample output:
PCR Mismatch! Check firmware and bootloader before typing passphrase!
TPM PCR [sha256]:
00: 17401f37710984c1d8a03a81fff3ab567ae9291bac61e21715b890ee28879738
01: 7a114329ba388445a96e8db2a072785937c1b7a8803ed7cc682b87f3ff3dd7a8
02: 11c2776849e8e24b7d80c926cbc4257871bffa744dadfefd3ed049ce25143e05
03: 6c33b362073e28e30b47302bbdd3e6f9cee4debca3a304e646f8c68245724350
04: 62d38838483ecfd2484ee3a2e5450d8ca3b35fc72cda6a8c620f9f43521c37d1
05: d8a85cb37221ab7d1f2cc5f554dbe0463acb6784b5b8dc3164ccaa66d8fff0e1
06: 9262e37cbe71ed4daf815b4a4881fb7251c9d371092dde827557d5368121e10e
07: 219d542233be492d62b079ffe46cf13396a8c27e520e88b08eaf2e6d3b7e70f5
08: de1f61c973b673e505adebe0d7e8fb65fde6c24dd4ab4fbaff9e28b18df6ecd3
09: c1de7274fa3e879a16d7e6e7629e3463d95f68adcfd17c477183846dccc41c89
10: 0000000000000000000000000000000000000000000000000000000000000000
11: 0000000000000000000000000000000000000000000000000000000000000000
12: 0000000000000000000000000000000000000000000000000000000000000000
13: 0000000000000000000000000000000000000000000000000000000000000000
14: 9ab9ebe4879a7f4dd00c04f37e79cfd69d0dd7a8bcc6b01135525b67676a3e40
15: 0000000000000000000000000000000000000000000000000000000000000000
16: 0000000000000000000000000000000000000000000000000000000000000000
17: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23: 0000000000000000000000000000000000000000000000000000000000000000
error: failed to unseal sealed key (TPM2_Unseal: 0x99d).
error: no key protector provided a usable key for luks (af16e48f-746b-4a12-aae1-c14dcee429e0).
If the user happens to have the PCR values for key sealing, the PCR dump
can be used to identify the changed PCRs and narrow down the scope for
closer inspection.
Please note that the PCR dump is trustworthy only if the GRUB binary is
authentic, so the user has to check the GRUB binary thoroughly before
using the PCR dump.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update linux_kernel_params to match the v6.13.7 upstream version of boot_params.
Refactor most things out into structs, as the Linux kernel does.
edid_info should be a struct with "unsigned char dummy[128]" and efi_info should
be a struct as well, starting at 0x1c0. However, for backwards compatibility,
GRUB can have efi_systab at 0x1b8 and padding at 0x1bc (or padding at both spots).
This cuts into the end of edid_info. Make edid_info inline and only make it go
up to 0x1b8.
Signed-off-by: Patrick Colp <patrick.colp@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_xnu_load_kext_from_dir(), when the call to grub_device_open()
failed, it simply cleaned up previously allocated memory and returned
GRUB_ERR_NONE. However, it neglected to free ctx->newdirname which is
allocated before the call to grub_device_open().
Fixes: CID 473859
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_cmd_initrd(), initrd_ctx is allocated before calling
grub_relocator_alloc_chunk_align(). When that function fails,
initrd_ctx should be freed before exiting grub_cmd_initrd().
Fixes: CID 473852
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix memory leaks in make_vg() with new helper functions, free_pv()
and free_lv(). Additionally, correct a check after allocating
comp->segments->nodes that mistakenly checked lv->segments->nodes
instead, likely due to a copy-paste error.
Fixes: CID 473878
Fixes: CID 473884
Fixes: CID 473889
Fixes: CID 473890
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A regression was introduced recently as a part of the series of
filesystem related patches to address some CVEs found in GRUB.
This issue may cause either an infinite loop at startup when
accessing certain valid NTFS filesystems, or may cause a crash
due to a NULL pointer dereference on systems where NULL address
is invalid (such as may happen when calling grub-mount from
the operating system level).
Correct this issue by checking that at->attr_cur is within bounds
inside find_attr().
Fixes: https://savannah.gnu.org/bugs/?66855
Fixes: aff263187 (fs/ntfs: Fix out-of-bounds read)
Signed-off-by: B Horn <b@horn.uk>
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The grub_malloc() has been inadvertently removed from the code after it
has been modified to use safe math functions.
Fixes: 4beeff8a (net: Use safe math macros to prevent overflows)
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
Tested-by: Marta Lewandowska <mlewando@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change RMA size from 512 MB to 768 MB which will result in more memory
at boot time for PowerPC. When vTPM, Secure Boot or FADump are enabled
on PowerPC the 512 MB RMA memory is not sufficient for boot. With this
512 MB RMA, GRUB runs out of memory and fails to boot the machine.
Sometimes even usage of CDROM requires more memory for installation and
along with the options mentioned above exhausts the boot memory which
results in boot failures. Increasing the RMA size will resolves multiple
out of memory issues observed on PowerPC machines.
Failure details (GRUB debug console dump):
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 1
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 0
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/file.c:215: Closing `/ppc/ppc64/initrd.img' ...
kern/disk.c:297: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000'...
kern/disk.c:311: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000' succeeded.
kern/file.c:225: Closing `/ppc/ppc64/initrd.img' failed with 3.
kern/file.c:148: Opening `/ppc/ppc64/initrd.img' succeeded.
error: ../../grub-core/kern/mm.c:552:out of memory.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this fix the GRUB failed to boot linux with "out of memory" after
trying to run a "search --fs-uuid..." on a system that has 7 ZFS pools
across about 80 drives.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mark cachevol LV's as ignored features, which is true only if they are
configured as "writethrough". This patch does not let GRUB boot from
"writeback" cache-enabled LV's.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The LV matching must be done after processing the ignored feature
indirections, as integrity volumes & caches may have several levels
of indirection that the segments must be shifted through.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
