Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: multipart/mixed; boundary="------------l85DkQMEZf392AV7IPgjfB9l"
Message-ID: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru>
Date:   Thu, 30 Mar 2023 20:48:46 +0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Content-Language: en-US
To:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc:     linux-mm@kvack.org,
        =?UTF-8?Q?Jakub_Mat=c4=9bna?= <matenajakub@gmail.com>,
        Hugh Dickins <hughd@google.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>
From:   stsp <stsp2@yandex.ru>
Subject: MREMAP_FIXED unmaps dest on error
Precedence: bulk

This is a multi-part message in MIME format.
--------------l85DkQMEZf392AV7IPgjfB9l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello.

The attached test-case demonstrates a
bug in mremap(). If MREMAP_FIXED is used
over an existing mapping and mremap() fails,
destination area gets unmapped.
AFAIK the failed syscall should have no
observable effects.

There is also another bug demonstrated by
the same test-case. Namely, it does 2 subsequent
mprotect()s on the same page, changing the
protection and restoring it back. But VMAs
are not merged, so the subsequent mremap()
fails (and exhibits a bug by unmapping dest).

--------------l85DkQMEZf392AV7IPgjfB9l
Content-Type: text/x-csrc; charset=UTF-8; name="mrtst2.c"
Content-Disposition: attachment; filename="mrtst2.c"
Content-Transfer-Encoding: base64

I2RlZmluZSBfR05VX1NPVVJDRQojaW5jbHVkZSA8c3lzL21tYW4uaD4KI2luY2x1ZGUgPGFz
c2VydC5oPgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxmY250bC5oPgojaW5jbHVk
ZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNp
bmNsdWRlIDxzaWduYWwuaD4KCiNpZm5kZWYgUEFHRV9TSVpFCiNkZWZpbmUgUEFHRV9TSVpF
IDQwOTYKI2VuZGlmCgpzdGF0aWMgdm9pZCBteV9zZWd2KGludCBzaWcpCnsKICAgIHByaW50
ZiAoIlRlc3QgRkFJTEVEXG4iKTsKICAgIF9leGl0IChFWElUX0ZBSUxVUkUpOwp9CgppbnQg
bWFpbih2b2lkKQp7CiAgICBjb25zdCBjaGFyICpmaWxlID0gIm1ydHN0Mi5jIjsKICAgIGNo
YXIgKmFkZHIsICphZGRyMiwgKmFkZHIzOwogICAgaW50IGZkOwoKICAgIGZkID0gb3BlbiAo
ZmlsZSwgT19SRE9OTFkpOwogICAgaWYgKGZkID09IC0xKQogICAgICAgIHJldHVybiBFWElU
X0ZBSUxVUkU7CiAgICBhZGRyID0gbW1hcCAoTlVMTCwgUEFHRV9TSVpFICogMiwgUFJPVF9S
RUFELCBNQVBfUFJJVkFURSwgZmQsIDApOwogICAgY2xvc2UoZmQpOwogICAgaWYgKGFkZHIg
PT0gTUFQX0ZBSUxFRCkgewogICAgICAgIHBlcnJvcigibW1hcCgpIik7CiAgICAgICAgcmV0
dXJuIEVYSVRfRkFJTFVSRTsKICAgIH0KICAgIGFkZHIyID0gbW1hcCAoTlVMTCwgUEFHRV9T
SVpFICogMiwgUFJPVF9SRUFEIHwgUFJPVF9XUklURSwKICAgICAgICAgICAgICAgICAgTUFQ
X0FOT05ZTU9VUyB8IE1BUF9QUklWQVRFLCAtMSwgMCk7CiAgICBpZiAoYWRkcjIgPT0gTUFQ
X0ZBSUxFRCkgewogICAgICAgIHBlcnJvcigibW1hcCgpIik7CiAgICAgICAgcmV0dXJuIEVY
SVRfRkFJTFVSRTsKICAgIH0KICAgIC8qIHNwbGl0IFZNQSB0byBmYWlsIG1yZW1hcCgpICov
CiAgICBtcHJvdGVjdCAoYWRkciwgUEFHRV9TSVpFLCBQUk9UX1JFQUQgfCBQUk9UX1dSSVRF
KTsKICAgIC8qIFZNQXMgd29uJ3QgYmUgbWVyZ2VkLCBidWcgKi8KICAgIG1wcm90ZWN0IChh
ZGRyLCBQQUdFX1NJWkUsIFBST1RfUkVBRCk7CiAgICAvKiBtYWtlIHN1cmUgZGVzdCBpcyBo
ZXJlIGFuZCB3cml0YWJsZSAqLwogICAgYWRkcjJbMF0gPSAzOwogICAgLyogZXhwb3NlIHRo
ZSBidWcgKi8KICAgIGFkZHIzID0gbXJlbWFwIChhZGRyLCBQQUdFX1NJWkUgKiAyLCBQQUdF
X1NJWkUgKiAyLAogICAgICAgICAgICAgICAgICAgIE1SRU1BUF9NQVlNT1ZFIHwgTVJFTUFQ
X0ZJWEVEIHwgTVJFTUFQX0RPTlRVTk1BUCwKICAgICAgICAgICAgICAgICAgICBhZGRyMik7
CiAgICBpZiAoYWRkcjMgPT0gYWRkcjIpIHsKICAgICAgICBwcmludGYgKCJFdmVuIFZNQXMg
bWVyZ2VkPyBFeGNlbGxlbnQhXG4iKTsKICAgICAgICByZXR1cm4gMDsKICAgIH0KICAgIGFz
c2VydCAoYWRkcjMgPT0gTUFQX0ZBSUxFRCk7CiAgICBzaWduYWwgKFNJR1NFR1YsIG15X3Nl
Z3YpOwogICAgLyogc2VlIGlmIGRlc3QgYWRkcmVzcyB1bm1hcHBlZCAqLwogICAgYWRkcjJb
MF0gPSA1OwogICAgYXNzZXJ0IChhZGRyMlswXSA9PSA1KTsKICAgIHByaW50ZiAoIlRlc3Qg
UEFTU0VEXG4iKTsKICAgIHJldHVybiAwOwp9Cg==

--------------l85DkQMEZf392AV7IPgjfB9l--