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 6D1A2C02198 for ; Tue, 18 Feb 2025 05:41:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C1242800E1; Tue, 18 Feb 2025 00:41:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 670732800DF; Tue, 18 Feb 2025 00:41:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 538B22800E1; Tue, 18 Feb 2025 00:41:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 352B52800DF for ; Tue, 18 Feb 2025 00:41:05 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9B6F11602F3 for ; Tue, 18 Feb 2025 05:41:04 +0000 (UTC) X-FDA: 83131966848.08.F186510 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by imf22.hostedemail.com (Postfix) with ESMTP id BEA72C0002 for ; Tue, 18 Feb 2025 05:41:02 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L52KX144; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@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=1739857262; 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:in-reply-to:references:references:dkim-signature; bh=MifYh++JAuvD0qZvmXaJQvX960rDJK4fzbBnF35BdDY=; b=Q2lnYeUHz92gJSefwjmb0NtPHbiYyLc+tC3Exkaw08dvcXFeQ+na+Q3Thhst4trZGh5pGW onlbmifDlmf2TC1YgFxp74J6qwdajIQyOkPBDYQ/GPNeOZcx6jgDSi8MxPwVQLVQr2D2HM pax4uZS0gFpsRNZ7RLPTbZcnI8gDe0Y= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L52KX144; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739857262; a=rsa-sha256; cv=none; b=hIq80nxy/MTDaoLMpm4gMUIhq9tWOUQ1x5cpu4W00KlsCN6L312/v3c94y6ls6yml79PKu SciEwuc2YLddjYPokRYYMqJRtFJDQPUNMejWBLWb7fnlnEPMpPQiGmLDPeW8tdbjJv40wF AcgB7iYltuGghkQDMPnFPGX4GwRdm4U= Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-4be5033a2cbso983078137.1 for ; Mon, 17 Feb 2025 21:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739857262; x=1740462062; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MifYh++JAuvD0qZvmXaJQvX960rDJK4fzbBnF35BdDY=; b=L52KX144mjDSJ3fpeqhU03MJJZWPg7Rouz4NeYAXkWf5BYbPJDfPhlpSX+TCK4tLns 5KdCeRO06iTx/HZgJEu4mtnrdBxgCiVQzpEYz0LWNiCr7BjnBYMmAsJ6eiyCn8Z5cY7D ccR/hUczzgXC1oN7AjDuwyxWzlC+WumHbMb+bxxayuoY8gDPraX0FOiFx/2XhirmF6c+ 9tF2axuOUVHiyHN8iphwI1rQJHI1mz8f+AoiGfpSNV/6IvJRp/0T5JHdwuuApJuhX+HQ LCcQ2s6NnqcAkwWWAJdnIXIJZFVwRQgxl8wQmZrQQVOnQDbP2fuhSNmee4f6oKbNJi0m gOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739857262; x=1740462062; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MifYh++JAuvD0qZvmXaJQvX960rDJK4fzbBnF35BdDY=; b=JYJ5n3es4OaDsGPtN5GbFL3IQ2y7JckPoYpyt64XD20ExuuETngrxBGrVWiHKnngfY h+6xAHWLSJ8NMIJlROYbvfHSSd42YR6vzeUL46nVmaqt67hqpuHEOIGTrKwMVEcvmVEH CaWKOt0PXQ2ks40VX8f0Ga3DHNbrNTX16N4V/BddfjDXEUGZwqfYnT1wHfqeQZSC7W4P 0r6z+1sVwBneU/YwKAe/TRNgR1jmLBCsnRK1HUncXs06l9/XPcER+yEqJPIwgoZZLiNw cZdxwphNRNH7hfBP9F1sHHKAvEw/KqAddLCjZAL9XyButYhFE1XYYkpppz4z2r3gqz2N SCCA== X-Forwarded-Encrypted: i=1; AJvYcCU6/d55Ue7e60EHDxMCWmkNn7kxf9GkvxC5Q9rI4veCDnDe++naJjTw6WhZEeWAS2P0SY7BOUjhPw==@kvack.org X-Gm-Message-State: AOJu0YxETErkBDsXtUtN5YKLsQmX1yACztYpbgYM5rIQ4kR7bUkvdXay 1f+tIHFApGs+PtwIC84TFOd45/cXxJ4L6CvGG5uVBz5GzD5JRMAn7j5T8RBm61ChIy349UWqOCB 4oEldZC+L8hi4PiQabEYWAMc0Vxk= X-Gm-Gg: ASbGncu+GntR+TlQpZOfYYnxuKBJFT3DhtSZaTGBrkxAVh1cT7aah1Nc2JnkDixvUR0 Qpx2pPthnleICp40xG8S+RXq+XkKoo2Pb6pq6wQEFvGT+tcoeVRK2iB1wT6r17T2s7UmIZraf X-Google-Smtp-Source: AGHT+IGR7ulYUkokYF6mOlYBL+Q9buDJnVmvFe9JxfmdfiSj3xbT9BLP20AyUrpmZXe7JuKrQ3wm4zhEQsRVNWwXQ4Q= X-Received: by 2002:a05:6102:442b:b0:4bb:cf25:c5a7 with SMTP id ada2fe7eead31-4bd3fd4882amr6529257137.7.1739857261737; Mon, 17 Feb 2025 21:41:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 18 Feb 2025 18:40:49 +1300 X-Gm-Features: AWEUYZmrzTbh2ql9JksTax0dFkC3yuh-suhge5VV8sP3McTaFwVSAJzAWWlPK10 Message-ID: Subject: Re: [PATCH v3] mm: Fix possible NULL pointer dereference in __swap_duplicate To: gaoxu Cc: Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Suren Baghdasaryan , Yosry Ahmed , yipengxiang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BEA72C0002 X-Stat-Signature: u4an3erc5xgsqbbcka7xzpjzh3zznsf8 X-HE-Tag: 1739857262-429819 X-HE-Meta: U2FsdGVkX1+h0DB8ivHkgvi3lkHeVp/EvA0CxnaAvTEYnRKGDcsEReUB06PSaSSuJtGa3a4F0TMMUPiWP5tZklFIWO0tlu7pZImjxn6JGkt9ZK9AUDY6kud9sp1PCVUjD3DqrKmSyluhw4DmwSGllso205st0OyKu7AMc+QuvRGniQx+85KGrvNYBZT3YAhONPFaY7/go3XYgvAuqix9KciQnl2Gqt8uBXQGknRf/GZkQ3P/VZIJ6NjlUXxhODJ2krHPyGchHV4DzXWybtLLKk8ED9DHtN2+g0VqNI4OlqU1LWJbPmPmz9E1F6oAiyYnMvBEAQhSexRhty6bzrCzU4eiAB+fGk3FbxYo14EaIyLE9MXw+vRLxzH5BeNE+j0gv+8QNraCLii+kTR6s65g9i+yyMh+wCxD6kWjwgCASDOFMZIPBUnQdWa/l5AFJABbQg9PND7JOLbQujmyLsIlL2F8vwCwJu6Wu/Zqvq4cRT0hdJHnimyHi31h3+8LD7IrVYXQLta/5t47d0KGGODwJp6gi0D7dAP0J4zJ5pffYwLuiepGSEcrAhAYPqqwCg1aLNfM6PH3DWB73OgLEBdhoRbNYjKWJmA45VtCXj9tO+/pctYPOhf4f1O67+qb6kA3/NDOYNLYbMIu+V0npHPsVqBiFMUDDZE5s68OUexzB1CFzP/D/n41VK8S6gMiuHl8jMK+8dAgl2P0eTAu7izD1Sc78c0M8sVeC8R6OVNfCbS/Lt5YgAyHhNRhV2tScD5FPlCJMDGyFuS/nvpTdE9oW4UB2cSTKZRt50IFb1Nrn1kywRvRsrv4IpJK3i4UCS4FQOa1e/RbH+8ifwzjk4iMbnOIIM2K2oDfXXK5vml4jNeGlc+9oe59IpL3GO31Mo39m0/3t+UD6MNeVv8lBiV09ckDq3r+p568GZfyl5PXEbL5khq9ynaxqvrPWKb/wIWmcInclkd8JhIz8+w09Ur 6McL9i8D Vlki0OMEc8KD9EEFbScG1JyVfMSvlAMVOC4DpehwY/AL3h3x7pesC9PQEJ1MzxPdpEMi4bkc1Zmn42bb1URQOHviwLvN23F7y7eMnhf74UrXVjQxrpFSGK9ZqPS4ZUuH68Z2tGe4uetg3jTM/l2XFi5W6nwN52tncl/KZwyMK29TWEiEK5bnDgzFJ9OvN9a5K1Qfn0LGWeokKDUinJ0cTeS4RuRxPIulR3g0cl6jL6TcczlOodeWt1PqcqEBTR+mOmoHT6GX7PYnup4b74qYziguCKuLOu4Qo1i1YXgECpXJAdi4wyiMcAgzXPWcnag1dg8IX+7zwhvlKnvtMeoXm8UC1DBvbV5uGhJkO6b30OhhBjtfpVtap4EtQ+nmS2O27rzO+D22BtciPgfSA1n2UjTYMix7QNb1Pg/7w0tNNyeSCfTZZNCz683Y0/2Sh/tqq7RP76UPTelLKWGBvN1rIEGxxOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Thank you! On Tue, Feb 18, 2025 at 3:51=E2=80=AFPM gaoxu wrote: > > > > > On Sat, Feb 15, 2025 at 10:05=E2=80=AFPM gaoxu wrote= : > > > > > > Add a NULL check on the return value of swp_swap_info in > > > __swap_duplicate to prevent crashes caused by NULL pointer dereferenc= e. > > > > > > The reason why swp_swap_info() returns NULL is unclear; it may be due > > > to CPU cache issues or DDR bit flips. The probability of this issue i= s > > > very small, and the stack info we encountered is as follows=EF=BC=9A > > > Unable to handle kernel NULL pointer dereference at virtual address > > > 0000000000000058 > > > [RB/E]rb_sreason_str_set: sreason_str set null_pointer Mem abort info= : > > > ESR =3D 0x0000000096000005 > > > EC =3D 0x25: DABT (current EL), IL =3D 32 bits > > > SET =3D 0, FnV =3D 0 > > > EA =3D 0, S1PTW =3D 0 > > > FSC =3D 0x05: level 1 translation fault Data abort info: > > > ISV =3D 0, ISS =3D 0x00000005, ISS2 =3D 0x00000000 > > > CM =3D 0, WnR =3D 0, TnD =3D 0, TagAccess =3D 0 > > > GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 user pgtable: 4k= pages, > > > 39-bit VAs, pgdp=3D00000008a80e5000 [0000000000000058] > > > pgd=3D0000000000000000, p4d=3D0000000000000000, > > > pud=3D0000000000000000 > > > Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Skip md ftrac= e > > > buffer dump for: 0x1609e0 ... > > > pc : swap_duplicate+0x44/0x164 > > > lr : copy_page_range+0x508/0x1e78 > > > sp : ffffffc0f2a699e0 > > > x29: ffffffc0f2a699e0 x28: ffffff8a5b28d388 x27: ffffff8b06603388 > > > x26: ffffffdf7291fe70 x25: 0000000000000006 x24: 0000000000100073 > > > x23: 00000000002d2d2f x22: 0000000000000008 x21: 0000000000000000 > > > x20: 00000000002d2d2f x19: 18000000002d2d2f x18: ffffffdf726faec0 > > > x17: 0000000000000000 x16: 0010000000000001 x15: 0040000000000001 > > > x14: 0400000000000001 x13: ff7ffffffffffb7f x12: ffeffffffffffbff > > > x11: ffffff8a5c7e1898 x10: 0000000000000018 x9 : 0000000000000006 > > > x8 : 1800000000000000 x7 : 0000000000000000 x6 : ffffff8057c01f10 > > > x5 : 000000000000a318 x4 : 0000000000000000 x3 : 0000000000000000 > > > x2 : 0000006daf200000 x1 : 0000000000000001 x0 : 18000000002d2d2f Cal= l > > > trace: > > > swap_duplicate+0x44/0x164 > > > copy_page_range+0x508/0x1e78 > > > > This is really strange since we already have a swap entry check before = calling > > swap_duplicate(). > > > > copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, > > pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct > > *dst_vma, > > struct vm_area_struct *src_vma, unsigned long addr, int > > *rss) { > > unsigned long vm_flags =3D dst_vma->vm_flags; > > pte_t orig_pte =3D ptep_get(src_pte); > > pte_t pte =3D orig_pte; > > struct folio *folio; > > struct page *page; > > swp_entry_t entry =3D pte_to_swp_entry(orig_pte); > > > > if (likely(!non_swap_entry(entry))) { > > if (swap_duplicate(entry) < 0) > > return -EIO; > > ... > > } > > > > likely the swap_type is larger than MAX_SWAPFILES so we get a NULL? > > > > static struct swap_info_struct *swap_type_to_swap_info(int type) { > > if (type >=3D MAX_SWAPFILES) > > return NULL; > > > > return READ_ONCE(swap_info[type]); /* rcu_dereference() */ } > > > > But non_swap_entry() guarantees that swp_type is smaller than > > MAX_SWAPFILES. > > > > static inline int non_swap_entry(swp_entry_t entry) { > > return swp_type(entry) >=3D MAX_SWAPFILES; } > > > > So another possibility is that we have an overflow of swap_info[] where= type is < > > MAX_SWAPFILES but is not a valid existing swapfile? > In the log of this issue, there is a printed entry: get_swap_device: > Bad swap file entry 18000000002d2d2f. > It can be calculated that swp_type(18000000002d2d2f) =3D 6. > In the Android 15-linux6.6: > system: MAX_SWAPFILES =3D 28, nr_swapfiles =3D 1. > Since swp_type(18000000002d2d2f)=3D6 is less than MAX_SWAPFILES but great= er > than nr_swapfiles, the value of this entry is abnormal. > > static unsigned int nr_swapfiles; > static struct swap_info_struct *swap_info[MAX_SWAPFILES]; > swap_info is a static array, with its values initialized to 0. > The size of the array is MAX_SWAPFILES, and the size of valid values in t= he array is > nr_swapfiles. Therefore, when we validate the validity of swp_type(entry)= , > we should compare it with nr_swapfiles, not MAX_SWAPFILES. > The code for validating swp_type may need to be modified as follows: That might be true, but on a normal system, we only need to distinguish between a swap entry and a migrate entry. Therefore, comparing with MAX_SWAPFILES is sufficient. > static inline int non_swap_entry(swp_entry_t entry) > { > - return swp_type(entry) >=3D MAX_SWAPFILES; > + return swp_type(entry) >=3D nr_swapfiles; > } > > static struct swap_info_struct *swap_type_to_swap_info(int type) > { > - if (type >=3D MAX_SWAPFILES) > + if (type >=3D nr_swapfiles) > return NULL; > > return READ_ONCE(swap_info[type]); /* rcu_dereference() */ > } > > > > I don't see how the current patch contributes to debugging or fixing an= ything > > related to this dumped stack. Can we dump swp_type() as well? > > > > > copy_process+0x1278/0x21cc > > > kernel_clone+0x90/0x438 > > > __arm64_sys_clone+0x5c/0x8c > > > invoke_syscall+0x58/0x110 > > > do_el0_svc+0x8c/0xe0 > > > el0_svc+0x38/0x9c > > > el0t_64_sync_handler+0x44/0xec > > > el0t_64_sync+0x1a8/0x1ac > > > Code: 9139c35a 71006f3f 54000568 f8797b55 (f9402ea8) ---[ end trace > > > 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal > > > exception > > > SMP: stopping secondary CPUs > > > > > > The patch seems to only provide a workaround, but there are no more > > > effective software solutions to handle the bit flips problem. This > > > path will change the issue from a system crash to a process exception= , > > > thereby reducing the impact on the entire machine. > > > > > > Signed-off-by: gao xu > > > --- > > > v1 -> v2: > > > - Add WARN_ON_ONCE. > > > - update the commit info. > > > v2 -> v3: Delete the review tags (This is my issue, and I apologize). > > > --- > > > > > > mm/swapfile.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/mm/swapfile.c b/mm/swapfile.c index 7448a3876..a0bfdba94 > > > 100644 > > > --- a/mm/swapfile.c > > > +++ b/mm/swapfile.c > > > @@ -3521,6 +3521,8 @@ static int __swap_duplicate(swp_entry_t entry, > > unsigned char usage, int nr) > > > int err, i; > > > > > > si =3D swp_swap_info(entry); > > > + if (WARN_ON_ONCE(!si)) > > > > I mean, printk something related to swp_type(). This is really strange,= but the > > current stack won't help with debugging. > The log can find info related to "get_swap_device: Bad swap file entry xx= x" > when an entry encounters an exception. > Add a print info log like the following: > pr_err("%s%08d\n", Bad swap type, swp_type(entry)); This is really strange. It would be better to have the entire PTE value dumped so we can determine if a bit-flip occurred on critical bits like PTE_PRESENT. In that case, a present PTE could be misinterpreted as a swap entry. On arm64, /* * Encode and decode a swap entry: * bits 0-1: present (must be zero) * bits 2: remember PG_anon_exclusive * bits 3-7: swap type * bits 8-57: swap offset * bit 58: PTE_PROT_NONE (must be zero) */ #define __SWP_TYPE_SHIFT 3 #define __SWP_TYPE_BITS 5 #define __SWP_OFFSET_BITS 50 #define __SWP_TYPE_MASK ((1 << __SWP_TYPE_BITS) - 1) #define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT) #define __SWP_OFFSET_MASK ((1UL << __SWP_OFFSET_BITS) - 1) _swp_type is bits3-7. For a present pte, bits 3-7 are: AP[7-6], NS[5], AttributeIndex[4-2]. > > > > > + return -EINVAL; > > > > > > offset =3D swp_offset(entry); > > > VM_WARN_ON(nr > SWAPFILE_CLUSTER - offset % > > SWAPFILE_CLUSTER); > > > -- > > > 2.17.1 Thanks Barry