Cover Letter Detail
Show a cover letter.
GET /api/covers/2232255/?format=api
{ "id": 2232255, "url": "http://patchwork.ozlabs.org/api/covers/2232255/?format=api", "web_url": "http://patchwork.ozlabs.org/project/ubuntu-kernel/cover/20260504041108.88774-1-matthew.ruffell@canonical.com/", "project": { "id": 15, "url": "http://patchwork.ozlabs.org/api/projects/15/?format=api", "name": "Ubuntu Kernel", "link_name": "ubuntu-kernel", "list_id": "kernel-team.lists.ubuntu.com", "list_email": "kernel-team@lists.ubuntu.com", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260504041108.88774-1-matthew.ruffell@canonical.com>", "list_archive_url": null, "date": "2026-05-04T04:10:55", "name": "[SRU,J,0/3] SUNRPC: System wide grep leads to NULL pointer deference in sysfs reads", "submitter": { "id": 76884, "url": "http://patchwork.ozlabs.org/api/people/76884/?format=api", "name": "Matthew Ruffell", "email": "matthew.ruffell@canonical.com" }, "mbox": "http://patchwork.ozlabs.org/project/ubuntu-kernel/cover/20260504041108.88774-1-matthew.ruffell@canonical.com/mbox/", "series": [ { "id": 502608, "url": "http://patchwork.ozlabs.org/api/series/502608/?format=api", "web_url": "http://patchwork.ozlabs.org/project/ubuntu-kernel/list/?series=502608", "date": "2026-05-04T04:10:58", "name": "SUNRPC: System wide grep leads to NULL pointer deference in sysfs reads", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/502608/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/2232255/comments/", "headers": { "Return-Path": "<kernel-team-bounces@lists.ubuntu.com>", "X-Original-To": "incoming@patchwork.ozlabs.org", "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.a=rsa-sha256 header.s=20251003 header.b=UkuK4ubz;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com\n (client-ip=185.125.189.65; helo=lists.ubuntu.com;\n envelope-from=kernel-team-bounces@lists.ubuntu.com;\n receiver=patchwork.ozlabs.org)" ], "Received": [ "from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g87WX1KN4z1yKW\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 04 May 2026 14:11:50 +1000 (AEST)", "from localhost ([127.0.0.1] helo=lists.ubuntu.com)\n\tby lists.ubuntu.com with esmtp (Exim 4.86_2)\n\t(envelope-from <kernel-team-bounces@lists.ubuntu.com>)\n\tid 1wJkeN-0001TJ-MP; Mon, 04 May 2026 04:11:19 +0000", "from smtp-relay-internal-0.internal ([10.131.114.225]\n helo=smtp-relay-internal-0.canonical.com)\n by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.86_2) (envelope-from <matthew.ruffell@canonical.com>)\n id 1wJkeM-0001TC-F5\n for kernel-team@lists.ubuntu.com; Mon, 04 May 2026 04:11:18 +0000", "from mail-pj1-f69.google.com (mail-pj1-f69.google.com\n [209.85.216.69])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 5977F3F221\n for <kernel-team@lists.ubuntu.com>; Mon, 4 May 2026 04:11:18 +0000 (UTC)", "by mail-pj1-f69.google.com with SMTP id\n 98e67ed59e1d1-3650a4eb60dso2187534a91.1\n for <kernel-team@lists.ubuntu.com>; Sun, 03 May 2026 21:11:18 -0700 (PDT)", "from Garunix (122-58-201-163-adsl.sparkbb.co.nz. [122.58.201.163])\n by smtp.gmail.com with ESMTPSA id\n 98e67ed59e1d1-364ec027690sm9665264a91.13.2026.05.03.21.11.14\n for <kernel-team@lists.ubuntu.com>\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Sun, 03 May 2026 21:11:16 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1777867878;\n bh=jOmWX+Cgly/2OCpEbJcO6kY557/08R/cqNOhSHfJiP8=;\n h=From:To:Subject:Date:Message-ID:MIME-Version;\n b=UkuK4ubzM2fQNvjgajyofoxs8lpAftt71zc7E+IIzSc09fN2FP+r+gDgvvSsoOuv0\n 8FsXtmrLo84MvO3qSNpvCX4zHnSWsltY6rw6/vKs+s4gKnyQklDw0R7Cy4ankH5cqG\n 7Ey2vIEGsM0WXMPmxGbf9FLFWENsjP+Z7t3iToWd+lbc8OBNOuNXEU0NXDQMmGkMWT\n ty6nc45jOtCvUmC5CF2M5kCigRTwdR2lPoHTZdqJkf8NSy77HRULxzY9zKNwOXlbZW\n jaUONyRCiNkZw7brZ1gF3tHb7RYq27bRJBYLq0Wk5XAOORZa4af/LJrkiZnwp+3+0E\n gH49/dp/dcDDW4zdSAQ5aIMJoCH1KOs9VwJ/+a6PyZZtACu46BtgdhZBrDHOCIOI4h\n wnbz/06ubn0hQD2Bisza0+5sUGoKtU0Dwvj79QsOAAiXt7JXsKgCUmzTNDkaoDp5/R\n LPUVTyeSxzTixzBmoh7rVU1SNc7aJXD3uj34D2z4jUIjH1yBnC1o/7rmu2TipOehZe\n pRRbTLW0hpAsOfuszG5vaa1mmt59e08qinJhxZcdnOaDHaMR7iq9xo6JMttlk3Rity\n Fh18xe7iBTFsgXp9/i6+bcEPcI/8iaruuuFnJ+T9Ggh6N4uKHx4/qtoW6bTd0cxMw8\n MRxNt8oFfGMfhK5YbaPYTmik=", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777867877; x=1778472677;\n h=content-transfer-encoding:mime-version:message-id:date:subject:to\n :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=jOmWX+Cgly/2OCpEbJcO6kY557/08R/cqNOhSHfJiP8=;\n b=N+Ah/lekpqq156MMllq8bjIf2v8hbr+vZpnylkaimH9XgtrRuECV5Ug+MCj5JJqeB0\n z0jO157hiqO83iP+JhUfu7oOFV9NMzRqz3DX3XdvC6JYkpup7tPLU/JJXWQb4XKbf/LQ\n a1vuYSCnsLfn0kgJX5TVs1KBN4iHl2Z94roxFygOHYgG7KXsUgr052Q0u4JEzbkjmqZn\n M2ErshhKDp0qJeEecrh0f5D/NMepFIJt8lkJEaxbK7A/AgH3R+Bfmc13w8e83HatthmM\n sPY6FuGcFVCLbjizPg8jj70Iv1eGXenHyq6qcqWH9k66ALOEUDp28DxOMsDOzW+oYwgi\n SZOg==", "X-Gm-Message-State": "AOJu0YwkNiBwrwdtDOEjHXvb6S+KZ0O+/YLq6xDgiWtErz2AJ3E4b0Ee\n HURPloSlDMF5ezNQ6odF67mRjpSe443dE/b6WSL9HS2i44tlFhcQwkSgjp03KJAj0baGAZQafCV\n 7yVo2yZ1FeNosFehX0dqjg6dp26ldQzbYf21LhimWwMxnCm5wLOPiPW+Tbbc8EFDJf6XcWA2oZb\n +lQkcmOEXtCdcISQ==", "X-Gm-Gg": "AeBDievPmKP3AI5X9N8MBaY1lJmILDq0OWlyrofT8cJSgXuYbD7/1aDTPOM1yuf7hZl\n LG3G2Zh+PcGGxhH/KOMb3sAJMGbi0i4vJLv8fjsOP0UBOLU0vbImJ22aNSWmVYvB7fYnTV9rnKG\n Z5LE01rI5L5vzsfrlW3RI4fcdHZ4HV3+Nh+DR1bQEGXzTYQth63R/K3QOzP2P/X8yY4MAv5GDx8\n uu4UBmvWnEZ+VwLiEOCjgI0sW6qplqM/+WQrC+9/hW83F/bF7DteoMeX9fkMjYUtGI/CP/XcyCZ\n tj87Gz2Gu9lZKSf4BB0/zMjGOljtBo20LwWUHWykXyuORY+j6/pamo49a1eobkIJCDxjy0z7Z1T\n vBrbCRugJdsohqISIVbIckYZzZ3odx5LvHDbbcozXvqIq2CbABbP1MSkUCl3dgiHaIaELxHdi9G\n 31", "X-Received": [ "by 2002:a17:90b:3852:b0:35c:b02:b5c1 with SMTP id\n 98e67ed59e1d1-3650cd4b20bmr8108865a91.2.1777867876969;\n Sun, 03 May 2026 21:11:16 -0700 (PDT)", "by 2002:a17:90b:3852:b0:35c:b02:b5c1 with SMTP id\n 98e67ed59e1d1-3650cd4b20bmr8108839a91.2.1777867876492;\n Sun, 03 May 2026 21:11:16 -0700 (PDT)" ], "From": "Matthew Ruffell <matthew.ruffell@canonical.com>", "To": "kernel-team@lists.ubuntu.com", "Subject": "[SRU][J][PATCH 0/3] SUNRPC: System wide grep leads to NULL pointer\n deference in sysfs reads", "Date": "Mon, 4 May 2026 16:10:55 +1200", "Message-ID": "<20260504041108.88774-1-matthew.ruffell@canonical.com>", "X-Mailer": "git-send-email 2.53.0", "MIME-Version": "1.0", "X-BeenThere": "kernel-team@lists.ubuntu.com", "X-Mailman-Version": "2.1.20", "Precedence": "list", "List-Id": "Kernel team discussions <kernel-team.lists.ubuntu.com>", "List-Unsubscribe": "<https://lists.ubuntu.com/mailman/options/kernel-team>,\n <mailto:kernel-team-request@lists.ubuntu.com?subject=unsubscribe>", "List-Archive": "<https://lists.ubuntu.com/archives/kernel-team>", "List-Post": "<mailto:kernel-team@lists.ubuntu.com>", "List-Help": "<mailto:kernel-team-request@lists.ubuntu.com?subject=help>", "List-Subscribe": "<https://lists.ubuntu.com/mailman/listinfo/kernel-team>,\n <mailto:kernel-team-request@lists.ubuntu.com?subject=subscribe>", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "Errors-To": "kernel-team-bounces@lists.ubuntu.com", "Sender": "\"kernel-team\" <kernel-team-bounces@lists.ubuntu.com>" }, "content": "BugLink: https://bugs.launchpad.net/bugs/2149767\n\n[Impact]\n\nAn unprivileged user doing a simple system wide grep can cause a NULL pointer\ndereference and oops in the SUNRPC subsystem, leading to a local Denial Of \nService.\n\nA user doing a grep such as \n\n$ grep -R \"something\" /\n\nwill eventually make its way to /sys/kernel/sunrpc/, where it can hit a race\nwhere ->sock in SUNRPC can be set to NULL, like if a network was going down and\nup again, or a nfs server was being restarted, leading to the following oops.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000020\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0 \nOops: 0000 SMP NOPTI\nCPU: 2 PID: 4933 Comm: grep Not tainted 5.15.0-176-generic #186-Ubuntu\nRIP: 0010:kernel_getsockname+0x6/0x20\nCode: 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 20 48 8b 40 60 48 89 e5 ff d0 0f 1f 00 5d c3 cc cc cc cc 0f 1f 40 00 0f 1f 44 00 00 55 <48> 8b 47 20 31 d2 48 8b 40 38 48 89 e5 ff d0 0f 1f 00 5d c3 cc cc\nCall Trace:\n <TASK>\n ? xs_sock_getport+0x2b/0x70 [sunrpc]\n ? kvmalloc_node+0x28/0xa0\n ? memcg_slab_post_alloc_hook+0x19e/0x210\n get_srcport+0x15/0x20 [sunrpc]\n rpc_sysfs_xprt_info_show+0x110/0x130 [sunrpc]\n kobj_attr_show+0xf/0x30\n sysfs_kf_seq_show+0xa2/0x100\n kernfs_seq_show+0x24/0x30\n seq_read_iter+0x121/0x4b0\n ? _copy_to_user+0x20/0x30\n ? cp_new_stat+0x152/0x180\n kernfs_fop_read_iter+0x30/0x40\n new_sync_read+0x10a/0x190\n vfs_read+0x106/0x1a0\n ksys_read+0x67/0xf0\n __x64_sys_read+0x19/0x20\n x64_sys_call+0x1dba/0x1fa0\n do_syscall_64+0x56/0xb0\n ? do_syscall_64+0x63/0xb0\n ? do_syscall_64+0x63/0xb0\n ? arch_exit_to_user_mode_prepare.constprop.0+0x1e/0xc0\n ? syscall_exit_to_user_mode+0x41/0x80\n ? do_syscall_64+0x63/0xb0\n entry_SYSCALL_64_after_hwframe+0x6c/0xd6\n\nA workaround is to exclude /sys from your grep or find commands.\n\n[Fix]\n\nThe fix is to ensure that SUNRPC holds the ->recv_mutex during sysfs reads.\nThis makes sure that ->sock cannot be modified by an external change, e.g.\na nfs server being restarted.\n\nThe fix, and their dependencies and fixes are:\n\ncommit 17f09d3f619a7ad2d2b021b4e5246f08225b1b0f\nAuthor: Anna Schumaker <Anna.Schumaker@Netapp.com>\nDate: Thu Oct 28 15:17:41 2021 -0400\nSubject: SUNRPC: Check if the xprt is connected before handling sysfs reads\nLink: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=17f09d3f619a7ad2d2b021b4e5246f08225b1b0f\n\ncommit b49ea673e119f59c71645e2f65b3ccad857c90ee\nAuthor: NeilBrown <neil@brown.name>\nDate: Mon Jan 17 16:36:53 2022 +1100\nSubject: SUNRPC: lock against ->sock changing during sysfs read\nLink: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b49ea673e119f59c71645e2f65b3ccad857c90ee\n\ncommit 421ab1be43bd015ffe744f4ea25df4f19d1ce6fe\nAuthor: Trond Myklebust <trond.myklebust@hammerspace.com>\nDate: Fri Mar 25 10:37:31 2022 -0400\nSubject: SUNRPC: Do not dereference non-socket transports in sysfs\nLink: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=421ab1be43bd015ffe744f4ea25df4f19d1ce6fe\n\nThese landed during 5.16-rc1 and 5.18-rc1.\n\n[Testcase]\n\nCreate a fresh jammy VM.\n\nCreate a NFS share:\n\n$ sudo apt install nfs-kernel-server\n$ sudo mkdir -p /mnt/nfs_share\n$ sudo chown nobody:nogroup /mnt/nfs_share\n$ sudo chmod 777 /mnt/nfs_share\n$ sudo vim /etc/exports\n/mnt/nfs_share 192.168.1.0/24(rw,sync,no_subtree_check)\n$ sudo exportfs -a\n$ sudo systemctl restart nfs-kernel-server\n\nSet up a loop where we grep the SUNRPC sysfs interface, causing a read to\nhappen, and some of these reads will happen when the ->recv_mutex is not held.\n\n$ while true; do\n grep -Rr . /sys/kernel/sunrpc/xprt-switches/;\ndone\n\nSet up a loop where we mount and unmount the nfs share. This triggers the SUNRPC\ntransport to disconnect or change states.\n\n$ sudo -s\n# while true; do\n mount -t nfs 192.168.122.126:/mnt/nfs_share /mnt/test\n umount /mnt/test\ndone\n\nWait a few seconds and the kernel will oops with a null pointer dereference.\n\nThere is a test kernel available in the following PPA:\n\nhttps://launchpad.net/~mruffell/+archive/ubuntu/sf434838-test\n\nIf you install the test kernel, you can keep running the loops forever without\nany kernel oops.\n\n[Where problems can occur]\n\nWe are changing how SUNRPC protects sysfs reads, ensuring we take a mutex to\nprotect the socket transport from changing due to external factors. Taking the\nmutex might take time, and slow down sysfs read operations, or cause deadlocks\nin other places in SUNRPC if not done correctly.\n\nThe patch \"SUNRPC: Do not dereference non-socket transports in sysfs\" is quite a\nrefactor, but the risk to RDMA users not having the patch is higher than\ncarrying the patch.\n\nIf a regression were to occur, users could likely work around the issue by not\nusing system wide grep or find commands that parse sysfs entries.\n\n[Other info]\n\nThis is known as CVE-2022-48816.\n\nhttps://ubuntu.com/security/CVE-2022-48816\nhttps://nvd.nist.gov/vuln/detail/cve-2022-48816\n\nAnna Schumaker (1):\n SUNRPC: Check if the xprt is connected before handling sysfs reads\n\nNeilBrown (1):\n SUNRPC: lock against ->sock changing during sysfs read\n\nTrond Myklebust (1):\n SUNRPC: Do not dereference non-socket transports in sysfs\n\n include/linux/sunrpc/xprt.h | 3 ++\n include/linux/sunrpc/xprtsock.h | 1 -\n net/sunrpc/sysfs.c | 62 ++++++++++++++++++---------------\n net/sunrpc/xprtsock.c | 33 ++++++++++++++++--\n 4 files changed, 67 insertions(+), 32 deletions(-)" }