* Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS
[not found] ` <CAFswPa9jR6mKAsCrdmspCARe-evk16s1t0SG9LrRLCze_f6Ydw@mail.gmail.com>
@ 2024-05-25 15:19 ` Greg Kroah-Hartman
2024-05-25 15:28 ` Jens Axboe
2024-05-25 18:15 ` Gabriel Krisman Bertazi
2 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-25 15:19 UTC (permalink / raw)
To: Eduardo' Vela" <Nava>
Cc: Jens Axboe, Gabriel Krisman Bertazi, linux-cve-announce, cve,
linux-kernel, Tamás Koczka
On Sat, May 25, 2024 at 05:09:45PM +0200, Eduardo' Vela" <Nava> wrote:
> On Sat, 25 May 2024, 09:15 Greg Kroah-Hartman, <gregkh@linuxfoundation.org>
> wrote:
>
> > On Fri, May 24, 2024 at 10:57:07AM -0600, Jens Axboe wrote:
> > > On 5/24/24 10:45 AM, Gabriel Krisman Bertazi wrote:
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> > > >
> > > >> Description
> > > >> ===========
> > > >>
> > > >> In the Linux kernel, the following vulnerability has been resolved:
> > > >>
> > > >> io_uring: drop any code related to SCM_RIGHTS
> > > >>
> > > >> This is dead code after we dropped support for passing io_uring fds
> > > >> over SCM_RIGHTS, get rid of it.
> > > >>
> > > >> The Linux kernel CVE team has assigned CVE-2023-52656 to this issue.
> > > >
> > > > Hello Greg,
> > > >
> > > > [+Jens in Cc]
> > > >
> > > > This is stable material, but doesn't deserve CVE status. There is
> > > > nothing exploitable that is fixed here. Instead, this commit is
> > dropping
> > > > unreachable code after the removal of a feature, following another CVE
> > > > report. Doing the clean up in the original patch would have made the
> > > > real security fix harder to review.
> > > >
> > > > The real issue was reported as CVE-2023-52654 and handled by a
> > different
> > > > commit.
> > >
> > > FWIW, the same is true for a number of other commits recently. They are
> > > nowhere near CVE material, it's just generic bug fixes.
> >
> > Ok, glad to revoke them if you do not think they are user triggerable
> > issues. I'll go reject this one right now, thanks.
> >
>
> Good day!
>
> 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").
>
> 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).
>
> What a mess! 😄
>
> My colleague poprdi@google.com sent this analysis to the CNA list, so maybe
> we can continue the discussion there as he also provided some additional
> details there.
Oh yeah, that's right, that's why we issued that!
Jens, any objection for me restoring this CVE?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS
[not found] ` <CAFswPa9jR6mKAsCrdmspCARe-evk16s1t0SG9LrRLCze_f6Ydw@mail.gmail.com>
2024-05-25 15:19 ` Greg Kroah-Hartman
@ 2024-05-25 15:28 ` Jens Axboe
2024-05-25 15:37 ` Greg Kroah-Hartman
2024-05-25 18:15 ` Gabriel Krisman Bertazi
2 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2024-05-25 15:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gabriel Krisman Bertazi, linux-cve-announce, cve, linux-kernel,
Tamás Koczka
On 5/25/24 9:09 AM, Eduardo' Vela" <Nava> wrote:
> On Sat, 25 May 2024, 09:15 Greg Kroah-Hartman, <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>> wrote:
>
> On Fri, May 24, 2024 at 10:57:07AM -0600, Jens Axboe wrote:
> > On 5/24/24 10:45 AM, Gabriel Krisman Bertazi wrote:
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>> writes:
> > >
> > >> Description
> > >> ===========
> > >>
> > >> In the Linux kernel, the following vulnerability has been resolved:
> > >>
> > >> io_uring: drop any code related to SCM_RIGHTS
> > >>
> > >> This is dead code after we dropped support for passing io_uring fds
> > >> over SCM_RIGHTS, get rid of it.
> > >>
> > >> The Linux kernel CVE team has assigned CVE-2023-52656 to this issue.
> > >
> > > Hello Greg,
> > >
> > > [+Jens in Cc]
> > >
> > > This is stable material, but doesn't deserve CVE status. There is
> > > nothing exploitable that is fixed here. Instead, this commit is dropping
> > > unreachable code after the removal of a feature, following another CVE
> > > report. Doing the clean up in the original patch would have made the
> > > real security fix harder to review.
> > >
> > > The real issue was reported as CVE-2023-52654 and handled by a different
> > > commit.
> >
> > FWIW, the same is true for a number of other commits recently. They are
> > nowhere near CVE material, it's just generic bug fixes.
>
> Ok, glad to revoke them if you do not think they are user triggerable
> issues. I'll go reject this one right now, thanks.
>
>
> Good day!
>
> 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").
>
> 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).
>
> What a mess! ?
Ah right, yeah it was a mess because of the stable backports, it was not
for the upstream front. Agree Greg, let's just keep it because of the
stable side.
--
Jens Axboe
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS
2024-05-25 15:28 ` Jens Axboe
@ 2024-05-25 15:37 ` Greg Kroah-Hartman
0 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-25 15:37 UTC (permalink / raw)
To: Jens Axboe
Cc: Gabriel Krisman Bertazi, linux-cve-announce, cve, linux-kernel,
Tamás Koczka
On Sat, May 25, 2024 at 09:28:35AM -0600, Jens Axboe wrote:
> On 5/25/24 9:09 AM, Eduardo' Vela" <Nava> wrote:
> > On Sat, 25 May 2024, 09:15 Greg Kroah-Hartman, <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>> wrote:
> >
> > On Fri, May 24, 2024 at 10:57:07AM -0600, Jens Axboe wrote:
> > > On 5/24/24 10:45 AM, Gabriel Krisman Bertazi wrote:
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>> writes:
> > > >
> > > >> Description
> > > >> ===========
> > > >>
> > > >> In the Linux kernel, the following vulnerability has been resolved:
> > > >>
> > > >> io_uring: drop any code related to SCM_RIGHTS
> > > >>
> > > >> This is dead code after we dropped support for passing io_uring fds
> > > >> over SCM_RIGHTS, get rid of it.
> > > >>
> > > >> The Linux kernel CVE team has assigned CVE-2023-52656 to this issue.
> > > >
> > > > Hello Greg,
> > > >
> > > > [+Jens in Cc]
> > > >
> > > > This is stable material, but doesn't deserve CVE status. There is
> > > > nothing exploitable that is fixed here. Instead, this commit is dropping
> > > > unreachable code after the removal of a feature, following another CVE
> > > > report. Doing the clean up in the original patch would have made the
> > > > real security fix harder to review.
> > > >
> > > > The real issue was reported as CVE-2023-52654 and handled by a different
> > > > commit.
> > >
> > > FWIW, the same is true for a number of other commits recently. They are
> > > nowhere near CVE material, it's just generic bug fixes.
> >
> > Ok, glad to revoke them if you do not think they are user triggerable
> > issues. I'll go reject this one right now, thanks.
> >
> >
> > Good day!
> >
> > 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").
> >
> > 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).
> >
> > What a mess! ?
>
> Ah right, yeah it was a mess because of the stable backports, it was not
> for the upstream front. Agree Greg, let's just keep it because of the
> stable side.
Now republished, thanks!
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2023-52656: io_uring: drop any code related to SCM_RIGHTS
[not found] ` <CAFswPa9jR6mKAsCrdmspCARe-evk16s1t0SG9LrRLCze_f6Ydw@mail.gmail.com>
2024-05-25 15:19 ` Greg Kroah-Hartman
2024-05-25 15:28 ` Jens Axboe
@ 2024-05-25 18:15 ` Gabriel Krisman Bertazi
2 siblings, 0 replies; 9+ messages in thread
From: Gabriel Krisman Bertazi @ 2024-05-25 18:15 UTC (permalink / raw)
To: Eduardo Vela <Nava>
Cc: Greg Kroah-Hartman, Jens Axboe, linux-cve-announce, cve,
linux-kernel, Tamás Koczka
"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
^ permalink raw reply [flat|nested] 9+ messages in thread