public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre JUHEN <pierre.juhen@orange.fr>
To: Coly Li <colyli@suse.de>, Rolf Fokkens <rolf@rolffokkens.nl>
Cc: Nix <nix@esperi.org.uk>, linux-block@vger.kernel.org
Subject: Re: [RFC PATCH] bcache: fix stack corruption by PRECEDING_KEY()
Date: Sun, 9 Jun 2019 07:56:40 +0200	[thread overview]
Message-ID: <bf1ccdb8-2a32-e69b-f52e-0b4fa45fe18f@orange.fr> (raw)
In-Reply-To: <777da4cb-2d11-9bcc-b56f-e59265b8c76d@suse.de>

Le 09/06/2019 à 02:59, Coly Li a écrit :
> On 2019/6/9 2:50 上午, Rolf Fokkens wrote:
>> On 6/8/19 12:22 PM, Coly Li wrote:
>>> +static inline void preceding_key(struct bkey *k, struct bkey
>>> *preceding_key_p)
>>> +{
>>> +    if (KEY_INODE(k) || KEY_OFFSET(k)) {
>>> +        *preceding_key_p = KEY(KEY_INODE(k), KEY_OFFSET(k), 0);
>>> +        if (!preceding_key_p->low)
>>> +            preceding_key_p->high--;
>>> +        preceding_key_p->low--;
>>> +    } else {
>>> +        preceding_key_p = NULL;
>> If I'm correct, the line above has no net effect, it just changes a
>> local variable (parameter) with no effect elsewhere. So the else part
>> may be left out, or do you mean this?
>>
>> *preceding_key_p = ZERO_KEY;
>>
> Hi Rolf and Pierre,
>
> Setting preceding_key_p to NULL is for the following
> bch_btree_iter_init(). See the call chains
>
> bch_btree_insert_key()->bch_btree_iter_init()->
> __bch_btree_iter_init()->bch_bset_search()
>
> preceding_key_p is parameter 'search' in bch_bset_search().
> If it is NULL, t->data->start returns directly; if it is not NULL,
> __bch_bset_search() is called.
>
> Indeed *preceding_key_p = ZERO_KEY is unnecessary, just makes me
> comfortable. The problem is PRECEDING_KEY() allocates an on-stack
> variable, and this one is overlapped with stackframe of
> bch_btree_iter_init(), and overwritten. Because this anonymous on-stack
> variable is allocated inside PRECEDING_KEY(), not (and should not be)
> protected by compiler.
>
> So I add the new local variable preceding_key (and make preceding_key_p
> points to it) explicitly on stack frame of bch_btree_insert_key(), which
> will never be overlapped with stackframe of bch_btree_iter_init().
>
> Thanks.

HI,


so the right line should be :

*preceding_key_p = NULL;

because Rolf is right

preceding_key_p = NULL;

does change only the value of the calling parameter and exits, not the 
value of the preceding key in the stack.




  reply	other threads:[~2019-06-09  5:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08 10:22 [RFC PATCH] bcache: fix stack corruption by PRECEDING_KEY() Coly Li
2019-06-08 18:50 ` Rolf Fokkens
2019-06-08 21:52   ` Pierre JUHEN
2019-06-09  0:59   ` Coly Li
2019-06-09  5:56     ` Pierre JUHEN [this message]
2019-06-09  8:23       ` Coly Li
2019-06-09  9:21 ` Coly Li
2019-06-09 10:46   ` Pierre JUHEN
2019-06-09 12:16     ` Coly Li

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=bf1ccdb8-2a32-e69b-f52e-0b4fa45fe18f@orange.fr \
    --to=pierre.juhen@orange.fr \
    --cc=colyli@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=nix@esperi.org.uk \
    --cc=rolf@rolffokkens.nl \
    /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