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: <20240104104255.eewvmywxyqtfwzug@quack3> Date: Thu, 4 Jan 2024 11:42:55 +0100 From: Jan Kara <jack@...e.cz> To: Baokun Li <libaokun1@...wei.com> Cc: linux-ext4@...r.kernel.org, tytso@....edu, adilger.kernel@...ger.ca, jack@...e.cz, ritesh.list@...il.com, linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com, yukuai3@...wei.com, stable@...r.kernel.org Subject: Re: [PATCH v2 4/8] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() On Thu 21-12-23 23:05:54, Baokun Li wrote: > After updating bb_free in mb_free_blocks, it is possible to return without > updating bb_fragments because the block being freed is found to have > already been freed, which leads to inconsistency between bb_free and > bb_fragments. > > Since the group may be unlocked in ext4_grp_locked_error(), this can lead > to problems such as dividing by zero when calculating the average fragment > length. Hence move the update of bb_free to after the block double-free > check guarantees that the corresponding statistics are updated only after > the core block bitmap is modified. > > Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit") > CC: stable@...r.kernel.org # 3.10 > Signed-off-by: Baokun Li <libaokun1@...wei.com> Just one nit below but regardless of that feel free to add: Reviewed-by: Jan Kara <jack@...e.cz> > @@ -1941,10 +1936,16 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, > EXT4_GROUP_INFO_BBITMAP_CORRUPT); > } else { > mb_regenerate_buddy(e4b); > + goto check; > } > - goto done; > + return; > } I think this might be more readable when we revert the condition like: /* * Fastcommit replay can free already freed blocks which * corrupts allocation info. Regenerate it. */ if (sbi->s_mount_state & EXT4_FC_REPLAY) { mb_regenerate_buddy(e4b); goto check; } ext4_grp_locked_error(sb, e4b->bd_group, inode ? inode->i_ino : 0, blocknr, "freeing already freed block (bit %u); block bitmap corrupt.", block); ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT); return; } Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists