[{"id":3672995,"web_url":"http://patchwork.ozlabs.org/comment/3672995/","msgid":"<6105a24f-980e-4f03-98c7-500886998f09@canonical.com>","list_archive_url":null,"date":"2026-04-03T06:13:19","subject":"ACK: [SRU][N/Q][PATCH 0/1] CVE-2026-23394","submitter":{"id":85372,"url":"http://patchwork.ozlabs.org/api/people/85372/","name":"Masahiro Yamada","email":"masahiro.yamada@canonical.com"},"content":"On 4/3/26 08:07, Tim Whisonant wrote:\n> SRU Justification:\n>\n> [Impact]\n>\n> af_unix: Give up GC if MSG_PEEK intervened.\n>\n> Igor Ushakov reported that GC purged the receive queue of\n> an alive socket due to a race with MSG_PEEK with a nice repro.\n>\n> This is the exact same issue previously fixed by commit\n> cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\").\n>\n> After GC was replaced with the current algorithm, the cited\n> commit removed the locking dance in unix_peek_fds() and\n> reintroduced the same issue.\n>\n> The problem is that MSG_PEEK bumps a file refcount without\n> interacting with GC.\n>\n> Consider an SCC containing sk-A and sk-B, where sk-A is\n> close()d but can be recv()ed via sk-B.\n>\n> The bad thing happens if sk-A is recv()ed with MSG_PEEK from\n> sk-B and sk-B is close()d while GC is checking unix_vertex_dead()\n> for sk-A and sk-B.\n>\n> GC thread User thread\n> --------- -----------\n> unix_vertex_dead(sk-A)\n> -> true <------.\n> \\\n> `------ recv(sk-B, MSG_PEEK)\n> invalidate !! -> sk-A's file refcount : 1 -> 2\n>\n> close(sk-B)\n> -> sk-B's file refcount : 2 -> 1\n> unix_vertex_dead(sk-B)\n> -> true\n>\n> Initially, sk-A's file refcount is 1 by the inflight fd in sk-B\n> recvq. GC thinks sk-A is dead because the file refcount is the\n> same as the number of its inflight fds.\n>\n> However, sk-A's file refcount is bumped silently by MSG_PEEK,\n> which invalidates the previous evaluation.\n>\n> At this moment, sk-B's file refcount is 2; one by the open fd,\n> and one by the inflight fd in sk-A. The subsequent close()\n> releases one refcount by the former.\n>\n> Finally, GC incorrectly concludes that both sk-A and sk-B are dead.\n>\n> One option is to restore the locking dance in unix_peek_fds(),\n> but we can resolve this more elegantly thanks to the new algorithm.\n>\n> The point is that the issue does not occur without the subsequent\n> close() and we actually do not need to synchronise MSG_PEEK with\n> the dead SCC detection.\n>\n> When the issue occurs, close() and GC touch the same file refcount.\n> If GC sees the refcount being decremented by close(), it can just\n> give up garbage-collecting the SCC.\n>\n> Therefore, we only need to signal the race during MSG_PEEK with\n> a proper memory barrier to make it visible to the GC.\n>\n> Let's use seqcount_t to notify GC when MSG_PEEK occurs and let\n> it defer the SCC to the next run.\n>\n> This way no locking is needed on the MSG_PEEK side, and we can\n> avoid imposing a penalty on every MSG_PEEK unnecessarily.\n>\n> Note that we can retry within unix_scc_dead() if MSG_PEEK is\n> detected, but we do not do so to avoid hung task splat from\n> abusive MSG_PEEK calls.\n>\n> [Fix]\n>\n> Questing: backported from upstream\n> Noble: backported from upstream\n> Jammy: not affected\n> Focal: not affected\n> Bionic: not affected\n> Xenial: not affected\n> Trusty: not affected\n>\n> [Test Plan]\n>\n> Compile and boot tested.\n>\n> [Where problems could occur]\n>\n> The change affects Unix domain sockets, specifically the garbage\n> collection algorithm, to prevent a race condition that leads to\n> early clearing of a receive queue. Issues would affect Unix\n> domain sockets, particularly when used with MSG_PEEK.\n>\n> Kuniyuki Iwashima (1):\n> af_unix: Give up GC if MSG_PEEK intervened.\n>\n> net/unix/af_unix.c | 2 ++\n> net/unix/af_unix.h | 1 +\n> net/unix/garbage.c | 79 ++++++++++++++++++++++++++++++----------------\n> 3 files changed, 54 insertions(+), 28 deletions(-)\n>\n\nAcked-by: Masahiro Yamada ","headers":{"Return-Path":"","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=kn53+NMe;\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 4fn7hF6RgXz1yD3\n\tfor ; Fri, 03 Apr 2026 17:13:33 +1100 (AEDT)","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 )\n\tid 1w8XmX-0006Tl-AM; Fri, 03 Apr 2026 06:13:25 +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 )\n id 1w8XmV-0006TU-RD\n for kernel-team@lists.ubuntu.com; Fri, 03 Apr 2026 06:13:23 +0000","from mail-pg1-f198.google.com (mail-pg1-f198.google.com\n [209.85.215.198])\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 9FD4D3F294\n for ; Fri, 3 Apr 2026 06:13:23 +0000 (UTC)","by mail-pg1-f198.google.com with SMTP id\n 41be03b00d2f7-b630b4d8d52so918906a12.3\n for ; Thu, 02 Apr 2026 23:13:23 -0700 (PDT)","from ?IPV6:2001:f74:8f00:c00:6aff::1002?\n ([2001:f74:8f00:c00:6aff::1002]) by smtp.gmail.com with ESMTPSA id\n 41be03b00d2f7-c76c6492097sm4336348a12.10.2026.04.02.23.13.20\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Thu, 02 Apr 2026 23:13:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1775196803;\n bh=TlX6E+lUXyLF64OdgAGqMu4QW9jV+a7O8K+t0ftCn7E=;\n h=Message-ID:Date:MIME-Version:Subject:To:References:From:\n In-Reply-To:Content-Type;\n b=kn53+NMeayz0XofOmwxo2Erebe2T/etBGD5w2//3MfoLItq90qg52+FI01kOpjAR8\n AKllz2nW6fZNh29PjFsualG/B7FqSjmxovSSS/l0RUTcoSVWEq6TEPgwBj7mrM1r9M\n cgphSMetF2Kvq2Hsp9jmjgBvPmplkO7MjfZ0Tp1o6lMDW7D7ysmQ7qX6L/vd+HuNsI\n 5ucGwVpP1D5QwXkkJ1PvAFEwwPfsoNQ2gPmyvBF9J4v7z8FEEfQsvEjMaMzG59Xweg\n S3r7+IN0xcygiPPThNirMc4Tl33TBSw2MCiwxsRD5sKHTIJHXs4o2pgwRxnT+YdnE1\n aod95h50MwTl5mxfMiq+za8/P7RFChluLMxJTmspGGxn59eHW+lEJrfndN9xS+pPj4\n uVWRj8aIKbPEwb9NcesLsUKBp0J23uvpTOoT5bxAYD0CxxI7p0bBmUazHn/VLfZXrY\n emiA4sUbCKVzNjnNR5W2VkZo8tI/IEHz/FWlbX1r+/tCyaS5AORQiaJ4pzKz9gKNh2\n zHTxJEuvAQVxEZeBT5MvccJ7QTVjv1NmZm+QVId66GVGr5nWxAZzLfQQ6up9FRPbIz\n wxSbevjyL8KMQY70PcViQAJFKiSXtrjRGwW9+nrxP4r7a+6ezz47iSZY8QNW6C8Nkw\n bbTqiqXtxqIx4WAiKTyJPoSA=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775196802; x=1775801602;\n h=content-transfer-encoding:in-reply-to:content-language:from\n :references:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=TlX6E+lUXyLF64OdgAGqMu4QW9jV+a7O8K+t0ftCn7E=;\n b=jYeB3wDzSQdMPinxmI5RBMmp1ngipDYUjcbfQ6NAUhpamL6xcfrzTyG2biAoECdboS\n K5wGpIk9PcmiMD1eT/C+HF2skeVwTn3xYDt9iKl6gLjEaQc/J5f2sOkmFk5SdVHRMsfk\n VFlBkieTSH+TXp8HqXHO6um90kJlD9PRv900y/MRi3mn1ZxHNYrO7E7jc5q/lnWvls0F\n 3Km9E0BzV4irC0NEMta5JKd3qci8Plky/fvevD7PBJv2pkts5t9j2lcawnaitaOIkn4l\n mMKiaNFPH7ldrkysiRDGpaQ9PV+WbhKTaWC05rewyL27bHqXLMX7uiwsWLQAL15hPTzM\n YaWQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWUPsDQaz+WJZqjv/XPAlvqEitlWOLnVd1SaXDJnUZY9WwOaYfX5feDVzXuXKjLngwID8BRPfJVT7iygQ==@lists.ubuntu.com","X-Gm-Message-State":"AOJu0YxbzZ0JMnXSlDRbCsQpewk60J5WgVPjGp8Iln/AedbGPbZMVwdT\n MKQRXeJ8hu04rdpnS/px6OPEmmGd6qi3CjgXAeDKujVskYcd5WjwjQm8UoIeueumsqHytciAwYB\n ap0FQk9y/xuq/3+36tDmqAguBkwSY5qduKS3Aa0GBNbe1of/NkASK3WI8d3uYKTWaes4MSddH9Q\n dQGW+B26p/7WyV8A==","X-Gm-Gg":"ATEYQzzYV1+ibu7cH23GFVv71OXg2tpDQf0LvYVsAWRWKX6HJ4nganoaFAMqAbHK1lP\n ewOALptRImpq90jNX7d7dUxjicSEbY8V/1s2BkAs1jDaQTakcvwXIkdCxOIfmD/n9ugGfkP/eej\n 4ehQzg+aKsF7chCBS99olHE4s1QkT1DFjj88I+t94MfXl3bFAdPd7GBYyKi/DW/pas9IjV/IwEL\n 8n/oOtxB8ZYOaimFwiWLJif/VWnu0PPai+AwPrNIU/9dKlcfslgBYRy2tsB2zu97FJjgMaEatLy\n CatXAaMDdaqYBPPCwj0wzAqvRZ4eBE4Kz1oG5tqnO+XbonipPNG1L/c1kR/RsuDLPHRB6nVFdsa\n e3EdY0kQtT7pWrQsIA+PFVVpo0+zqMCb24X2dD7Pe7rNLotHzKvQZrhg=","X-Received":["by 2002:a05:6a20:12c6:b0:39b:f026:6f8d with SMTP id\n adf61e73a8af0-39f2f2f71femr1852775637.43.1775196802050;\n Thu, 02 Apr 2026 23:13:22 -0700 (PDT)","by 2002:a05:6a20:12c6:b0:39b:f026:6f8d with SMTP id\n adf61e73a8af0-39f2f2f71femr1852750637.43.1775196801585;\n Thu, 02 Apr 2026 23:13:21 -0700 (PDT)"],"Message-ID":"<6105a24f-980e-4f03-98c7-500886998f09@canonical.com>","Date":"Fri, 3 Apr 2026 15:13:19 +0900","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"ACK: [SRU][N/Q][PATCH 0/1] CVE-2026-23394","To":"Tim Whisonant , kernel-team@lists.ubuntu.com","References":"<20260402230724.1279847-1-tim.whisonant@canonical.com>","From":"Masahiro Yamada ","Content-Language":"en-US","In-Reply-To":"<20260402230724.1279847-1-tim.whisonant@canonical.com>","X-BeenThere":"kernel-team@lists.ubuntu.com","X-Mailman-Version":"2.1.20","Precedence":"list","List-Id":"Kernel team discussions ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Transfer-Encoding":"base64","Content-Type":"text/plain; charset=\"utf-8\"; Format=\"flowed\"","Errors-To":"kernel-team-bounces@lists.ubuntu.com","Sender":"\"kernel-team\" "}}]