public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Andreas Dilger <adilger@dilger.ca>
Cc: David Howells <dhowells@redhat.com>,
	viro@zeniv.linux.org.uk, smfrench@gmail.com, jlayton@redhat.com,
	mcao@us.ibm.com, aneesh.kumar@linux.vnet.ibm.com,
	linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, samba-technical@lists.samba.org,
	sjayaraman@suse.de, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/3] Extended file stat functions [ver #2]
Date: Thu, 1 Jul 2010 10:09:32 +0200	[thread overview]
Message-ID: <201007011009.33197.arnd@arndb.de> (raw)
In-Reply-To: <84225B35-7365-4DE2-8920-5741011B347C@dilger.ca>

On Thursday 01 July 2010 06:57:07 Andreas Dilger wrote:
> If a future kernel gets a new static field at st_extra_results (say
> unsigned long long st_ino_high) with a new flag XSTAT_REQUEST_INO_HIGH
> 0x000040000ULL the kernel will think that the old app is requesting 
> this field, and will fill in the 64-bit field at st_extra_results[1]
> (which the old app didn't allocate space for, nor does it understand)
> and may get a segfault, or stack smashing, or random heap corruption.

That depends on whether the struct contains a 'buflen' field or not
(it may be part of the struct, as a syscall argument, or in a second struct).
I argue that it should not contain a buflen field and that users should
consequently not set bits that they don't know about to prevent the
scenario you describe.

If the buflen stays in, it will prevent the stack smashing part,
but add extra complexity in the interface, which can cause other
problems.

	Arnd

  reply	other threads:[~2010-07-01  8:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-30  1:16 [PATCH 0/3] Extended file stat functions [ver #2] David Howells
2010-06-30  1:17 ` [PATCH 1/3] Mark arguments to certain syscalls as being const " David Howells
2010-06-30  1:17 ` [PATCH 2/3] AFS: Use i_generation not i_version for the vnode uniquifier " David Howells
2010-06-30  1:17 ` [PATCH 3/3] Add a pair of system calls to make extended file stats available " David Howells
2010-06-30  1:48   ` Trond Myklebust
2010-06-30  9:33     ` Andreas Dilger
2010-06-30  9:47       ` David Howells
2010-06-30  2:32   ` Nicholas Miell
2010-06-30  8:30   ` Arnd Bergmann
2010-06-30  8:55     ` David Howells
2010-06-30  9:31       ` Arnd Bergmann
2010-06-30 10:01         ` David Howells
2010-06-30 11:46           ` Arnd Bergmann
2010-06-30 12:14             ` David Howells
2010-06-30 12:44               ` Arnd Bergmann
2010-06-30  9:45   ` Andreas Dilger
2010-06-30 10:22     ` David Howells
2010-06-30 11:04 ` [PATCH 0/3] Extended file stat functions " Andreas Dilger
2010-06-30 12:05   ` David Howells
2010-06-30 12:11     ` Christoph Hellwig
2010-06-30 12:23       ` David Howells
2010-06-30 13:31       ` Arnd Bergmann
2010-06-30 14:05         ` Jeff Layton
2010-06-30 17:36           ` Arnd Bergmann
2010-06-30 21:45     ` Andreas Dilger
2010-06-30 23:15       ` David Howells
2010-06-30 23:27         ` H. Peter Anvin
2010-07-01  0:15           ` David Howells
2010-07-01  3:20             ` H. Peter Anvin
2010-07-01  4:57         ` Andreas Dilger
2010-07-01  8:09           ` Arnd Bergmann [this message]
2010-07-05 23:52 ` Brad Boyer
2013-11-26 10:40 ` Jan Kara
2013-11-28 13:07   ` David Howells
2013-11-28 13:57     ` Jan Kara

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=201007011009.33197.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=adilger@dilger.ca \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcao@us.ibm.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sjayaraman@suse.de \
    --cc=smfrench@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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