From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C78BEC7619A for ; Sat, 8 Apr 2023 15:51:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD0316B0071; Sat, 8 Apr 2023 11:51:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B807F6B0074; Sat, 8 Apr 2023 11:51:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A483E6B0075; Sat, 8 Apr 2023 11:51:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 914276B0071 for ; Sat, 8 Apr 2023 11:51:39 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 563A014092E for ; Sat, 8 Apr 2023 15:51:39 +0000 (UTC) X-FDA: 80658663918.23.E9B9509 Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) by imf08.hostedemail.com (Postfix) with ESMTP id AB11E160005 for ; Sat, 8 Apr 2023 15:51:37 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=f47is1vb; spf=pass (imf08.hostedemail.com: domain of mail.dipanjan.das@gmail.com designates 209.85.160.46 as permitted sender) smtp.mailfrom=mail.dipanjan.das@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680969097; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=xbMqxWkswZ+j8vnTKs/LDwFFKDpT5yB5iqVFJaXrdK0=; b=AZcwmNjdyl08EUHEkIsl8S7Y+7gtktCYtI5Q+m1Iv1yBobXagAV/EmGUv8vrBqqQudI5RS pgvTkaTlyQR2D3pimafSbmflcLIGKopXq8U0Noq/4c476D0HTwJQu5QxFpiwk3d3WmnxAR 68zQSofq7AMwLxPP8F8p4Ci8RmNIdek= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=f47is1vb; spf=pass (imf08.hostedemail.com: domain of mail.dipanjan.das@gmail.com designates 209.85.160.46 as permitted sender) smtp.mailfrom=mail.dipanjan.das@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680969097; a=rsa-sha256; cv=none; b=PfXyRPbttAqZ5DrPyzCsao4BhaJA8sW3O5R3ZWJ3RxN+eseehejG7zjDaIhG2C7IYpKKpo gXafH9hpjmmuV8LJnmexCd7m38d8LX4fqCQu90qPfydADxhcZ4/2DGUWu/Ii49DMf3+5E8 7/Q7YRTTuTCbCNo9SG5BB7avK/6dY6U= Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-18412684c50so4530399fac.5 for ; Sat, 08 Apr 2023 08:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680969097; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xbMqxWkswZ+j8vnTKs/LDwFFKDpT5yB5iqVFJaXrdK0=; b=f47is1vb+JbkCQQfIXJ2m/c93n99bT/X424DtFyIruIHTQ6UWgZpe2Viw/V4xL2pLT gOIi7DNETja0ezD/QuncBUzcOum0e4Pb/g6Lkewu6wb0UdDlJzpWuIRCmOeuYtGE0EJK 5pkSmr0Y7HXrWawBdYBZZ8SHURQMA9w88I7UbDbUT9YCfFPSEl81eU6jkCh+ge06inVv P3jkP3n22C9zEmL6z3NzsfyYyGoMDv6e3LeHnDm73MVI25MmB+x92HuypFZQlricaw2x rn3Qo1qtu/5/94Xt2XEasV2gWuDj3BEpokdA5OtJfXV6FTOEmjCabGcAXmSbFfvt2Wpb kTfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680969097; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xbMqxWkswZ+j8vnTKs/LDwFFKDpT5yB5iqVFJaXrdK0=; b=cNVmmzVpJq5BrXKXVW5JsgR8NrOtUkVOWoghQfeRs1jV2UkPppVR5OaqMya2reZopO qFpPZ8MwYqtTOEOeAibfpyqMb8BUz+/WaucE6OYWG0I068v3y/DaOGwxNBrjpY7O8+9K jmomGPGGC/B7b7jsOMt5bnI7SXGNTlMKePKUT+oJ0Iacd0O2E5b9JN2w+a0hcihT5SBn YM9bLV7j7KQnAzx2FCmcEGZfdW90NiYFuwFqoyJViuhZMOpLYQ5AtKBPrhaULpjKhZVl hFJLH9xnynPbkZCMFZ9O/77ifRDR4BCKIhpMMPrC/GOFi5bjh2mj3urZ2TMQiLSf0EQG 9Qyg== X-Gm-Message-State: AAQBX9dBaNd15EMHnRn6dz2SSfd3PpErf+MK3GWrxnTX3NoMfNBxUwwk YexAc+ZNxg0QfnRizoR6TdsBD6bOhRyMZ9XxMws= X-Google-Smtp-Source: AKy350baogKz7qZ8DoqJQN/5M78y5On02n0InjTOAKSGKWAb3fNiOkPdlXCbi9UZCyTTVpjaYDSiWJOCsgNgFn6RMbQ= X-Received: by 2002:a05:6870:4184:b0:184:1a2c:83df with SMTP id y4-20020a056870418400b001841a2c83dfmr2001463oac.4.1680969096727; Sat, 08 Apr 2023 08:51:36 -0700 (PDT) MIME-Version: 1.0 From: Dipanjan Das Date: Sat, 8 Apr 2023 08:51:26 -0700 Message-ID: Subject: Possible incorrect handling of fault injection inside KMSAN instrumentation To: Alexander Potapenko , Marco Elver , Dmitry Vyukov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, Linux Kernel Mailing List Cc: syzkaller , Marius Fleischer , Priyanka Bose Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AB11E160005 X-Rspam-User: X-Stat-Signature: gmupu8ki95ob6831uzsgyjkwitmy4x83 X-HE-Tag: 1680969097-243036 X-HE-Meta: U2FsdGVkX1+uu9A2Un8TzdYujSH3wrElBoparFP2dFpXANLhioub9mIS6q7AzKEyXNJpNadnrTZFa6m/BPG7BrHLkTwbPtqdO7e3o9YO2HHSZblj0jobf4iGsKuvQqBMuj14F32PHDhDKE/tmMtC3Wc60CleyXDIBpJT3sMe1894Z2lUtVZWkHPQbcUC57TwWlvSGgjwHNlIg5fDkFizKTVUXj8wFCKlPMAhpCWbzuu5V9+L5/LIcZ8dl/PDmqet+3vex7w7ELfGsMBM8V0T0y5/k3M/MPxPAztetQhIdySJdIStzwFJul0V8SxFKH91j2wTMEU+BI6nI2/UudVekuj/wAyHd30s9CVd+Sbt/j5Yy5/WNnozASvNiYOzw/7gD5dJBddF5efDV46QIPKD98qyZ6i83I4fqvnR4jQNhCKelVz6i9MIHhYn5ewwnS64vWoNo2uF9P+TpSb/NXlqYGCLXByvqIye1p2iiGjK4TcP+6MXaefM4Wb5FmUhU0Nal6bHlfevMQ2jOGzKmjqD5jBdOoRQaqdkN2gvKGJXsrE3wMOh7BbkWbQWxFeNBnL4Vak7e0fRRNj69G6gP/KshtSolGse/FFXerbQ/kEPMxQi4Sx3noyG0JKfEe6ydDIWM+PIDhfjz//QBuoAUJz7fWfWFXtl+am66cAhCtjrTBevxUt6VMMa6aot1eyQFFXNBc2bgwaMWmzzPhMB3rPhDxeoESBHI9YMDXXmsBs9rpvo6Q8tIAyDcE8JUnqx9CHJ8EcSjvdFrF4yw6KkVHmht+tdowLz1k6T8XdTryBNZkP02Kc69QON+1OJxV9oq6++70UoTmIxKAaPe+6z+npDF+zeAo/w7rWGQSgvGcBxa9dOo5tcVZrxRMCj9MetHZNefMlpfuShRUqrz3LFWIMRgjrLL5LqeKKftB3nLBDqDY7N1C8/Qnn751KoaRZSa9F6k6gY3oQpQVt/FTIsrzZ Vuzh/lBs Sd6Ie4hWxD8iYC0z41fsKldRBeyphOAmMl5AvdmhEv5g1tfzpiL95lk+FEJq1pmfRGH01J1PqZDL9zdbAtoP2Zaey7KeEbw5NQeiC4XSFskGOquJcTZlEvuC3JfWs4xFVJ1Gr+k2wmOVs//J1108qkHv36/hnfYA2U/eGR4DnlmWb/tatBKj3AcoqD9sCYBh/EuvyAcpEoexNqpVxiFZsCnmQmyKL1F1AA+2tEWy9z+YjbeCxPSdHqn7XimAmkoOhpD4SrMsBBb2GFWRSafYZTVUE68aRm5vcWlMcHl+YTnRU3eiR3qjv8igpZYcRN/eLXZCT6tvhcvSO6Q+UVxg6f4j4Zkyx/3wqxT33LkcVJvKf1ZRyFJTSh9Y0r81Juw3FjJyj+sKLRk0Mw6sjJF1pkSE71i7Bn4jetvueaRZWOfzHS+uh63ZBgRsV6jsmKKmEJ+wjjBUMDEBH0m/13h/OB2ALsdSKSWZ1FnFBmkWRvWOZdo4Qk1YbkPhxrIUnXlW4wpIhzmw/AQ7QZrf/u+1Vl3xwYcQD7nYSRPKaKQzjlbcGJwI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000035, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, We would like to report a =E2=80=9Cpotential=E2=80=9D bug in the KMSAN inst= rumentation which has been found during the root-cause analysis of another bug discovered by our modified version of syzkaller. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D description: Possible incorrect handling of fault injection inside KMSAN instrumentation affected file: mm/kmsan/shadow.c kernel version: 6.2.0-rc5 kernel commit: 41c66f47061608dc1fd493eebce198f0e74cc2d7 git tree: kmsan kernel config: https://syzkaller.appspot.com/text?tag=3DKernelConfig&x=3Da9= a22da1efde3af6. The config has Fault Injection (FI) turned on, which is important in this case. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D We reported the =E2=80=9Csupposed=E2=80=9D bug discovered by our fuzzer her= e: https://groups.google.com/u/1/g/syzkaller/c/_83qwErVKlA. Initially, we presumed that the vzalloc() call (refer to Jiri Slaby=E2=80=99s comment on that thread) fails due to fault injection (refer to the reproducer attached). However, we were confused to see that the allocation failure triggers a crash, though clearly the driver code checks for allocation failures. Nonetheless, we reported the crash to the developers. Following Jiri=E2=80=99s comments, who evidently had the same impression as ours, we started investigating. Below is our observation. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D TL;DR: kmsan's allocation of shadow or origin memory in kmsan_vmap_pages_range_noflush() fails silently due to fault injection (FI). KMSAN sort of =E2=80=9Cswallows=E2=80=9D the allocation failure, and = moves on. When either of them is later accessed while updating the metadata, there are no checks to test the validity of the respective pointers, which results in a page fault. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Detail explanation: - In drivers/tty/n_tty.c:1879 (n_tty_open) , the driver calls vzalloc to allocate memory for ldata. - This triggers the KMSAN instrumentation to allocate the corresponding shadow and origin memory in mm/kmsan/shadow.c:236 (kmsan_vmap_pages_range_noflush) . - This allocation of the shadow memory fails (through fault injection). KMSAN checks for failure, frees the allocated memory and returns. Note: There is no return value signaling the error. Additionally, the pages for shadow and origin memory are not mapped at the addresses where KMSAN expects them to be (in fact, there are no pages that could be mapped at all since the allocation failed). - The allocation of the actual memory for the driver is successful. Therefore, vzalloc (from 1.) returns a valid pointer (not NULL). - After checking that the allocation succeeded (drivers/tty/n_tty.c:1880), the driver tries to dereference ldata and write to one of the fields at drivers/tty/n_tty.c:1883 (n_tty_open). - This triggers the KMSAN instrumentation to update the shadow/origin memory according to the write by calling __msan_metadata_ptr_for_store_8 which subsequently calls mm/kmsan/shadow.c:81 (kmsan_get_shadow_origin_ptr). - Since the address that the driver is trying to access is with the vmalloc range, this function will only calculate the offset of this pointer from the base of the vmalloc range and add this to the base of the shadow/origin memory range to retrieve the pointer for the corresponding shadow/origin memory. Note: there are no checks ensuring that this memory is actually mapped. - Next, after the return of __msan_metadata_ptr_for_store_8 , the instrumentation will try to update the shadow memory (or origin, we are not entirely confident which of the two. We think it is the shadow, but it also does not really change anything). Since this memory is not mapped, it leads to the crash. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Our conclusions/Questions: - Should KMSAN fail silently? Probably not. Otherwise, the instrumentation always needs to check whether shadow/origin memory exists. - Should KMSAN even be tested using fault injection? We are not sure. On one hand, the primary purpose of FI should be testing the application code. But also, inducing faults inside instrumentation clearly helps to find mistakes in that, too. - What is a fix for this? Should a failure in the KMSAN instrumentation be propagated up so that the kernel allocator (vzalloc() in this case) can =E2=80=9Cpretend=E2=80=9D to fail, too? --=20 Thanks and Regards, Dipanjan