Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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.
Thread-Topic: [PATCH v2] lzo: fix ip overrun during compress.
Thread-Index: AQHUhuxfhCM/itRkZUmE23ES7mjh0qVlNWoAgAkytACAARlyAA==
Date:   Wed, 5 Dec 2018 03:07:58 +0000
Message-ID: <SN1PR13MB030484F09EE8A00DB094CDFADFA80@SN1PR13MB0304.namprd13.prod.outlook.com>
References: <BLUPR13MB0289EFEB79833470EE62F48EDFD10@BLUPR13MB0289.namprd13.prod.outlook.com>
 <20181128135242.gy3avmbp2pdmjaka@twin.jikos.cz>
 <5C0654EE.5040001@oberhumer.com>
In-Reply-To: <5C0654EE.5040001@oberhumer.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:  [Yb5Ox/83svVV3pYk/IoNaSJKzAJwONhj]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BN3NAM04HT023;6:kzjYXkEx/6DDyU1lBH6v/Kdh/exqlQule+FmqofjKmcd5Ylkh42tdZdKjyFv9zfEQKC/bDZHBh0eD07Vzs0uuN41j/KxFft8ouZw5p6dWNibvHIRq30Qo0I8EYTV0rC3GUI+cyAlnSm5awYcxYWZTkf+rxFpx2DS491b2xR5ptaVaG2tPGVY0El3xlfbZpjeC8uDZd+gv3Boi/5nHK6xtVIEA66ZFMyfv/UwNal5rDjfsSn4vt+nXEGqLsfxvbDK9V3lrEyejPI+7jWJhSodKPmh/OMQRDnTAOqdqDXSSYmDeLBaZ4nMOyp3ZkKVrhq/tggdSfFDA5LV/6RL6mtx22VgFhehNSpq6rIMbYbKAF2whkFo4FJqVpw2rrr+R5e+KWSfhdY75FzE368ZbozigLUh20q+Gr3yhNQIAaXNiqG7TF+oEkYwde+0glTwbujW+xfYq7vqEVqflZtG7GYHCg==;5:Zrh+/GMKD12Vti1Gnkm/2EEQjByZATnc7JKhsNUVkCFs42Ww6vfLzGM3nHVkhffIxx2BFdk66qjwonod0DYxxUmWFKHGPKBYNaWR0VDqh1X3MMa44Y8rNgOGPMHqelm/rQ9jryPpHlyjWwnJuwhJ9gcxu39jZVnmAbMxgAvpbLY=;7:fIgk411clJ7rI1/cscbKZhOXi8VoO/zIagq/lQWOdZ3oYi7L5/SkUVfaJzD+pTYsXYJ/BBrTh2/kvx8/rX18E2iSC5FmR8V7IyeGg5EOLRieL0iWN7dcS5m2pX8NQ93Ub41Qgc82Z5/U0Bz3LplMRw==
x-incomingheadercount: 50
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390098)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045);SRVR:BN3NAM04HT023;
x-ms-traffictypediagnostic: BN3NAM04HT023:
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(4566010)(82015058);SRVR:BN3NAM04HT023;BCL:0;PCL:0;RULEID:;SRVR:BN3NAM04HT023;
x-microsoft-antispam-message-info: pFTvcd5vqCxIL8SKBEf/TWMMfMhhOV6U9kgvstQM7OqL1d15PUfTiRGuTNiSWEtf
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <134CC919548DFB49A9286CA73E1EAB66@namprd13.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: live.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: f12efbb0-867f-4c93-8261-502eceebfafa
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f25aeed-6c9c-40de-b4b8-08d65a5edb0a
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: f12efbb0-867f-4c93-8261-502eceebfafa
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2018 03:07:58.3154
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT023
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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=20
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,
>  =20
>          while (l > 20) {
>                  size_t ll =3D l <=3D (M4_MAX_OFFSET + 1) ? l : (M4_MAX_O=
FFSET + 1);
> -               uintptr_t ll_end =3D (uintptr_t) ip + ll;
> -               if ((ll_end + ((t + ll) >> 5)) <=3D ll_end)
> +               // check for address space wraparound
> +               if (((uintptr_t) ip + ll + ((t + ll) >> 5)) <=3D (uintptr=
_t) ip)
>                          break;
>                  BUILD_BUG_ON(D_SIZE * sizeof(lzo_dict_t) > LZO1X_1_MEM_C=
OMPRESS);
>                  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 =3D 0xFFFFFFFFFFFFF000,
     |  ?,
     |    out =3D 0xFFFFFFFF2E2EE000,
     |    out_len =3D 0xFFFFFF801CAA3510,
     |  ?,
     |    wrkmem =3D 0xFFFFFFFF4EBC0000)
     |  dict =3D 0xFFFFFFFF4EBC0000
     |  op =3D 0x1
     |  ip =3D 0x9
     |  ii =3D 0x9
     |  in_end =3D 0x0
     |  ip_end =3D 0xFFFFFFFFFFFFFFEC
     |  m_len =3D 0
     |  m_off =3D 1922
-001|lzo1x_1_compress(
     |    in =3D 0xFFFFFFFFFFFFF000,
     |    in_len =3D 0,
     |    out =3D 0xFFFFFFFF2E2EE000,
     |    out_len =3D 0x00000001616FB7D0,
     |    wrkmem =3D 0xFFFFFFFF4EBC0000)
     |  ip =3D 0xFFFFFFFFFFFFF000
     |  op =3D 0xFFFFFFFF2E2EE000
     |  l =3D 4096
     |  t =3D 0
     |  ll =3D 4096

ll =3D l =3D in_len =3D 4096 in lzo1x_1_compress,  so your patch is working=
=20
for this panic case, but, I`m
not sure, is it possible that in =3D 0xFFFFFFFFFFFFF000 and  in_len < 4096?


Thanks,
Yueyi