linux-kernel - 2.6.12 quotaoff loop on a read-only ext3 filesystem

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]

Date:	Fri, 06 Jul 2007 11:41:30 +0200
From:	xb <xavier.bru@...l.net>
To:	linux-kernel@...r.kernel.org
Subject: 2.6.12 quotaoff loop on a read-only ext3 filesystem

Hi all,

Running on a 2.6.12.6 kernel, we found a problem with running quotaoff 
on an ext3 read-only filesystem:

quotaoff loops in dqput() because DQ_ACTIVE_B is set and 
ext3_release_dquot() returns because of ext3_journal_start() returning 
EROFS  without  calling dquot_release() that should have removed 
DQ_ACTIVE_B.
Then if we try to run the mount command to remount rw the file system, 
it deadlocks on the down_write(&s->s_umount) owned by quotaoff.
Has this problem been already identified and fixed in recent versions ?
Thanks in advance.

traces -------------------------------------------------------
/static int ext3_release_dquot(struct dquot *dquot)
{
...
    handle = ext3_journal_start(dquot_to_inode(dquot),
                    EXT3_QUOTA_INIT_BLOCKS);
    if (IS_ERR(handle))
        return PTR_ERR(handle); <------ returns here
    ret = dquot_release(dquot); <------- not executed
...
}/

/    <4>Backtrace of current task (pid 20974, quotaoff)
    <4>
    <4>Call Trace:
    <4> [<a00000010019ca10>] dqput+0x210/0x4e0
    <4>                                sp=e00000062a21fbe0 
bsp=e00000062a211198
    <4> [<a0000001001a15f0>] vfs_quota_off+0x590/0xca0
    <4>                                sp=e00000062a21fbe0 
bsp=e00000062a2110f8
    <4> [<a0000001001a5660>] sys_quotactl+0x1540/0x15e0
    <4> [<a00000010000b040>] ia64_ret_from_syscall+0x0/0x20
/
/    <4>mount         D a000000100547520     0 24222  
21243                     (NOTLB)
    <4>
    <4>Call Trace:
    <4> [<a000000100543ab0>] schedule+0xc10/0x23a0
    <4>                                sp=e00000055a5efaf0 
bsp=e00000055a5e1248
    <4> [<a000000100547520>] rwsem_down_write_failed+0x1c0/0x4e0
    <4>                                sp=e00000055a5efb30 
bsp=e00000055a5e1200
    <4> [<a000000100139930>] sget+0x6d0/0xb60
    <4>                                sp=e00000055a5efb50 
bsp=e00000055a5e1198
    <4> [<a00000010013b6d0>] get_sb_bdev+0xd0/0x400
    <4>                                sp=e00000055a5efb70 
bsp=e00000055a5e1148
    <4> [<a000000205508980>] ext3_get_sb+0x40/0x60 [ext3]
    <4>                                sp=e00000055a5efb90 
bsp=e00000055a5e1110
 <4> [<a00000010013bfe0>] do_kern_mount+0x140/0x480
   <4> [<a0000001001759f0>] do_mount+0x370/0x1060
    <4>                                sp=e00000055a5efb90 
bsp=e00000055a5e1060
   <4> [<a000000100177000>] sys_mount+0x100/0x1c0
  /


View attachment "xavier.bru.vcf" of type "text/x-vcard" (294 bytes)