linux-kernel - Re: CVE-2023-52656: io_uring: drop any code related to SCM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Sat, 25 May 2024 14:15:19 -0400
From: Gabriel Krisman Bertazi <krisman@...e.de>
To: "Eduardo Vela <Nava>" <evn@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,  Jens Axboe
 <axboe@...nel.dk>,  linux-cve-announce@...r.kernel.org,  cve@...nel.org,
  linux-kernel@...r.kernel.org,  Tamás Koczka
 <poprdi@...gle.com>
Subject: Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS

"Eduardo' Vela\" <Nava>" <evn@...gle.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@...gle.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