From: Yueyi Li <liyueyi@live.com>
To: "Markus F.X.J. Oberhumer" <markus@oberhumer.com>,
"dsterba@suse.cz" <dsterba@suse.cz>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"w@1wt.eu" <w@1wt.eu>,
"donb@securitymouse.com" <donb@securitymouse.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] lzo: fix ip overrun during compress.
Date: Wed, 12 Dec 2018 05:21:29 +0000 [thread overview]
Message-ID: <BLUPR13MB0289EC81589A10E95912675FDFA70@BLUPR13MB0289.namprd13.prod.outlook.com> (raw)
In-Reply-To: <5C093A30.4020705@oberhumer.com>
Hi Markus,
OK, thanks. I`ll change it in v3.
Thanks,
Yueyi
On 2018/12/6 23:03, Markus F.X.J. Oberhumer wrote:
> Hi Yueyi,
>
> yes, my LZO patch works for all cases.
>
> The reason behind the issue in the first place is that if KASLR
> includes the very last page 0xfffffffffffff000 then we do not have a
> valid C "pointer to an object" anymore because of address wraparound.
>
> Unrelated to my patch I'd argue that KASLR should *NOT* include the
> very last page - indeed that might cause similar wraparound problems
> in lots of code.
>
> Eg, look at this simple clear_memory() implementation:
>
> void clear_memory(char *p, size_t len) {
> char *end = p + len;
> while (p < end)
> *p++= 0;
> }
>
> Valid code like this will fail horribly when (p, len) is the very
> last virtual page (because end will be the NULL pointer in this case).
>
> Cheers,
> Markus
>
>
>
> On 2018-12-05 04:07, Yueyi Li wrote:
>> Hi Markus,
>>
>> Thanks for your review.
>>
>> On 2018/12/4 18:20, Markus F.X.J. Oberhumer wrote:
>>> Hi,
>>>
>>> I don't think that address space wraparound is legal in C, but I
>>> understand that we are in kernel land and if you really want to
>>> compress the last virtual page 0xfffffffffffff000 the following
>>> small patch should fix that dubious case.
>> I guess the VA 0xfffffffffffff000 is available because KASLR be
>> enabled. For this case we can see:
>>
>> crash> kmem 0xfffffffffffff000
>> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>> ffffffbfffffffc0 1fffff000 ffffffff1655ecb9 7181fd5 2
>> 8000000000064209 locked,uptodate,owner_priv_1,writeback,reclaim,swapbacked
>>
>>> This also avoids slowing down the the hot path of the compression
>>> core function.
>>>
>>> Cheers,
>>> Markus
>>>
>>>
>>>
>>> diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c
>>> index 236eb21167b5..959dec45f6fe 100644
>>> --- a/lib/lzo/lzo1x_compress.c
>>> +++ b/lib/lzo/lzo1x_compress.c
>>> @@ -224,8 +224,8 @@ int lzo1x_1_compress(const unsigned char *in, size_t in_len,
>>>
>>> while (l > 20) {
>>> size_t ll = l <= (M4_MAX_OFFSET + 1) ? l : (M4_MAX_OFFSET + 1);
>>> - uintptr_t ll_end = (uintptr_t) ip + ll;
>>> - if ((ll_end + ((t + ll) >> 5)) <= ll_end)
>>> + // check for address space wraparound
>>> + if (((uintptr_t) ip + ll + ((t + ll) >> 5)) <= (uintptr_t) ip)
>>> break;
>>> BUILD_BUG_ON(D_SIZE * sizeof(lzo_dict_t) > LZO1X_1_MEM_COMPRESS);
>>> memset(wrkmem, 0, D_SIZE * sizeof(lzo_dict_t));
>> I parsed panic ramdump and loaded CPU register values, can see:
>>
>> -000|lzo1x_1_do_compress(
>> | in = 0xFFFFFFFFFFFFF000,
>> | ?,
>> | out = 0xFFFFFFFF2E2EE000,
>> | out_len = 0xFFFFFF801CAA3510,
>> | ?,
>> | wrkmem = 0xFFFFFFFF4EBC0000)
>> | dict = 0xFFFFFFFF4EBC0000
>> | op = 0x1
>> | ip = 0x9
>> | ii = 0x9
>> | in_end = 0x0
>> | ip_end = 0xFFFFFFFFFFFFFFEC
>> | m_len = 0
>> | m_off = 1922
>> -001|lzo1x_1_compress(
>> | in = 0xFFFFFFFFFFFFF000,
>> | in_len = 0,
>> | out = 0xFFFFFFFF2E2EE000,
>> | out_len = 0x00000001616FB7D0,
>> | wrkmem = 0xFFFFFFFF4EBC0000)
>> | ip = 0xFFFFFFFFFFFFF000
>> | op = 0xFFFFFFFF2E2EE000
>> | l = 4096
>> | t = 0
>> | ll = 4096
>>
>> ll = l = in_len = 4096 in lzo1x_1_compress, so your patch is working
>> for this panic case, but, I`m
>> not sure, is it possible that in = 0xFFFFFFFFFFFFF000 and in_len < 4096?
>>
>>
>> Thanks,
>> Yueyi
>>
next prev parent reply other threads:[~2018-12-12 5:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 7:31 [PATCH v2] lzo: fix ip overrun during compress Yueyi Li
2018-11-28 13:52 ` David Sterba
2018-11-28 14:15 ` Willy Tarreau
2018-11-29 16:49 ` Dave Rodgman
2018-11-30 3:05 ` Yueyi Li
2018-11-30 12:20 ` Dave Rodgman
2018-12-03 2:46 ` Yueyi Li
2018-12-03 3:05 ` Yueyi Li
2018-12-04 10:20 ` Markus F.X.J. Oberhumer
2018-12-05 3:07 ` Yueyi Li
2018-12-06 15:03 ` Markus F.X.J. Oberhumer
2018-12-12 5:21 ` Yueyi Li [this message]
2018-12-12 12:35 ` Markus F.X.J. Oberhumer
2018-12-14 13:56 ` Richard Weinberger
2018-12-14 16:46 ` Kees Cook
2018-12-16 16:56 ` Markus F.X.J. Oberhumer
2018-12-18 9:25 ` Yueyi 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=BLUPR13MB0289EC81589A10E95912675FDFA70@BLUPR13MB0289.namprd13.prod.outlook.com \
--to=liyueyi@live.com \
--cc=donb@securitymouse.com \
--cc=dsterba@suse.cz \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@oberhumer.com \
--cc=w@1wt.eu \
/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).