| Message ID | 20230614104237.1948590-1-cascardo@canonical.com |
|---|---|
| Headers | show |
| Series | CVE-2023-2430 | expand |
On Wed, 2023-06-14 at 07:42 -0300, Thadeu Lima de Souza Cascardo wrote: > [Impact] > A race condition when sending a MSG_RING operation to an IOPOLL > io_uring > may lead to incorrect behavior. > > [Test case] > A test case was prepared where incorrect behavior was observed, > indicating > a race condition. > > [Backport] > For 6.1, some conflicts because of previous out-of-order backports > were dealt with. > > For 5.19, lots of file movements and different changes required that > the > backport was written anew. It introduces the double_locking (which is > not > double anymore), just for the sake of locking the other ctx > uring_lock when > sending MSG_RING data. > > For 6.0, there were more clean cherry-picks compared to 6.1. However, > the > testing shows some other strange behavior and is being currently > investigated. > > [Potential regression] > io_uring users relying on MSG_RING or IOPOLL would be affected. > > Jens Axboe (2): > io_uring/msg_ring: move double lock/unlock helpers higher up > io_uring/msg_ring: fix missing lock on overflow for IOPOLL > > Pavel Begunkov (2): > io_uring: get rid of double locking > io_uring: extract a io_msg_install_complete helper Seems like a huge amount of work. Acked-by: Cengiz Can <cengiz.can@canonical.com> > > io_uring/msg_ring.c | 143 ++++++++++++++++++++++++++---------------- > -- > io_uring/msg_ring.h | 1 + > io_uring/opdef.c | 1 + > 3 files changed, 88 insertions(+), 57 deletions(-) > > -- > 2.34.1 > >
On 6/14/23 03:42, Thadeu Lima de Souza Cascardo wrote: > [Impact] > A race condition when sending a MSG_RING operation to an IOPOLL io_uring > may lead to incorrect behavior. > > [Test case] > A test case was prepared where incorrect behavior was observed, indicating > a race condition. > > [Backport] > For 6.1, some conflicts because of previous out-of-order backports were dealt with. > > For 5.19, lots of file movements and different changes required that the > backport was written anew. It introduces the double_locking (which is not > double anymore), just for the sake of locking the other ctx uring_lock when > sending MSG_RING data. > > For 6.0, there were more clean cherry-picks compared to 6.1. However, the > testing shows some other strange behavior and is being currently investigated. > > [Potential regression] > io_uring users relying on MSG_RING or IOPOLL would be affected. > > Jens Axboe (2): > io_uring/msg_ring: move double lock/unlock helpers higher up > io_uring/msg_ring: fix missing lock on overflow for IOPOLL > > Pavel Begunkov (2): > io_uring: get rid of double locking > io_uring: extract a io_msg_install_complete helper > > io_uring/msg_ring.c | 143 ++++++++++++++++++++++++++------------------ > io_uring/msg_ring.h | 1 + > io_uring/opdef.c | 1 + > 3 files changed, 88 insertions(+), 57 deletions(-) > Acked-by: Tim Gardner <tim.gardner@canonical.com>
On 14.06.23 12:42, Thadeu Lima de Souza Cascardo wrote: > [Impact] > A race condition when sending a MSG_RING operation to an IOPOLL io_uring > may lead to incorrect behavior. > > [Test case] > A test case was prepared where incorrect behavior was observed, indicating > a race condition. > > [Backport] > For 6.1, some conflicts because of previous out-of-order backports were dealt with. > > For 5.19, lots of file movements and different changes required that the > backport was written anew. It introduces the double_locking (which is not > double anymore), just for the sake of locking the other ctx uring_lock when > sending MSG_RING data. > > For 6.0, there were more clean cherry-picks compared to 6.1. However, the > testing shows some other strange behavior and is being currently investigated. > > [Potential regression] > io_uring users relying on MSG_RING or IOPOLL would be affected. > > Jens Axboe (2): > io_uring/msg_ring: move double lock/unlock helpers higher up > io_uring/msg_ring: fix missing lock on overflow for IOPOLL > > Pavel Begunkov (2): > io_uring: get rid of double locking > io_uring: extract a io_msg_install_complete helper > > io_uring/msg_ring.c | 143 ++++++++++++++++++++++++++------------------ > io_uring/msg_ring.h | 1 + > io_uring/opdef.c | 1 + > 3 files changed, 88 insertions(+), 57 deletions(-) > Applied to kinetic:linux/master-next. Thanks. -Stefan
Thadeu Lima de Souza Cascardo kirjoitti 14.6.2023 klo 13.42: > [Impact] > A race condition when sending a MSG_RING operation to an IOPOLL io_uring > may lead to incorrect behavior. > > [Test case] > A test case was prepared where incorrect behavior was observed, indicating > a race condition. > > [Backport] > For 6.1, some conflicts because of previous out-of-order backports were dealt with. > > For 5.19, lots of file movements and different changes required that the > backport was written anew. It introduces the double_locking (which is not > double anymore), just for the sake of locking the other ctx uring_lock when > sending MSG_RING data. > > For 6.0, there were more clean cherry-picks compared to 6.1. However, the > testing shows some other strange behavior and is being currently investigated. > > [Potential regression] > io_uring users relying on MSG_RING or IOPOLL would be affected. > > Jens Axboe (2): > io_uring/msg_ring: move double lock/unlock helpers higher up > io_uring/msg_ring: fix missing lock on overflow for IOPOLL > > Pavel Begunkov (2): > io_uring: get rid of double locking > io_uring: extract a io_msg_install_complete helper > > io_uring/msg_ring.c | 143 ++++++++++++++++++++++++++------------------ > io_uring/msg_ring.h | 1 + > io_uring/opdef.c | 1 + > 3 files changed, 88 insertions(+), 57 deletions(-) > applied to oem-6.1, thanks
Timo Aaltonen kirjoitti 20.6.2023 klo 15.31: > Thadeu Lima de Souza Cascardo kirjoitti 14.6.2023 klo 13.42: >> [Impact] >> A race condition when sending a MSG_RING operation to an IOPOLL io_uring >> may lead to incorrect behavior. >> >> [Test case] >> A test case was prepared where incorrect behavior was observed, >> indicating >> a race condition. >> >> [Backport] >> For 6.1, some conflicts because of previous out-of-order backports >> were dealt with. >> >> For 5.19, lots of file movements and different changes required that the >> backport was written anew. It introduces the double_locking (which is not >> double anymore), just for the sake of locking the other ctx uring_lock >> when >> sending MSG_RING data. >> >> For 6.0, there were more clean cherry-picks compared to 6.1. However, the >> testing shows some other strange behavior and is being currently >> investigated. >> >> [Potential regression] >> io_uring users relying on MSG_RING or IOPOLL would be affected. >> >> Jens Axboe (2): >> io_uring/msg_ring: move double lock/unlock helpers higher up >> io_uring/msg_ring: fix missing lock on overflow for IOPOLL >> >> Pavel Begunkov (2): >> io_uring: get rid of double locking >> io_uring: extract a io_msg_install_complete helper >> >> io_uring/msg_ring.c | 143 ++++++++++++++++++++++++++------------------ >> io_uring/msg_ring.h | 1 + >> io_uring/opdef.c | 1 + >> 3 files changed, 88 insertions(+), 57 deletions(-) >> > > applied to oem-6.1, thanks and let's be explicit about that in the Subject.