Received-SPF: pass (google.com: domain of linux-kernel+bounces-189505-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Gabriel Krisman Bertazi <krisman@suse.de>
To: "Eduardo Vela <Nava>" <evn@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,  Jens Axboe
 <axboe@kernel.dk>,  linux-cve-announce@vger.kernel.org,  cve@kernel.org,
  linux-kernel@vger.kernel.org,  =?utf-8?Q?Tam=C3=A1s?= Koczka
 <poprdi@google.com>
Subject: Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS
In-Reply-To: <CAFswPa9jR6mKAsCrdmspCARe-evk16s1t0SG9LrRLCze_f6Ydw@mail.gmail.com>
	(Eduardo' Vela's message of "Sat, 25 May 2024 17:09:45 +0200")
Organization: SUSE
References: <2024051338-CVE-2023-52656-6545@gregkh>
	<871q5rqhuc.fsf@mailhost.krisman.be>
	<d1cb0cd3-0826-48fc-8713-8648d6eb9fd7@kernel.dk>
	<2024052542-diner-snare-a618@gregkh>
	<CAFswPa9jR6mKAsCrdmspCARe-evk16s1t0SG9LrRLCze_f6Ydw@mail.gmail.com>
Date: Sat, 25 May 2024 14:15:19 -0400
Message-ID: <87fru5pxl4.fsf@mailhost.krisman.be>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

"Eduardo' Vela\" <Nava>" <evn@google.com> writes:

> So, either I'm completely lost or CVE-2023-52656 shouldn't have been
> rejected. Forgive me for mudding the problem even more.
>
> I think we need to unreject this CVE (CVE-2023-52656) or CVE-2023-52654
> should be amended to include the dead code removal commit.. that said,
> that'll be weirder than just unrejecting this commit.
>
> The reason is that the commit "io_uring/af_unix: disable sending io_uring
> over sockets" is not enough to fix the vulnerability in stable branches,
> because e.g. bcedd497b3b4a0be56f3adf7c7542720eced0792 on 5.15 only fixes
> one path (io_sqe_file_register) to reach unix_inflight(), but it is still
> reachable via another path (io_sqe_fileS_register) which is only removed by
> d909d381c3152393421403be4b6435f17a2378b4 ("io_uring: drop any code related
> to SCM_RIGHTS").

Hm, right.  this is real for some really old stable tree.  thanks for
the clarification.

But lets agree, the above write up is literally the *only* relevant,
public information on the issue (that I could find).  And it only
appeared because we almost wrongfully rejected it.  The CVE description,
the list of affected trees and everything else in the CVE report are
absolute non-sense.  Still, the CVE report is all downstream developers
have to work on the issue.  Of course, the original commit message could
not have tracked the new information, but the analysis MUST be appended
to the CVE description.

FWIW,

	Fixed in 6.1.83 with commit a3812a47a320
	Fixed in 6.7.11 with commit 88c49d9c8961
	Fixed in 6.8 with commit 6e5e6d274956

Is nonsense, then.  We check for io_is_uring_fops(file) right before it.

Greg,

I understand we have multiple streams for security issues, including
some that might be automated through Fixes tag. But for cases like this,
where a discussion apparently happened and a human did the excellent
work of properly analyzing it, can we get a real CVE description
beyond the original commit message?  Even publishing the archives of the
original report (minus, whatever, the exploit) alongside the CVE would
improve the situation.  The old CVE process was notoriously bad with
descriptions, but this is somehow worse.

> Although that patch claims "it is dead code", this claim was only true on
> upstream, but not on stable branches (or at least on 5.15 where the
> vulnerability was proven to be reachable).

Yet, there no information about this "small" detail anywhere I can find.

> My colleague poprdi@google.com sent this analysis to the CNA list, so maybe
> we can continue the discussion there

No. this *really* needs to be discussed on an *open* list.  The CVE is
out already.

-- 
Gabriel Krisman Bertazi