linux-kernel - Re: [PATCH] fs: fuse: check return value of fuse_simple

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: <CAJfpegtOOCVrNkSmpmMY0dVH-359jc3RqXJ7K6dzvUqxtCxBtg@mail.gmail.com>
Date:   Mon, 20 Jan 2020 14:39:18 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Cengiz Can <cengiz@...nel.wtf>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: fuse: check return value of fuse_simple_request

On Mon, Jan 20, 2020 at 1:13 PM Cengiz Can <cengiz@...nel.wtf> wrote:
>
> In `fs/fuse/file.c` `fuse_simple_request` is used in multiple places,
> with its return value properly checked for possible errors.
>
> However the usage on `fuse_file_put` ignores its return value. And the
> following `fuse_release_end` call used hard-coded error value of `0`.
>
> This triggers a warning in static analyzers and such.
>
> I've added a variable to capture `fuse_simple_request` result and passed
> that to `fuse_release_end` instead.

Which then goes on to ignore the error, so we are exactly where we
were with some added obscurity, which will be noticed by the next
generation of static analyzer, when you'd come up with an even more
obscure way to ignore the error, etc...  This leads to nowhere.

If this matters (not sure) then we'll need a notation to ignore the
return value.  Does casting to (void) work?

Thanks,
Miklos