Commit 5d71d711d07a ("libblkid: topolicy/ioctl: use union for multiple data types")
incorrectly assumed that set_ulong and set_int refer to the type
returned by the kernel. Instead the different function pointer names
refer to the types of the function pointers.
However all ioctls, except for the later added BLKGETDISKSEQ, return
32bit integers.
This made libblkid also interpret the upper 32bits too, leading to
garbage values.
Introduce a new member 'kernel_size' to also handle the 64bit
BLKGETDISKSEQ.
Karel Zak [Wed, 17 Jan 2024 11:37:08 +0000 (12:37 +0100)]
wall: fix calloc cal [-Werror=calloc-transposed-args]
term-utils/wall.c:143:37: error: xcalloc sizes specified with sizeof in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
143 | buf->groups = xcalloc(sizeof(*buf->groups), buf->ngroups);
| ^
term-utils/wall.c:143:37: note: earlier argument should specify number of elements, later size of each element
Milan Broz [Fri, 16 Feb 2024 15:44:12 +0000 (16:44 +0100)]
libblkid: Check offset in LUKS2 header
LUKS2 binary header contains offset field that describes where
the header should be located.
If this offset is not correct, blkid should tread this header
as invalid.
This patch fixes problem when both swap and LUKS headers are
present (LUKS header was swapped out) and detected LUKS header
is at a wrong offset.
As LUKS has higher priority, it confuses detection.
mdadm superblocks before 1.1 are placed at the end of the device, which
means that the data contained inside the array starts at offset 0. For
LUKS inside MD, blkid falsely detects this as plain LUKS instead of a
linux_raid_member. This causes e.g. dracut to not assemble the array
during boot and system startup fails.
Karel Zak [Thu, 14 Dec 2023 08:41:37 +0000 (09:41 +0100)]
Merge branch 'stable-2.39/libsmartcols' of https://github.com/t-8ch/util-linux into stable/v2.39
* 'stable-2.39/libsmartcols' of https://github.com/t-8ch/util-linux:
libsmartcols: (tests) add test for continuous json output
libsmartcols: only recognize closed object as final element
libsmartcols: flush correct stream
libsmartcols: drop spourious newline in between streamed JSON objects
github: add labeler
Edward Chron [Fri, 23 Jun 2023 01:31:31 +0000 (18:31 -0700)]
dmesg: -r LOG_MAKEPRI needs fac << 3
Submission to Project: util-linux
Open Incident: #2325 at github.com/util-linux/util-linux/issues/2325
Component: util-linux/sys-utils
File: dmesg.c
Code level patch applied against: 2.39 - latest code pulled from
git.github.com:util-linux/util-linux.git
BUG: The facility field passed to macro from /usr/include/sys/syslog.h
LOG_MAKEPRI(fac, pri) by dmesg -r needs to have fac argument
shifted 3 bit to the left to return a valid raw valid. The lower
3 bits for a raw value are used by the loglevel priority (pri)
field, so the facility bits can only occupy the bits above the
bits used to hold the pri field value.
The dmesg -r command produces the incorrect output for the raw value
for the or'ed combination of the facility | loglevel priority that gets
produced by the LOG_MAKEPRI macro. That macro is defined as:
#define LOG_MAKEPRI(fac, pri) ((fac) | (pri))
which is defined in the current glibc code in /usr/include/sys/syslog.h
and is used only in the dmesg -r (raw output option) command to form the
raw value for facility or'ed with loglevel priority and displayed as:
<#>[#######.######] ...
where the # in <#> contains the output from the LOG_MAKEPRI macro.
The lower 3 bits are reserved for the loglevel priority 0-7
and the bits above that are for the facility value, so the facility
index should be shifted to the left three bits and or'ed with the
loglevel priority.
In the glibc file: /usr/include/sys/syslog.h the macro LOG_MAKEPRI is
defined as:
#define LOG_MAKEPRI(fac, pri) ((fac) | (pri)
and returns the wrong facility and loglevel priority values, ideally it
should be defined as:
We checked with glibc developement and the LOG_MAKEPRI macro is correct
as is and can't be changed as it used by *BSD as is so the solution for
dmesg -r is to shift the facility index left by 3 bits as input to the
LOG_MAKEPRI macro. That is what glibc development recommended.
(For reference, see glibc bugzilla Bug 30563)
We can front end the LOG_MAKEPRI macro with a macro that shifts the
facility by the needed 3 bits which we've added to dmesg.c:
-bash-4.2# dmesg -r | grep "Test Message Facility"
<7>[ 495.317239] Test Message Facility 8 Loglevel 6
<7>[ 503.340779] Test Message Facility 8 Loglevel 7
<7>[ 643.374764] Test Message Facility 24 Loglevel 6
<7>[ 657.165117] Test Message Facility 24 Loglevel 7
However, if we run the dmesg -r command using the new front end macro
LOG_RAW_FAC_PRI(fac, pri) we do get the correct output:
Here is the corrected dmesg -r output:
-------------------------------------
-bash-4.2# dmesg -r | grep "Test Message Facility"
<14>[ 495.317239] Test Message Facility 8 Loglevel 6
<15>[ 503.340779] Test Message Facility 8 Loglevel 7
<30>[ 643.374764] Test Message Facility 24 Loglevel 6
<31>[ 657.165117] Test Message Facility 24 Loglevel 7
shifting the facility index value by 3 bits in the LOG_RAW_FAC_PRI macro
provides the correct ouput as shown. All the other commands produce the
same output so now they are all in agreement.
Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com>
(cherry picked from commit fa6ac102dc1bca83d75af423a2be3e377d60432e)
Karel Zak [Tue, 28 Nov 2023 13:40:48 +0000 (14:40 +0100)]
libmount: accept '\' as escape for options separator
The libmount library can accept any characters as an option value when
the value is quoted (e.g., foo="b,a,r"). However, overlayfs users have
been using '\' as an escape character (e.g., lowerdir=foo\,bar).
Although this escaping mechanism was never officially supported by
libmount/mount, it worked for the old mount(2) API because it kept the
options string unparsed for the mount(2) syscall.
The introduction of the new mount API, which utilizes fsconfig(2) per
option, has brought attention to this issue.
This patch addresses the problem by introducing official support for
'\' as an escape character for options separator.
Suggested-by: Miklos Szeredi <miklos@szeredi.hu>
References: https://lore.kernel.org/all/CAOQ4uxhgUSPkYAV8SJu-SFszkJcVO3-M4DXf46nJUtXODrPk2g@mail.gmail.com/T/#ma8e6cfc1ce7229abc089e03eed99b23b90d701e5 Signed-off-by: Karel Zak <kzak@redhat.com>
(cherry picked from commit f6c29efa929cb8c741591ab38061e7921d53a997)
Karel Zak [Mon, 27 Nov 2023 10:25:29 +0000 (11:25 +0100)]
Merge branch 'stable-2.39/bcachefs-fixes' of https://github.com/t-8ch/util-linux into PR/stable-v2.39.3
* 'stable-2.39/bcachefs-fixes' of https://github.com/t-8ch/util-linux:
tests: skip broken tests on docker
libblkid: (bcachefs) add support for sub-device labels
libblkid: (bcachefs) adapt to major.minor version
libuuid: avoid truncate clocks.txt to improve performance
Instead of explicitly truncating clocks.txt file, pad with
whitespaces in the end of file.
This is done to improve performance of libuuid on xfs
filesystems. Instead of truncating the file, pad it with whitespaces.
This is anyways used as a failsafe method in case truncate fails.
The reason why this regression was introduced was because of: 869ae85dae64 ("xfs: flush new eof page on truncate to avoid post-eof corruption")
An attempt to move the clocks.txt to /run (tmpfs) has been attempted before
[1] and with commit ab2e7dd17 ("libuuid: move clock state file from
/var/lib to /var/run"). The latter was reverted.
Define cs_min through a define and not a const int to avoid the
following build failure with -O0 raised since version 2.39 and
https://github.com/util-linux/util-linux/commit/2fa4168c8bc9d5438bc1dfadda293c7c21b6fa59:
libuuid/src/gen_uuid.c: In function 'uuid_generate_time_generic':
libuuid/src/gen_uuid.c:536:33: error: initializer element is not constant
THREAD_LOCAL int cache_size = cs_min;
^~~~~~
For consistency, also use define for cs_max and cs_factor
Karel Zak [Thu, 2 Nov 2023 09:41:03 +0000 (10:41 +0100)]
libmount: improve mnt_table_next_child_fs()
The function utilizes the struct libmnt_itr to iterate through the mountinfo file
but neglects the direction specified by the iterator. This a bug. The application
must manage the direction, as, for instance, umount(8) requires the children of
the mountpoint in reverse order.
Fixes: https://github.com/util-linux/util-linux/issues/2552 Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak [Wed, 1 Nov 2023 13:47:41 +0000 (14:47 +0100)]
disk-utils: add SPDX and Copyright notices
Explicitly state the license (usually GPL-2.0-or-later; our default)
and include copyright statements in all files to prevent false positive
reports from license analysis tools. Add also add SPDX-License-Identifier
tag to all files.
Yuezhang Mo [Wed, 11 Oct 2023 10:42:11 +0000 (18:42 +0800)]
libblkid: exfat: fix fail to find volume label
Commit f98b56326 set the maximum number of iterations to 10000.
If the volume label is after the 10000th entry, the volume label
will not be found. So this commit sets the maximum number of
iterations to correct value 256×1024×1024/32.
Fixes: f98b56326 ("libblkid: [exfat] Limit maximum number of iterations in find_label") Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Andy Wu <Andy.Wu@sony.com> Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com>
Thomas Weißschuh [Mon, 25 Sep 2023 22:27:22 +0000 (00:27 +0200)]
libblkid: (ntfs) validate that sector_size is a power of two
The NTFS prober reads data based off an offset of the sector size.
If the sector size is unaligned and the read data is cached then other
probers can read unaligned values.
Sector sizes for NTFS actually only make sense as power-of-two so
validate that and as a sideeffect avoid the unaligned reads.
Also add the reproducer from OSS-Fuzz that found this issue.
Some lines in /proc/cpuinfo can be large e.g. flags and can then
truncate them in displaying them
BUFSIZ can vary quite a bit e.g. glibc/linux systems its 8192
but on musl/linux and OSX its 1024, on mingW it is 256, some tests e.g.
x86_64-64cpu-linux6.2.tar.gz has added really long line for cpu flags
line which is greater than 1024 characters and hence this test fails
on musl because lscpu -s reports truncated string