linux-ext4 - Re: [bug report] ext4: convert symlink external data block mapping to bdev

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

Message-ID: <0ff22f40-3eee-44ed-970d-8ee6af7979e4@kadam.mountain>
Date:   Thu, 10 Aug 2023 14:48:45 +0300
From:   Dan Carpenter <dan.carpenter@...aro.org>
To:     Zhang Yi <yi.zhang@...wei.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [bug report] ext4: convert symlink external data block mapping
 to bdev

On Thu, Aug 10, 2023 at 07:25:02PM +0800, Zhang Yi wrote:
> On 2023/8/10 18:31, Dan Carpenter wrote:
> > Hello Zhang Yi,
> > 
> > The patch 6493792d3299: "ext4: convert symlink external data block
> > mapping to bdev" from Apr 24, 2022 (linux-next), leads to the
> > following Smatch static checker warning:
> > 
> > 	fs/ext4/namei.c:3353 ext4_init_symlink_block()
> > 	error: potential NULL/IS_ERR bug 'bh'
> > 
> > fs/ext4/namei.c
> >     3337 static int ext4_init_symlink_block(handle_t *handle, struct inode *inode,
> >     3338                                    struct fscrypt_str *disk_link)
> >     3339 {
> >     3340         struct buffer_head *bh;
> >     3341         char *kaddr;
> >     3342         int err = 0;
> >     3343 
> >     3344         bh = ext4_bread(handle, inode, 0, EXT4_GET_BLOCKS_CREATE);
> >     3345         if (IS_ERR(bh))
> >     3346                 return PTR_ERR(bh);
> > 
> >>From reading the code, it looks like ext4_bread() can return both error
> > pointers and NULL.  (Second return statement).
> 
> Hello, Dan,
> 
> After checking the code, we have passed in EXT4_GET_BLOCKS_CREATE to
> ext4_bread(), the return value must be an error code or a valid
> buffer_head, it's impossible to return NULL. So I think the warning
> is a false positive.
> 

Yep.  You're right.  Thanks for taking a look at this.

Eventually, I will get around to tracking bits set across function
boundaries and that should silence this warning.

regards,
dan carpenter