Generating the canary at build time allows the canary to be different for
every build which could limit the effectiveness of certain exploits.
Fallback to the statically generated random bytes if /dev/urandom is not
readable, e.g. Windows.
On 32-bit architectures, which use a 32-bit canary, reduce the canary to
4 bytes with one byte being NUL to filter out string buffer overflow attacks.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The canary, __stack_chk_guard, is in the BSS and so will get initialized to
zero if it is not explicitly initialized. If the UEFI firmware does not
support the RNG protocol, then the canary will not be randomized and will
be zero. This seems like a possibly easier value to write by an attacker.
Initialize canary to static random bytes, so that it is still random when
there is no RNG protocol. Set at least one byte to NUL to protect against
string buffer overflow attacks [1]. Code that writes NUL terminated strings
will terminate when a NUL is encountered in the input byte stream. So the
attacker will not be able to forge the canary by including it in the input
stream without terminating the string operation and thus limiting the
stack corruption.
[1] https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/gfxmenu/gui_image.c, Coverity detected a double free in the
function load_image(). The function checks if self->bitmap and self->raw_bitmap
aren't NULL and then frees them. In the case self->bitmap and self->raw_bitmap
are the same, only self->raw_bitmap is freed which would also free the memory
used by self->bitmap. However, in this case self->bitmap isn't being set to NULL
which could lead to a double free later in the code. After self->raw_bitmap is
freed, it gets set to the variable bitmap. If this variable is NULL, the code
could have a path that would free self->bitmap a second time in the function
rescale_image().
Fixes: CID 292472
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to the ACPI specification the XSDT Entry field contains an array
of 64-bit physical addresses which points to other DESCRIPTION_HEADERs. However,
the entry_ptr iterator is defined as a 32-bit pointer. It means each 64-bit
entry in the XSDT table is treated as two separate 32-bit entries then. Fix the
issue by using correct addresses sizes when processing RSDT and XSDT tables.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
NetBSD uses slightly different function names for the same functions.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
NetBSD gettext is older than the check but we don't actually need 0.18.3,
older one works fine. This is needed to make bootstrap work on NetBSD.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is some variance in how compiler treats sizeof() especially
on 32-bit platforms where it can be naturally either int or long.
Explicit cast solves the issue.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this build-time mkfont fails dynamic linking. This is not ideal
but improves the situation until a better solution is available.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
*BSD puts fonts in other places. Add them to the list.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The HAVE_LIBZFS is defined by libzfs test and hence conflicts with
manual definition. On NetBSD it ends up detecting zfs but not detecting
nvpair and creates confusion. Split them.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It's not critical, -Werror on it is inappropriate. We don't want to
modify gnulib too much. This warning is pretty much irrelevant.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It's not available on NetBSD outside of syslog. Using strerror() is more
reliable as we retrieve errno immediately rather than down the stack.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Wrong function and variable name cause a stupid compilation error on
NetBSD and OpenBSD. Only NetBSD and OpenBSD use this file. No other
platform is affected.
Additionally, define RAW_FLOPPY_MAJOR constant if it is missing.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
After recent change in blocklist types we have a type mismatch. Fixing it
requires a wrapper or large changes. I feel like wrapper makes more sense.
Without this patch we end up with a compilation problem and without wrapping
callback data is not passed properly anymore.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Variable e is set but never used. We can just remove it now.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We don't really control the small aspects of generated files and NetBSD
version has an unused variable that is then detected by gcc as warning
that is then promoted to error.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Current code implicitly assumes that aligning chunk_size + *kern_end is
the same as aligning on curload which is not the case because
chunk_size starts at zero even if *kern_end is unaligned and ALIGN_PAGE
moved curload to an aligned position but not *kern_end + chunk_size.
This fixes booting of FreeBSD with zfs module.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit 154dcb1ae (build: Allow explicit module dependencies) broke
out of tree builds by introducing the extra_deps.lst file into the
source tree but referencing it just by name in grub-core/Makefile.am.
Fix it by adding $(top_srcdir)/grub-core to the path.
Fixes: 154dcb1ae (build: Allow explicit module dependencies)
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit 3f9eace2d (util/grub-install: Delay copying files to
{grubdir,platdir} after install_device was validated) delaying
copying of files caused a regression when installing without an
existing directory structure.
This patch ensures that the platform directory actually exists by the
time the code tries to canonicalize its filename.
Fixes: 3f9eace2d (util/grub-install: Delay copying files to {grubdir,platdir} after install_device was validated)
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The add_tar_files() function currently iterates through a directory's
content using readdir(), which doesn't guarantee a specific order. This
lack of deterministic behavior impacts reproducibility in the build process.
This commit resolves the issue by introducing sorting functionality.
The list retrieved by readdir() is now sorted alphabetically before
incorporation into the tar archive, ensuring consistent and predictable
file ordering within the archive.
On the occasion fix tfp memory leak.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Bernhard Wiedemann <bwiedemann@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This change mirrors a previous fix [1] but is specific to images
generated by grub-mkstandalone.
The former fix, commit 85a7be241 (util/mkimage: Use stable timestamp
when generating binaries.), focused on utilizing a stable timestamp
during binary generation in the util/mkimage context. This commit
extends that approach to the images produced by grub-mkstandalone,
ensuring consistency and stability in timestamps across all generated
binaries.
[1] 85a7be241 util/mkimage: Use stable timestamp when generating binaries.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Bernhard Wiedemann <bwiedemann@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Replace definition of HTTP_PORT with a pre-processor macro that converts
the constant to the correct grub_uint16_t type.
Change "port" local variable definition in http_establish() to have the
same type.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com
Revert the commit a79c567f6 (templates: Remove unused version comparison
functions) and add a warning to the functions that they are deprecated.
Removing the functions directly caused a lot of upgrade issues
with custom user scripts that called the functions. In Debian and
Ubuntu, grub-mkconfig is invoked as a post-installation script
and would fail, causing upgrades to fail halfway through and
putting the package manager into an inconsistent state.
FWIW, we get one bug per 2 weeks basically, for an interim Ubuntu
release which generally does not receive much usage, that is a high
number.
The proposal is to pick this for 2.12 and directly after the release
remove it again. Then users will have time to fix their scripts without
systems breaking immediately.
This reverts commit a79c567f6 (templates: Remove unused version
comparison functions).
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously grub-install copied modules to grubdir before doing any
validation on the install_device.
When grub-install was called with an invalid install_device, modules
were already copied to /boot before it found out and was forced to rely
on atexit() rollback.
This patch delays copying the modules after at least some install_device
validation was done, and thus reduces reliance on successful rollback.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If validation has been disabled via MokSbState, secure boot on the
firmware is still enabled, and the kernel fails to boot.
This is a bit hacky, because shim_lock is not *fully* enabled, but
it triggers the right code paths.
Ultimately, all this will be resolved by shim gaining it's own image
loading and starting protocol, so this is more a temporary workaround.
Fixes: 6425c12cd (efi: Fallback to legacy mode if shim is loaded on x86 archs)
Cc: Peter Jones <pjones@redhat.com>
Cc: Michael Chang <mchang@suse.com>
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Improve the documentation of the bli module and explain in more detail what
it does. Make clear that GPT formatted drives are expected and other
partition formats are ignored. Also reorder and reword this section a bit.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The bli module has a "hidden" dependency on the part_gpt module, which
is not picked up automatically by the build system. One purpose of the
bli module is to communicate the GPT UUID of the partition GRUB was
launched from to Linux user-space (systemd-gpt-auto-generator).
Without the part_gpt module, bli is not able to obtain the UUID. Since
bli does its work in the module initialization function, the order in
which the modules are loaded is also important: part_gpt needs to be
loaded before the bli module.
To solve this, track this dependency explicitly.
Note that the Boot Loader Interface specification, which bli aims to
implement, requires GPT formatted drives. The bli module ignores all
other partition formats.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The build system deduces inter-module dependencies from the symbols
required and exported by the modules. This works well, except for some
rare cases where the dependency is indirect or hidden. A module might
not make use of any function of some other module, but still expect its
functionality to be available to GRUB.
To solve this, introduce a new file, currently empty, called extra_deps.lst
to track these cases manually. This file gets processed in the same way
as the automatically generated syminfo.lst, making it possible to inject
data into the dependency resolver.
Since *.lst files are set to be ignored by git, add an exception for
extra_deps.lst.
Additionally, introduce a new keyword for the syminfo.lst syntax:
"depends" allows specifying a module dependency directly:
depends <module> <depdendency>...
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Display upper_mem_limit and its rounded-down value in MiB.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On PowerVM and KVM on Power use the new memory allocation function that
honors restrictions on which memory GRUB can actually use. In the request
structure indicate the request for a single memory block along with
address alignment restrictions. Request direct usage of the memory block
by setting init_region to false (prevent it from being added to GRUB's
heap). Initialize the found addr to -1, so that -1 will be returned
to the loader in case no memory could be allocated.
Report an out-of-memory error in case the initrd could not be loaded.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Introduce flags to identify PowerVM and KVM on Power and set them where
each type of host has been detected.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Rename regions_claim() to grub_regions_claim() to make it available for
memory allocation. The ieee1275 loader will use this function on PowerVM
and KVM on Power and thus avoid usage of memory that it is not allowed
to use.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Add support for memory alignment requirements and adjust a candidate
address to it before checking whether the block is large enough. This
must be done in this order since the alignment adjustment can make
a block smaller than what was requested.
None of the current callers has memory alignment requirements but the
ieee1275 loader for kernel and initrd will use it to convey them.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Return the allocated address of the memory block in the request structure
if a memory allocation was actually done. Leave the address untouched
otherwise. This enables a caller who wants to use the allocated memory
directly, rather than adding the memory to the heap, to see where memory
was allocated. None of the current callers need this but the converted
ieee1275 loader will make use of it.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Let the regions_claim() request structure's init_region determine whether
to call grub_mm_init_region() on it. This allows for adding memory to
GRUB's memory heap if init_region is set to true, or direct usage of the
memory otherwise. Set all current callers' init_region to true since they
want to add memory regions to GRUB's heap.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
The regions_claim() function limits the allocation of memory regions
by excluding certain memory areas from being used by GRUB. This for
example includes a gap between 640MB and 768MB as well as an upper
limit beyond which no memory may be used when an fadump is present.
However, the ieee1275 loader for kernel and initrd currently does not
use regions_claim() for memory allocation on PowerVM and KVM on Power
and therefore may allocate memory in those areas that it should not use.
To make the regions_claim() function more flexible and ultimately usable
for the ieee1275 loader, introduce a request structure to pass various
parameters to the regions_claim() function that describe the properties
of requested memory chunks. In a first step, move the total and flags
variables into this structure.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Pavithra Prakash <pavrampu@in.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Carolyn Scherrer <cpscherr@us.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
XFS introduced 64-bit extent counters for inodes via a series of
upstream commits and the feature was marked as stable in v6.5 via
commit 61d7e8274cd8 (xfs: drop EXPERIMENTAL tag for large extent
counts).
Further, xfsprogs release v6.5.0 switched this feature on by default
in mkfs.xfs via commit e5b18d7d1d96 (mkfs: enable large extent counts
by default).
Filesystems formatted with large extent count support, nrext64=1, are
thus currently not recognizable by GRUB, since this is an incompat
feature. Add the required support so that those filesystems and inodes
with large extent counters can be read by GRUB.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Marta Lewandowska <mlewando@redhat.com>
Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
With new alignment specification it's easy to screw up. Fortunately if it
happens the size will be bigger than intended. Compile time assert will catch
this.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On ia64 alignment requirements are strict. When we pass a pointer to
UUID it needs to be at least 4-byte aligned or EFI will crash.
On the other hand in device path there is no padding for UUID, so we
need 2 types in one formor another. Make 4-byte aligned and unaligned types
The code is structured in a way to accept unaligned inputs
in most cases and supply 4-byte aligned outputs.
Efiemu case is a bit ugly because there inputs and outputs are
reversed and so we need careful casts to account for this
inversion.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gpt_partition contains grub_guid. We need to decide whether the whole
structure is unaligned and then we need to use packed_guid. But we never
have unaligned part entries as we read them in an aligned buffer from disk.
Hence just make it all aligned.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
We do table search in many places doing exactly the same algorithm.
The only minor variance in users is which table is used if several entries
are present. As specification mandates uniqueness and even if it ever isn't,
first entry is good enough, unify this code and always use the first entry.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
known_protocols isn't used anywhere else and even misses grub_ prefix, so
let's make it local (static).
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function argp_parser() in util/grub-mount.c lacks a check on the
sanity of the file path when parsing parameters. This results in
a segmentation fault if a partition is mounted to a non-existent path.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Mads Kiilerich <mads@kiilerich.com>
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The XFS directory entry parsing code has never been completely correct
for extent based directories. The parser correctly handles the case
where the directory is contained in a single extent, but then mistakenly
assumes the data blocks for the multiple extent case are each identical
to the single extent case. The difference in the format of the data
blocks between the two cases is tiny enough that its gone unnoticed for
a very long time.
A recent change introduced some additional bounds checking into the XFS
parser. Like GRUB's existing parser, it is correct for the single extent
case but incorrect for the multiple extent case. When parsing a directory
with multiple extents, this new bounds checking is sometimes (but not
always) tripped and triggers an "invalid XFS directory entry" error. This
probably would have continued to go unnoticed but the /boot/grub/<arch>
directory is large enough that it often has multiple extents.
The difference between the two cases is that when there are multiple
extents, the data blocks do not contain a trailer nor do they contain
any leaf information. That information is stored in a separate set of
extents dedicated to just the leaf information. These extents come after
the directory entry extents and are not included in the inode size. So
the existing parser already ignores the leaf extents.
The only reason to read the trailer/leaf information at all is so that
the parser can avoid misinterpreting that data as directory entries. So
this updates the parser as follows:
For the single extent case the parser doesn't change much:
1. Read the size of the leaf information from the trailer
2. Set the end pointer for the parser to the start of the leaf
information. (The previous bounds checking set the end pointer to the
start of the trailer, so this is actually a small improvement.)
3. Set the entries variable to the expected number of directory entries.
For the multiple extent case:
1. Set the end pointer to the end of the block.
2. Do not set up the entries variable. Figuring out how many entries are
in each individual block is complex and does not seem worth it when
it appears to be safe to just iterate over the entire block.
The bounds check itself was also dependent upon the faulty XFS parser
because it accidentally used "filename + length - 1". Presumably this
was able to pass the fuzzer because in the old parser there was always
8 bytes of slack space between the tail pointer and the actual end of
the block. Since this is no longer the case the bounds check needs to be
updated to "filename + length + 1" in order to prevent a regression in
the handling of corrupt fliesystems.
Notes:
* When there is only one extent there will only ever be one block. If
more than one block is required then XFS will always switch to holding
leaf information in a separate extent.
* B-tree based directories seems to be parsed properly by the same code
that handles multiple extents. This is unlikely to ever occur within
/boot though because its only used when there are an extremely large
number of directory entries.
Fixes: ef7850c75 (fs/xfs: Fix issues found while fuzzing the XFS filesystem)
Fixes: b2499b29c (Adds support for the XFS filesystem.)
Fixes: https://savannah.gnu.org/bugs/?64376
Signed-off-by: Jon DeVree <nuxi@vault24.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Tested-by: Marta Lewandowska <mlewando@redhat.com>
