All of lore.kernel.org
 help / color / mirror / Atom feed
* 5.18/15/10 backport
@ 2022-06-30 20:45 Jens Axboe
  2022-07-04 13:26 ` Jens Axboe
  2022-07-04 13:33 ` Greg Kroah-Hartman
  0 siblings, 2 replies; 4+ messages in thread
From: Jens Axboe @ 2022-06-30 20:45 UTC (permalink / raw)
  To: Greg Kroah-Hartman, stable

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Hi,

Can you apply these three patches, one for each of the 5.10, 5.15, and
5.18 stable tree? Doesn't fix any issues of concern, just ensures that
we -EINVAL when invalid fields are set in the sqe for these opcodes.
This brings it up to par with 5.19 and newer.

Thanks!

-- 
Jens Axboe

[-- Attachment #2: 5.10-0001-io_uring-ensure-that-send-sendmsg-and-recv-recvmsg-c.patch --]
[-- Type: text/x-patch, Size: 1586 bytes --]

From 3387e6c1b723783283822e9da08243147e4c1f35 Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe@kernel.dk>
Date: Thu, 30 Jun 2022 14:44:16 -0600
Subject: [PATCH] io_uring: ensure that send/sendmsg and recv/recvmsg check
 sqe->ioprio

commit 73911426aaaadbae54fa72359b33a7b6a56947db upstream.

All other opcodes correctly check if this is set and -EINVAL if it is
and they don't support that field, for some reason the these were
forgotten.

This was unified a bit differently in the upstream tree, but had the
same effect as making sure we error on this field. Rather than have
a painful backport of the upstream commit, just fixup the mentioned
opcodes.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 fs/io_uring.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 2e12dcbc7b0f..023c3eb34dcc 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4366,6 +4366,8 @@ static int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
+	if (unlikely(sqe->addr2 || sqe->splice_fd_in || sqe->ioprio))
+		return -EINVAL;
 
 	sr->msg_flags = READ_ONCE(sqe->msg_flags);
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
@@ -4601,6 +4603,8 @@ static int io_recvmsg_prep(struct io_kiocb *req,
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
+	if (unlikely(sqe->addr2 || sqe->splice_fd_in || sqe->ioprio))
+		return -EINVAL;
 
 	sr->msg_flags = READ_ONCE(sqe->msg_flags);
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
-- 
2.35.1


[-- Attachment #3: 5.15-0001-io_uring-ensure-that-send-sendmsg-and-recv-recvmsg-c.patch --]
[-- Type: text/x-patch, Size: 1590 bytes --]

From 3a0773ea1e3b092f4964c24c41872f43a3737af9 Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe@kernel.dk>
Date: Thu, 30 Jun 2022 14:42:05 -0600
Subject: [PATCH] io_uring: ensure that send/sendmsg and recv/recvmsg check
 sqe->ioprio

commit 73911426aaaadbae54fa72359b33a7b6a56947db upstream.

All other opcodes correctly check if this is set and -EINVAL if it is
and they don't support that field, for some reason the these were
forgotten.

This was unified a bit differently in the upstream tree, but had the
same effect as making sure we error on this field. Rather than have
a painful backport of the upstream commit, just fixup the mentioned
opcodes.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 fs/io_uring.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 5fc3a62eae72..463c60ff8dfb 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4793,6 +4793,8 @@ static int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
+	if (unlikely(sqe->addr2 || sqe->file_index || sqe->ioprio))
+		return -EINVAL;
 
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
 	sr->len = READ_ONCE(sqe->len);
@@ -5014,6 +5016,8 @@ static int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
+	if (unlikely(sqe->addr2 || sqe->file_index || sqe->ioprio))
+		return -EINVAL;
 
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
 	sr->len = READ_ONCE(sqe->len);
-- 
2.35.1


[-- Attachment #4: 5.18-0001-io_uring-ensure-that-send-sendmsg-and-recv-recvmsg-c.patch --]
[-- Type: text/x-patch, Size: 1634 bytes --]

From 2ff4ef34c3e1bd6a5ab7a956ae98cb9b6ae0aac8 Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe@kernel.dk>
Date: Thu, 30 Jun 2022 14:38:45 -0600
Subject: [PATCH] io_uring: ensure that send/sendmsg and recv/recvmsg check
 sqe->ioprio

commit 73911426aaaadbae54fa72359b33a7b6a56947db upstream.

All other opcodes correctly check if this is set and -EINVAL if it is
and they don't support that field, for some reason the these were
forgotten.

This was unified a bit differently in the upstream tree, but had the
same effect as making sure we error on this field. Rather than have
a painful backport of the upstream commit, just fixup the mentioned
opcodes.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
---
 fs/io_uring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 3d123ca028c9..8950b443891f 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -5252,7 +5252,7 @@ static int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
-	if (unlikely(sqe->addr2 || sqe->file_index))
+	if (unlikely(sqe->addr2 || sqe->file_index || sqe->ioprio))
 		return -EINVAL;
 
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
@@ -5465,7 +5465,7 @@ static int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
-	if (unlikely(sqe->addr2 || sqe->file_index))
+	if (unlikely(sqe->addr2 || sqe->file_index || sqe->ioprio))
 		return -EINVAL;
 
 	sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: 5.18/15/10 backport
  2022-06-30 20:45 5.18/15/10 backport Jens Axboe
@ 2022-07-04 13:26 ` Jens Axboe
  2022-07-04 13:28   ` Jens Axboe
  2022-07-04 13:33 ` Greg Kroah-Hartman
  1 sibling, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2022-07-04 13:26 UTC (permalink / raw)
  To: Greg Kroah-Hartman, stable

On 6/30/22 2:45 PM, Jens Axboe wrote:
> Hi,
> 
> Can you apply these three patches, one for each of the 5.10, 5.15, and
> 5.18 stable tree? Doesn't fix any issues of concern, just ensures that
> we -EINVAL when invalid fields are set in the sqe for these opcodes.
> This brings it up to par with 5.19 and newer.

Just a reminder on this one, thanks!

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 5.18/15/10 backport
  2022-07-04 13:26 ` Jens Axboe
@ 2022-07-04 13:28   ` Jens Axboe
  0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2022-07-04 13:28 UTC (permalink / raw)
  To: Greg Kroah-Hartman, stable

On 7/4/22 7:26 AM, Jens Axboe wrote:
> On 6/30/22 2:45 PM, Jens Axboe wrote:
>> Hi,
>>
>> Can you apply these three patches, one for each of the 5.10, 5.15, and
>> 5.18 stable tree? Doesn't fix any issues of concern, just ensures that
>> we -EINVAL when invalid fields are set in the sqe for these opcodes.
>> This brings it up to par with 5.19 and newer.
> 
> Just a reminder on this one, thanks!

Disregard, mid-air collision on emails. Thanks for queueing them up.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 5.18/15/10 backport
  2022-06-30 20:45 5.18/15/10 backport Jens Axboe
  2022-07-04 13:26 ` Jens Axboe
@ 2022-07-04 13:33 ` Greg Kroah-Hartman
  1 sibling, 0 replies; 4+ messages in thread
From: Greg Kroah-Hartman @ 2022-07-04 13:33 UTC (permalink / raw)
  To: Jens Axboe; +Cc: stable

On Thu, Jun 30, 2022 at 02:45:53PM -0600, Jens Axboe wrote:
> Hi,
> 
> Can you apply these three patches, one for each of the 5.10, 5.15, and
> 5.18 stable tree? Doesn't fix any issues of concern, just ensures that
> we -EINVAL when invalid fields are set in the sqe for these opcodes.
> This brings it up to par with 5.19 and newer.

All now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-07-04 13:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-30 20:45 5.18/15/10 backport Jens Axboe
2022-07-04 13:26 ` Jens Axboe
2022-07-04 13:28   ` Jens Axboe
2022-07-04 13:33 ` Greg Kroah-Hartman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.