October 2022 - Linux-stable-mirror

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 88aa023a2556 ("fs: dlm: cleanup and remove _send_rcom") d10a0b88751a ("fs: dlm: rename socket and app buffer defines") 5b2f981fde8b ("fs: dlm: add midcomms debugfs functionality") 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") 8e2e40860c7f ("fs: dlm: add union in dlm header for lockspace id") 37a247da517f ("fs: dlm: move out some hash functionality") 8f2dc78dbc20 ("fs: dlm: make buffer handling per msg") a070a91cf140 ("fs: dlm: add more midcomms hooks") 6fb5cf9d4206 ("fs: dlm: public header in out utility") 8aa31cbf20ad ("fs: dlm: fix connection tcp EOF handling") ba868d9deaab ("fs: dlm: reconnect if socket error report occurs") b38bc9c2b317 ("fs: dlm: fix srcu read lock usage") 2fd8db2dd05d ("fs: dlm: fix missing unlock on error in accept_from_sock()") 9d232469bcd7 ("fs: dlm: add shutdown hook") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 88aa023a2556 ("fs: dlm: cleanup and remove _send_rcom") d10a0b88751a ("fs: dlm: rename socket and app buffer defines") 5b2f981fde8b ("fs: dlm: add midcomms debugfs functionality") 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") 8e2e40860c7f ("fs: dlm: add union in dlm header for lockspace id") 37a247da517f ("fs: dlm: move out some hash functionality") 8f2dc78dbc20 ("fs: dlm: make buffer handling per msg") a070a91cf140 ("fs: dlm: add more midcomms hooks") 6fb5cf9d4206 ("fs: dlm: public header in out utility") 8aa31cbf20ad ("fs: dlm: fix connection tcp EOF handling") ba868d9deaab ("fs: dlm: reconnect if socket error report occurs") b38bc9c2b317 ("fs: dlm: fix srcu read lock usage") 2fd8db2dd05d ("fs: dlm: fix missing unlock on error in accept_from_sock()") 9d232469bcd7 ("fs: dlm: add shutdown hook") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 88aa023a2556 ("fs: dlm: cleanup and remove _send_rcom") d10a0b88751a ("fs: dlm: rename socket and app buffer defines") 5b2f981fde8b ("fs: dlm: add midcomms debugfs functionality") 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") 8e2e40860c7f ("fs: dlm: add union in dlm header for lockspace id") 37a247da517f ("fs: dlm: move out some hash functionality") 8f2dc78dbc20 ("fs: dlm: make buffer handling per msg") a070a91cf140 ("fs: dlm: add more midcomms hooks") 6fb5cf9d4206 ("fs: dlm: public header in out utility") 8aa31cbf20ad ("fs: dlm: fix connection tcp EOF handling") ba868d9deaab ("fs: dlm: reconnect if socket error report occurs") b38bc9c2b317 ("fs: dlm: fix srcu read lock usage") 2fd8db2dd05d ("fs: dlm: fix missing unlock on error in accept_from_sock()") 9d232469bcd7 ("fs: dlm: add shutdown hook") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 88aa023a2556 ("fs: dlm: cleanup and remove _send_rcom") d10a0b88751a ("fs: dlm: rename socket and app buffer defines") 5b2f981fde8b ("fs: dlm: add midcomms debugfs functionality") 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") 8e2e40860c7f ("fs: dlm: add union in dlm header for lockspace id") 37a247da517f ("fs: dlm: move out some hash functionality") 8f2dc78dbc20 ("fs: dlm: make buffer handling per msg") a070a91cf140 ("fs: dlm: add more midcomms hooks") 6fb5cf9d4206 ("fs: dlm: public header in out utility") 8aa31cbf20ad ("fs: dlm: fix connection tcp EOF handling") ba868d9deaab ("fs: dlm: reconnect if socket error report occurs") b38bc9c2b317 ("fs: dlm: fix srcu read lock usage") 2fd8db2dd05d ("fs: dlm: fix missing unlock on error in accept_from_sock()") 9d232469bcd7 ("fs: dlm: add shutdown hook") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 88aa023a2556 ("fs: dlm: cleanup and remove _send_rcom") d10a0b88751a ("fs: dlm: rename socket and app buffer defines") 5b2f981fde8b ("fs: dlm: add midcomms debugfs functionality") 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") 8e2e40860c7f ("fs: dlm: add union in dlm header for lockspace id") 37a247da517f ("fs: dlm: move out some hash functionality") 8f2dc78dbc20 ("fs: dlm: make buffer handling per msg") a070a91cf140 ("fs: dlm: add more midcomms hooks") 6fb5cf9d4206 ("fs: dlm: public header in out utility") 8aa31cbf20ad ("fs: dlm: fix connection tcp EOF handling") ba868d9deaab ("fs: dlm: reconnect if socket error report occurs") b38bc9c2b317 ("fs: dlm: fix srcu read lock usage") 2fd8db2dd05d ("fs: dlm: fix missing unlock on error in accept_from_sock()") 9d232469bcd7 ("fs: dlm: add shutdown hook") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix invalid derefence of sb_lvbptr" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 7175e131ebba ("fs: dlm: fix invalid derefence of sb_lvbptr") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7175e131ebba47afef47e6ac4d5bab474d1e6e49 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Mon, 15 Aug 2022 15:43:19 -0400 Subject: [PATCH] fs: dlm: fix invalid derefence of sb_lvbptr I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] <TASK> [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] </TASK> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 354f79254d62..da95ba3c295e 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3651,7 +3651,7 @@ static void send_args(struct dlm_rsb *r, struct dlm_lkb *lkb, case cpu_to_le32(DLM_MSG_REQUEST_REPLY): case cpu_to_le32(DLM_MSG_CONVERT_REPLY): case cpu_to_le32(DLM_MSG_GRANT): - if (!lkb->lkb_lvbptr) + if (!lkb->lkb_lvbptr || !(lkb->lkb_exflags & DLM_LKF_VALBLK)) break; memcpy(ms->m_extra, lkb->lkb_lvbptr, r->res_ls->ls_lvblen); break;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] io_uring/rw: fix unexpected link breakage" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: bf68b5b34311 ("io_uring/rw: fix unexpected link breakage") f3b44f92e59a ("io_uring: move read/write related opcodes to its own file") c98817e6cd44 ("io_uring: move remaining file table manipulation to filetable.c") 735729844819 ("io_uring: move rsrc related data, core, and commands") 3b77495a9723 ("io_uring: split provided buffers handling into its own file") 7aaff708a768 ("io_uring: move cancelation into its own file") 329061d3e2f9 ("io_uring: move poll handling into its own file") cfd22e6b3319 ("io_uring: add opcode name to io_op_defs") 92ac8beaea1f ("io_uring: include and forward-declaration sanitation") c9f06aa7de15 ("io_uring: move io_uring_task (tctx) helpers into its own file") a4ad4f748ea9 ("io_uring: move fdinfo helpers to its own file") e5550a1447bf ("io_uring: use io_is_uring_fops() consistently") 17437f311490 ("io_uring: move SQPOLL related handling into its own file") 59915143e89f ("io_uring: move timeout opcodes and handling into its own file") e418bbc97bff ("io_uring: move our reference counting into a header") 36404b09aa60 ("io_uring: move msg_ring into its own file") f9ead18c1058 ("io_uring: split network related opcodes into its own file") e0da14def1ee ("io_uring: move statx handling to its own file") a9c210cebe13 ("io_uring: move epoll handler to its own file") 4cf90495281b ("io_uring: add a dummy -EOPNOTSUPP prep handler") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf68b5b34311ee57ed40749a1257a30b46127556 Mon Sep 17 00:00:00 2001 From: Pavel Begunkov <asml.silence(a)gmail.com> Date: Tue, 27 Sep 2022 00:44:39 +0100 Subject: [PATCH] io_uring/rw: fix unexpected link breakage req->cqe.res is set in io_read() to the amount of bytes left to be done, which is used to figure out whether to fail a read or not. However, io_read() may do another without returning, and we stash the previous value into ->bytes_done but forget to update cqe.res. Then we ask a read to do strictly less than cqe.res but expect the return to be exactly cqe.res. Fix the bug by updating cqe.res for retries. Cc: stable(a)vger.kernel.org Reported-and-Tested-by: Beld Zhang <beldzhang(a)gmail.com> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/3a1088440c7be98e5800267af922a67da0ef9f13.16642357… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/rw.c b/io_uring/rw.c index 59c92a4616b8..ed14322aadb9 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -793,6 +793,7 @@ int io_read(struct io_kiocb *req, unsigned int issue_flags) return -EAGAIN; } + req->cqe.res = iov_iter_count(&s->iter); /* * Now retry read with the IOCB_WAITQ parts set in the iocb. If * we get -EIOCBQUEUED, then we'll get a notification when the

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] io_uring/rw: fix unexpected link breakage" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: bf68b5b34311 ("io_uring/rw: fix unexpected link breakage") f3b44f92e59a ("io_uring: move read/write related opcodes to its own file") c98817e6cd44 ("io_uring: move remaining file table manipulation to filetable.c") 735729844819 ("io_uring: move rsrc related data, core, and commands") 3b77495a9723 ("io_uring: split provided buffers handling into its own file") 7aaff708a768 ("io_uring: move cancelation into its own file") 329061d3e2f9 ("io_uring: move poll handling into its own file") cfd22e6b3319 ("io_uring: add opcode name to io_op_defs") 92ac8beaea1f ("io_uring: include and forward-declaration sanitation") c9f06aa7de15 ("io_uring: move io_uring_task (tctx) helpers into its own file") a4ad4f748ea9 ("io_uring: move fdinfo helpers to its own file") e5550a1447bf ("io_uring: use io_is_uring_fops() consistently") 17437f311490 ("io_uring: move SQPOLL related handling into its own file") 59915143e89f ("io_uring: move timeout opcodes and handling into its own file") e418bbc97bff ("io_uring: move our reference counting into a header") 36404b09aa60 ("io_uring: move msg_ring into its own file") f9ead18c1058 ("io_uring: split network related opcodes into its own file") e0da14def1ee ("io_uring: move statx handling to its own file") a9c210cebe13 ("io_uring: move epoll handler to its own file") 4cf90495281b ("io_uring: add a dummy -EOPNOTSUPP prep handler") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf68b5b34311ee57ed40749a1257a30b46127556 Mon Sep 17 00:00:00 2001 From: Pavel Begunkov <asml.silence(a)gmail.com> Date: Tue, 27 Sep 2022 00:44:39 +0100 Subject: [PATCH] io_uring/rw: fix unexpected link breakage req->cqe.res is set in io_read() to the amount of bytes left to be done, which is used to figure out whether to fail a read or not. However, io_read() may do another without returning, and we stash the previous value into ->bytes_done but forget to update cqe.res. Then we ask a read to do strictly less than cqe.res but expect the return to be exactly cqe.res. Fix the bug by updating cqe.res for retries. Cc: stable(a)vger.kernel.org Reported-and-Tested-by: Beld Zhang <beldzhang(a)gmail.com> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/3a1088440c7be98e5800267af922a67da0ef9f13.16642357… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/rw.c b/io_uring/rw.c index 59c92a4616b8..ed14322aadb9 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -793,6 +793,7 @@ int io_read(struct io_kiocb *req, unsigned int issue_flags) return -EAGAIN; } + req->cqe.res = iov_iter_count(&s->iter); /* * Now retry read with the IOCB_WAITQ parts set in the iocb. If * we get -EIOCBQUEUED, then we'll get a notification when the

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] io_uring/rw: fix unexpected link breakage" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: bf68b5b34311 ("io_uring/rw: fix unexpected link breakage") f3b44f92e59a ("io_uring: move read/write related opcodes to its own file") c98817e6cd44 ("io_uring: move remaining file table manipulation to filetable.c") 735729844819 ("io_uring: move rsrc related data, core, and commands") 3b77495a9723 ("io_uring: split provided buffers handling into its own file") 7aaff708a768 ("io_uring: move cancelation into its own file") 329061d3e2f9 ("io_uring: move poll handling into its own file") cfd22e6b3319 ("io_uring: add opcode name to io_op_defs") 92ac8beaea1f ("io_uring: include and forward-declaration sanitation") c9f06aa7de15 ("io_uring: move io_uring_task (tctx) helpers into its own file") a4ad4f748ea9 ("io_uring: move fdinfo helpers to its own file") e5550a1447bf ("io_uring: use io_is_uring_fops() consistently") 17437f311490 ("io_uring: move SQPOLL related handling into its own file") 59915143e89f ("io_uring: move timeout opcodes and handling into its own file") e418bbc97bff ("io_uring: move our reference counting into a header") 36404b09aa60 ("io_uring: move msg_ring into its own file") f9ead18c1058 ("io_uring: split network related opcodes into its own file") e0da14def1ee ("io_uring: move statx handling to its own file") a9c210cebe13 ("io_uring: move epoll handler to its own file") 4cf90495281b ("io_uring: add a dummy -EOPNOTSUPP prep handler") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf68b5b34311ee57ed40749a1257a30b46127556 Mon Sep 17 00:00:00 2001 From: Pavel Begunkov <asml.silence(a)gmail.com> Date: Tue, 27 Sep 2022 00:44:39 +0100 Subject: [PATCH] io_uring/rw: fix unexpected link breakage req->cqe.res is set in io_read() to the amount of bytes left to be done, which is used to figure out whether to fail a read or not. However, io_read() may do another without returning, and we stash the previous value into ->bytes_done but forget to update cqe.res. Then we ask a read to do strictly less than cqe.res but expect the return to be exactly cqe.res. Fix the bug by updating cqe.res for retries. Cc: stable(a)vger.kernel.org Reported-and-Tested-by: Beld Zhang <beldzhang(a)gmail.com> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/3a1088440c7be98e5800267af922a67da0ef9f13.16642357… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/rw.c b/io_uring/rw.c index 59c92a4616b8..ed14322aadb9 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -793,6 +793,7 @@ int io_read(struct io_kiocb *req, unsigned int issue_flags) return -EAGAIN; } + req->cqe.res = iov_iter_count(&s->iter); /* * Now retry read with the IOCB_WAITQ parts set in the iocb. If * we get -EIOCBQUEUED, then we'll get a notification when the

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] io_uring/net: handle -EINPROGRESS correct for" failed to apply to 5.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT") f9ead18c1058 ("io_uring: split network related opcodes into its own file") e0da14def1ee ("io_uring: move statx handling to its own file") a9c210cebe13 ("io_uring: move epoll handler to its own file") 4cf90495281b ("io_uring: add a dummy -EOPNOTSUPP prep handler") 99f15d8d6136 ("io_uring: move uring_cmd handling to its own file") cd40cae29ef8 ("io_uring: split out open/close operations") 453b329be5ea ("io_uring: separate out file table handling code") f4c163dd7d4b ("io_uring: split out fadvise/madvise operations") 0d5847274037 ("io_uring: split out fs related sync/fallocate functions") 531113bbd5bf ("io_uring: split out splice related operations") 11aeb71406dd ("io_uring: split out filesystem related operations") e28683bdfc2f ("io_uring: move nop into its own file") 5e2a18d93fec ("io_uring: move xattr related opcodes to its own file") 97b388d70b53 ("io_uring: handle completions in the core") de23077eda61 ("io_uring: set completion results upfront") e27f928ee1cb ("io_uring: add io_uring_types.h") 4d4c9cff4f70 ("io_uring: define a request type cleanup handler") 890968dc0336 ("io_uring: unify struct io_symlink and io_hardlink") 9a3a11f977f9 ("io_uring: convert iouring_cmd to io_cmd_type") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3fb1bd68817288729179444caf1fd5c5c4d2d65d Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Tue, 4 Oct 2022 20:29:48 -0600 Subject: [PATCH] io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT We treat EINPROGRESS like EAGAIN, but if we're retrying post getting EINPROGRESS, then we just need to check the socket for errors and terminate the request. This was exposed on a bluetooth connection request which ends up taking a while and hitting EINPROGRESS, and yields a CQE result of -EBADFD because we're retrying a connect on a socket that is now connected. Cc: stable(a)vger.kernel.org Fixes: 87f80d623c6c ("io_uring: handle connect -EINPROGRESS like -EAGAIN") Link: https://github.com/axboe/liburing/issues/671 Reported-by: Aidan Sun <aidansun05(a)gmail.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/net.c b/io_uring/net.c index caa6a803cb72..8c7226b5bf41 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -46,6 +46,7 @@ struct io_connect { struct file *file; struct sockaddr __user *addr; int addr_len; + bool in_progress; }; struct io_sr_msg { @@ -1386,6 +1387,7 @@ int io_connect_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) conn->addr = u64_to_user_ptr(READ_ONCE(sqe->addr)); conn->addr_len = READ_ONCE(sqe->addr2); + conn->in_progress = false; return 0; } @@ -1397,6 +1399,16 @@ int io_connect(struct io_kiocb *req, unsigned int issue_flags) int ret; bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK; + if (connect->in_progress) { + struct socket *socket; + + ret = -ENOTSOCK; + socket = sock_from_file(req->file); + if (socket) + ret = sock_error(socket->sk); + goto out; + } + if (req_has_async_data(req)) { io = req->async_data; } else { @@ -1413,13 +1425,17 @@ int io_connect(struct io_kiocb *req, unsigned int issue_flags) ret = __sys_connect_file(req->file, &io->address, connect->addr_len, file_flags); if ((ret == -EAGAIN || ret == -EINPROGRESS) && force_nonblock) { - if (req_has_async_data(req)) - return -EAGAIN; - if (io_alloc_async_data(req)) { - ret = -ENOMEM; - goto out; + if (ret == -EINPROGRESS) { + connect->in_progress = true; + } else { + if (req_has_async_data(req)) + return -EAGAIN; + if (io_alloc_async_data(req)) { + ret = -ENOMEM; + goto out; + } + memcpy(req->async_data, &__io, sizeof(__io)); } - memcpy(req->async_data, &__io, sizeof(__io)); return -EAGAIN; } if (ret == -ERESTARTSYS)

2 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2022