#1152913 libblockdev: CVE-2026-111581: vfat/ntfs set_label passes label without "--" (option injection); patch attached inline

Package:
src:libblockdev
Source:
src:libblockdev
Submitter:
Sumit Verma
Date:
2026-11-03 05:39:02 UTC
Severity:
normal
Tags:
#1152913#5
Date:
2026-11-03 05:36:07 UTC
From:
To:
Hi,

CVE-2026-111581 (
https://www.google.com/url?q=https://bugzilla.redhat.com/show_bug.cgi?id%3D2554104&source=gmail&ust=1793770567286000&sa=E
)
has no Debian bug yet; the tracker lists libblockdev <unfixed>.

bd_fs_vfat_set_label() and bd_fs_ntfs_set_label() run fatlabel and
ntfslabel with the caller's label as a bare positional argument. A label
that starts with "-" is therefore parsed as an option by those tools.
Red Hat notes this is reachable through udisks2's Filesystem.SetLabel()
for an active local session.

There is no upstream fix yet: no commit, PR or issue in
storaged-project/libblockdev as of 2026-11-03, and the last release is
3.5.0. A minimal fix is to end option parsing with "--". The patch below
is against 3.5.0-2. It changes only the argv layout: "--reset" stays
before "--", and the device and label follow it.
--- a/src/plugins/fs/vfat.c
+++ b/src/plugins/fs/vfat.c
@@ -288,7 +288,9 @@
* Tech category: %BD_FS_TECH_VFAT-%BD_FS_TECH_MODE_SET_LABEL
*/
gboolean bd_fs_vfat_set_label (const gchar *device, const gchar *label,
GError **error) {
- const gchar *args[4] = {"fatlabel", device, NULL, NULL};
+ /* "--" ends option parsing so that a label starting with "-" is not
+ * interpreted by fatlabel as an option (CVE-2026-111581) */
+ const gchar *args[5] = {"fatlabel", "--", device, NULL, NULL};
UtilDep dep = {"fatlabel", "4.2", "--version", "fatlabel\\s+([\\d\\.]+).+"};
gchar *label_up = NULL;
gboolean new_vfat = FALSE;
@@ -302,14 +304,17 @@
new_vfat = bd_utils_check_util_version (
https://www.google.com/url?q=http://dep.name&source=gmail&ust=1793770567286000&sa=E,
dep.version,
dep.ver_arg, dep.ver_regexp,
NULL);
- if (new_vfat)
- args[2] = "--reset";
+ if (new_vfat) {
+ args[1] = "--reset";
+ args[2] = "--";
+ args[3] = device;
+ }
}

/* forcefully convert the label uppercase in case no reset was requested */
- if (label && args[2] == NULL) {
+ if (label && args[3] == NULL) {
label_up = g_ascii_strup (label, -1);
- args[2] = label_up;
+ args[3] = label_up;
}
ret = bd_utils_exec_and_report_error (args, NULL, error);
g_free (label_up);
--- a/src/plugins/fs/ntfs.c
+++ b/src/plugins/fs/ntfs.c
@@ -223,7 +223,9 @@
* Tech category: %BD_FS_TECH_NTFS-%BD_FS_TECH_MODE_SET_LABEL
*/
gboolean bd_fs_ntfs_set_label (const gchar *device, const gchar *label,
GError **error) {
- const gchar *args[4] = {"ntfslabel", device, label, NULL};
+ /* "--" ends option parsing so that a label starting with "-" is not
+ * interpreted by ntfslabel as an option (CVE-2026-111581) */
+ const gchar *args[5] = {"ntfslabel", "--", device, label, NULL};

if (!check_deps (&avail_deps, DEPS_NTFSLABEL_MASK, deps, DEPS_LAST,
&deps_check_lock, error))
return FALSE;

Testing: I did not rebuild libblockdev; that needs more -dev packages
than I have here. Instead I ran the exact argv vectors that 3.5.0 builds
and the patched ones against the real tools from sid (dosfstools 4.2-1.2
and ntfs-3g 1:2026.9.28-2), on 16 MB image files. Each case started from
the label "RESETME":

case 3.5.0 argv patched argv
vfat "DATA" label DATA label DATA
vfat "-V" prints fatlabel version, label "-V"
label unchanged
vfat --reset label cleared label cleared
ntfs "DATA" label DATA label DATA
ntfs "-n" parsed as an option (prints the label "-n"
current label), label unchanged

So with "--", labels are always taken literally, and the normal and
--reset paths behave as before. Both tools use getopt, which honours
"--"; the same applies to older fatlabel without --reset, where the
layout is "fatlabel -- device label".

An alternative or additional hardening would be to reject a leading "-"
in bd_fs_vfat_check_label()/bd_fs_ntfs_check_label(). However, labels
such as "-DATA-" are legitimate, so "--" seems the better fix.

This should probably be forwarded upstream too; I haven't opened
anything there.

Thanks!