linux-kernel - Re: [PATCH v4] livepatch: introduce shadow variable API

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: <d9328f8d-3299-a166-36a1-3122ed616cf5@redhat.com>
Date:   Fri, 18 Aug 2017 09:46:08 -0400
From:   Joe Lawrence <joe.lawrence@...hat.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jessica Yu <jeyu@...hat.com>, Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH v4] livepatch: introduce shadow variable API

On 08/17/2017 10:05 AM, Petr Mladek wrote:
> On Mon 2017-08-14 16:02:43, Joe Lawrence wrote:
>> [ ... snip ... ]
>> diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
>> new file mode 100644
>> index 000000000000..5acc838463d1
>> --- /dev/null
>> +++ b/samples/livepatch/livepatch-shadow-fix1.c
>> +void livepatch_fix1_dummy_free(struct dummy *d)
>> +{
>> +	void **shadow_leak;
>> +
>> +	/*
>> +	 * Patch: fetch the saved SV_LEAK shadow variable, detach and
>> +	 * free it.  Note: handle cases where this shadow variable does
>> +	 * not exist (ie, dummy structures allocated before this livepatch
>> +	 * was loaded.)
>> +	 */
>> +	shadow_leak = klp_shadow_get(d, SV_LEAK);
>> +	if (shadow_leak) {
>> +		klp_shadow_detach(d, SV_LEAK);
>> +		kfree(*shadow_leak);
> 
> This should get removed. The buffer used for the shadow variable
> is freed by kfree_rcu() called from klp_shadow_detach().
> 
> Same problem is also in the other livepatch.
> 
>> +		pr_info("%s: dummy @ %p, prevented leak @ %p\n",
>> +			 __func__, d, *shadow_leak);
> 
> This might access shadow_leak after it was (double) freed.
> 
>> +	} else {
>> +		pr_info("%s: dummy @ %p leaked!\n", __func__, d);
>> +	}
>> +
>> +	kfree(d);
>> +}

Hi Petr,

I think you're half correct.

The kfree is the crux of the memory leak patch, so it needs to stay.
However, the shadow variable is holding a copy of the pointer to the
memory leak area, so you're right that it can't be safely dereferenced
after the shadow variable is detached*.

The code should to be rearranged like:

void livepatch_fix1_dummy_free(struct dummy *d)
{
        void **p_shadow_leak, *shadow_leak;

        p_shadow_leak = klp_shadow_get(d, SV_LEAK);
        if (p_shadow_leak) {
                shadow_leak = *p_shadow_leak;   << deref before detach
                klp_shadow_detach(d, SV_LEAK);
                kfree(shadow_leak);
        ...

* Aside: I usually develop with slub_debug=FZPU set to catch silly
use-after-frees like this.  However, since the shadow variable is
released via kfree_rcu(), I think there was a window before the grace
period where this one worked out okay...  once I added a
synchronize_rcu() call in between the klp_shadow_detch() and kfree()
calls, I did see the poison pattern.  This is my first time using
kfree_rcu(), so it was interesting to dig into.

Thanks,

-- Joe