linux-kernel - [regression] linux: Loop-mounted UDF ISOs no longer readable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Z2XKY0f6on1UbwWb@eldamar.lan>
Date: Fri, 20 Dec 2024 20:49:55 +0100
From: Salvatore Bonaccorso <carnil@...ian.org>
To: regressions@...ts.linux.dev, Zhao Mengmeng <zhaomengmeng@...inos.cn>,
	Jan Kara <jack@...e.cz>
Cc: Daniel Reichelt <debian@...htgeist.net>, linux-kernel@...r.kernel.org
Subject: [regression] linux: Loop-mounted UDF ISOs no  longer readable

Hi Jan, hi Zhao,

In Debian we got he following report, full quoted below from Daniel
Reichelt, dass after updating to 6.1.115 (and later, confirmed up to
6.1.119), loop-mounted UDF ISOs are no longer readable:

> Hi,
> 
> in 6.1.112-1 I could loop-mount Windows Setup ISOs (downloaded from M$; hashes
> are fine; 10/11, DE/EN don't seem to make any difference) and access their
> content perfectly fine, i.e. share the /sources/ sub-directory via samba for
> netinstall scenarios.
> 
> Starting with 6.1.115-1, the ISOs can be mounted, the root-dir is accessible
> and `stat $mntpt/sources` gives output as well. However `ls $mntpt/sources`
> hangs and the kernel log is spammed with entries like
> 
> ---------------8<-------------------------
> 2024-12-11T14:53:19.616728+01:00 srv kernel: [182394.024828] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.629970+01:00 srv kernel: [182394.038041] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.641623+01:00 srv kernel: [182394.049714] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.654841+01:00 srv kernel: [182394.062928] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.666495+01:00 srv kernel: [182394.074615] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.679747+01:00 srv kernel: [182394.087833] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.691394+01:00 srv kernel: [182394.099510] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.704646+01:00 srv kernel: [182394.112727] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.716283+01:00 srv kernel: [182394.124400] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.729539+01:00 srv kernel: [182394.137618] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.741185+01:00 srv kernel: [182394.149279] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.754422+01:00 srv kernel: [182394.162494] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> 2024-12-11T14:53:19.766071+01:00 srv kernel: [182394.174159] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
> 2024-12-11T14:53:19.779289+01:00 srv kernel: [182394.187375] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
> ---------------8<-------------------------
> 
> 
> 6.1.119-1 shows the same behaviour.
> Let me know if you need additional info.

We have not a full bisect, but Daniel confirmed already in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089698#22 some
observations:

> OK:
>   6.1.112-1
> BAD:
>   6.1.115-1
>   6.1.119-1
> OK again:
>   6.3.1-1~exp1
>   current trixie
>   current sid

(current trixie is 6.11.10 based kernel, current sid is based on
6.12.5 kernel).

Dies this ring some bell to you?

#regzbot introduced: v6.1.112..v6.1.115
#regzbot monitor: https://bugs.debian.org/1089698

Regards,
Salvatore