| 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
| ||
|
Message-ID: <18e96492-af22-4bfe-8005-5114a4d5d99e@kylinos.cn> Date: Wed, 25 Dec 2024 09:06:11 +0800 From: Zhao Mengmeng <zhaomengmeng@...inos.cn> To: Greg KH <gregkh@...uxfoundation.org> Cc: Jan Kara <jack@...e.cz>, sashal@...nel.org, Salvatore Bonaccorso <carnil@...ian.org>, Daniel Reichelt <debian@...htgeist.net>, linux-kernel@...r.kernel.org, 1089698@...s.debian.org, regressions@...ts.linux.dev Subject: Re: [regression] linux: Loop-mounted UDF ISOs no longer readable On 2024/12/24 17:59, Greg KH wrote: > On Tue, Dec 24, 2024 at 05:46:59PM +0800, Zhao Mengmeng wrote: >> On 2024/12/23 10:48, Zhao Mengmeng wrote: >>> On 2024/12/21 03:49, Salvatore Bonaccorso wrote: >>>> 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: >>> >>> Sorry to hear that... >>> >>>>> 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? >>> >>> I'll take a look at it. Will post it here if anything new founded. >>> >>>> #regzbot introduced: v6.1.112..v6.1.115 >>>> #regzbot monitor: https://bugs.debian.org/1089698 >>>> >>>> Regards, >>>> Salvatore >>> >> -------------------- >> Update on 2024.12.24: >> >> Hi Jan, Sasha, after some testing and code digging, I found that v6.1 LTS may need >> this patch to solve Daniel's issue: >> >> commit 1ea1cd11c72d1405a6b98440a9d5ea82dfa07166 >> Author: Jan Kara <jack@...e.cz> >> Date: Wed Jan 25 11:43:03 2023 +0100 >> >> udf: Fix directory iteration for longer tail extents >> >> When directory's last extent has more that one block and its length is >> not multiple of a block side, the code wrongly decided to move to the >> next extent instead of processing the last partial block. This led to >> directory corruption. Fix the rounding issue. >> >> Signed-off-by: Jan Kara <jack@...e.cz> > > It's already queued up for the next 6.1.y release in a few days, so if > you could test the -rc that is out for review right now, that would be > great! Glad to test it, will do. > thanks, > > greg k-h
Powered by blists - more mailing lists