linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gens <david.gens@cs.tu-darmstadt.de>
To: linux-fsdevel@vger.kernel.org
Subject: Potential use-after-return in fs/fs-writeback.c
Date: Tue, 29 Nov 2016 13:38:54 +0100	[thread overview]
Message-ID: <d1873d8cd6e20ef0ecc62cacb9d2582f@rbg.informatik.tu-darmstadt.de> (raw)

Hi,

my name is David, I work as a research assistant at TU Darmstadt, 
Germany.
We are currently developing a static analysis tool to find dangling 
pointer
vulnerabilities automatically in large code bases, based on LLVM.

We think we found a potential use-after-return in move_expired_inodes in 
the
file fs/fs-writeback.c. This is the relevant code (at least 3.11-4.8):

    static long wb_writeback(struct bdi_writeback *wb,
                             struct wb_writeback_work *work)
    {
         unsigned long oldest_jif;
         ...
         work->older_than_this = &oldest_jif;
         ...
    }

    static int move_expired_inodes(struct list_head *delaying_queue,
                                   struct list_head *dispatch_queue,
                                   int flags,
                                   struct wb_writeback_work *work)
    {
         unsigned long *older_than_this = NULL;
         ...
         older_than_this = work->older_than_this;
         ...
         if (older_than_this &&
             inode_dirtied_after(inode, *older_than_this))
             break;
         ...
    }

The address of a local stack element is written to the wb_writeback_work 
object
retrieved from the work list in wb_do_writeback. If the auto_free 
property of
the object is not set, it will not be freed upon returning from the 
calling
function, which results in our tool reporting the situation as a 
vulnerability.

The pointer is dereferenced in move_expired_inodes, and passed as an 
argument to
inode_dirtied_after. Currently, this does not appear to be exploitable. 
We
investigated the issue, but were unable to falsify our report, hence 
this email.
Apologies, if we overlooked something trivial or failed to adhere to the 
code of
conduct on this mailing list.

Best wishes,
David Gens

                 reply	other threads:[~2016-11-29 13:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1873d8cd6e20ef0ecc62cacb9d2582f@rbg.informatik.tu-darmstadt.de \
    --to=david.gens@cs.tu-darmstadt.de \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).