linux-kernel - Please queue ubifs: Fix ubifs_tnc_lookup() usage in do_kill_orphans() for stable (was: Re: [PATCH] ubifs: Fix ubifs_tnc_lookup() usage in do_kill

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1537701093.171645.1588186266734.JavaMail.zimbra@nod.at>
Date:   Wed, 29 Apr 2020 20:51:06 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     stable <stable@...r.kernel.org>
Cc:     linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        John Ogness <john.ogness@...utronix.de>
Subject: Please queue ubifs: Fix ubifs_tnc_lookup() usage in
 do_kill_orphans() for stable (was: Re: [PATCH] ubifs: Fix
 ubifs_tnc_lookup() usage in do_kill_orphans())

----- Ursprüngliche Mail -----
> Von: "John Ogness" <john.ogness@...utronix.de>
> An: "richard" <richard@....at>
> CC: "linux-mtd" <linux-mtd@...ts.infradead.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
> Gesendet: Mittwoch, 29. April 2020 16:56:31
> Betreff: Re: [PATCH] ubifs: Fix ubifs_tnc_lookup() usage in do_kill_orphans()

> Hi Richard,
> 
> Could you CC this patch to stable? It fixes a serious problem that I am
> seeing on real devices (i.e. Linux not being able to mount its root
> filesystem after a power cut). Thanks.

Just checked again, better ask stable maintainers. :-)

Stable maintainers, can you please make sure this patch will make it
into stable?
The upstream commit is:
4ab25ac8b2b5 ("ubifs: Fix ubifs_tnc_lookup() usage in do_kill_orphans()")

I always thought havings a Fixes-Tag is enough to make sure it will
get picked up. Isn't this the case?

Thanks,
//richard
 
> John Ogness
> 
> On 2020-01-19, Richard Weinberger <richard@....at> wrote:
>> Orphans are allowed to point to deleted inodes.
>> So -ENOENT is not a fatal error.
>>
>> Reported-by: Кочетков Максим <fido_max@...ox.ru>
>> Reported-and-tested-by: "Christian Berger" <Christian.Berger@...bosch.com>
>> Fixes: ee1438ce5dc4 ("ubifs: Check link count of inodes when killing orphans.")
>> Signed-off-by: Richard Weinberger <richard@....at>
>> ---
>>  fs/ubifs/orphan.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c
>> index 54d6db61106f..2645917360b9 100644
>> --- a/fs/ubifs/orphan.c
>> +++ b/fs/ubifs/orphan.c
>> @@ -688,14 +688,14 @@ static int do_kill_orphans(struct ubifs_info *c, struct
>> ubifs_scan_leb *sleb,
>>  
>>  			ino_key_init(c, &key1, inum);
>>  			err = ubifs_tnc_lookup(c, &key1, ino);
>> -			if (err)
>> +			if (err && err != -ENOENT)
>>  				goto out_free;
>>  
>>  			/*
>>  			 * Check whether an inode can really get deleted.
>>  			 * linkat() with O_TMPFILE allows rebirth of an inode.
>>  			 */
>> -			if (ino->nlink == 0) {
>> +			if (err == 0 && ino->nlink == 0) {
>>  				dbg_rcvry("deleting orphaned inode %lu",
> >  					  (unsigned long)inum);