Skip to content

Conversation

@PlaidCat
Copy link
Collaborator

No description provided.

PlaidCat and others added 3 commits January 13, 2025 13:23
THIS IS BREAKING AND NOT INTENDED TO BE SHIPPED
Since we need to make sure all our checks run BEFORE the commit is
pushed to a branch we're swithcing this to `on pull_request_target` to
enable external contibutors.
@PlaidCat PlaidCat requested a review from bmastbergen January 14, 2025 19:04
@PlaidCat PlaidCat closed this Jan 14, 2025
@PlaidCat
Copy link
Collaborator Author

This did not do what I expected

PlaidCat and others added 2 commits January 14, 2025 15:53
Since we need to make sure all our checks run BEFORE the commit is
pushed to a branch we're swithcing this to `on pull_request_target` to
enable external contibutors.
@PlaidCat PlaidCat reopened this Jan 14, 2025
Testing resubmission fix
trying to move from:
merge_commit_sha to HEAD
PlaidCat and others added 12 commits January 14, 2025 18:40
Since we need to make sure external contributors code actually compiles
prior to merging. To get access to the forked repos merge request we
need to switch over our push/pull_request to pull_request_target.  In
addition we're fixing up some Naming Conventions, adding aarch64 to this
branch and fixing the naming so that we can quickly identify if the CI
is for x86_64 or aarch64.
@PlaidCat PlaidCat force-pushed the {jmaple}_ciqlts8_8 branch 3 times, most recently from 105bc2d to ebe2551 Compare January 15, 2025 22:20
@PlaidCat PlaidCat force-pushed the {jmaple}_ciqlts8_8 branch 2 times, most recently from 5a2bd5b to d38c5b9 Compare January 15, 2025 22:27
@PlaidCat
Copy link
Collaborator Author

Closing for now

@PlaidCat PlaidCat closed this Jan 15, 2025
github-actions bot pushed a commit that referenced this pull request Sep 19, 2025
syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:

  1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination

As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.

Let's call reqsk_fastopen_remove() in tcp_disconnect().

[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
 <IRQ>
 tcp_write_timer (net/ipv4/tcp_timer.c:738)
 call_timer_fn (kernel/time/timer.c:1747)
 __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
 timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
 tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
 __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
 tmigr_handle_remote (kernel/time/timer_migration.c:1096)
 handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
 irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
 </IRQ>

Fixes: 8336886 ("tcp: TCP Fast Open Server - support TFO listeners")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
github-actions bot pushed a commit that referenced this pull request Sep 25, 2025
[ Upstream commit 45c8a6c ]

syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:

  1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination

As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.

Let's call reqsk_fastopen_remove() in tcp_disconnect().

[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
 <IRQ>
 tcp_write_timer (net/ipv4/tcp_timer.c:738)
 call_timer_fn (kernel/time/timer.c:1747)
 __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
 timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
 tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
 __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
 tmigr_handle_remote (kernel/time/timer_migration.c:1096)
 handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
 irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
 </IRQ>

Fixes: 8336886 ("tcp: TCP Fast Open Server - support TFO listeners")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
github-actions bot pushed a commit that referenced this pull request Oct 4, 2025
There is a race condition between dm device suspend and table load that
can lead to null pointer dereference. The issue occurs when suspend is
invoked before table load completes:

BUG: kernel NULL pointer dereference, address: 0000000000000054
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50
Call Trace:
  <TASK>
  blk_mq_quiesce_queue+0x2c/0x50
  dm_stop_queue+0xd/0x20
  __dm_suspend+0x130/0x330
  dm_suspend+0x11a/0x180
  dev_suspend+0x27e/0x560
  ctl_ioctl+0x4cf/0x850
  dm_ctl_ioctl+0xd/0x20
  vfs_ioctl+0x1d/0x50
  __se_sys_ioctl+0x9b/0xc0
  __x64_sys_ioctl+0x19/0x30
  x64_sys_call+0x2c4a/0x4620
  do_syscall_64+0x9e/0x1b0

The issue can be triggered as below:

T1 						T2
dm_suspend					table_load
__dm_suspend					dm_setup_md_queue
						dm_mq_init_request_queue
						blk_mq_init_allocated_queue
						=> q->mq_ops = set->ops; (1)
dm_stop_queue / dm_wait_for_completion
=> q->tag_set NULL pointer!	(2)
						=> q->tag_set = set; (3)

Fix this by checking if a valid table (map) exists before performing
request-based suspend and waiting for target I/O. When map is NULL,
skip these table-dependent suspend steps.

Even when map is NULL, no I/O can reach any target because there is
no table loaded; I/O submitted in this state will fail early in the
DM layer. Skipping the table-dependent suspend logic in this case
is safe and avoids NULL pointer dereferences.

Fixes: c4576ae ("dm: fix request-based dm's use of dm_wait_for_completion")
Cc: stable@vger.kernel.org
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
github-actions bot pushed a commit that referenced this pull request Oct 15, 2025
commit 8d33a03 upstream.

There is a race condition between dm device suspend and table load that
can lead to null pointer dereference. The issue occurs when suspend is
invoked before table load completes:

BUG: kernel NULL pointer dereference, address: 0000000000000054
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50
Call Trace:
  <TASK>
  blk_mq_quiesce_queue+0x2c/0x50
  dm_stop_queue+0xd/0x20
  __dm_suspend+0x130/0x330
  dm_suspend+0x11a/0x180
  dev_suspend+0x27e/0x560
  ctl_ioctl+0x4cf/0x850
  dm_ctl_ioctl+0xd/0x20
  vfs_ioctl+0x1d/0x50
  __se_sys_ioctl+0x9b/0xc0
  __x64_sys_ioctl+0x19/0x30
  x64_sys_call+0x2c4a/0x4620
  do_syscall_64+0x9e/0x1b0

The issue can be triggered as below:

T1 						T2
dm_suspend					table_load
__dm_suspend					dm_setup_md_queue
						dm_mq_init_request_queue
						blk_mq_init_allocated_queue
						=> q->mq_ops = set->ops; (1)
dm_stop_queue / dm_wait_for_completion
=> q->tag_set NULL pointer!	(2)
						=> q->tag_set = set; (3)

Fix this by checking if a valid table (map) exists before performing
request-based suspend and waiting for target I/O. When map is NULL,
skip these table-dependent suspend steps.

Even when map is NULL, no I/O can reach any target because there is
no table loaded; I/O submitted in this state will fail early in the
DM layer. Skipping the table-dependent suspend logic in this case
is safe and avoids NULL pointer dereferences.

Fixes: c4576ae ("dm: fix request-based dm's use of dm_wait_for_completion")
Cc: stable@vger.kernel.org
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
github-actions bot pushed a commit that referenced this pull request Oct 28, 2025
JIRA: https://issues.redhat.com/browse/RHEL-115628
CVE: CVE-2025-39955

Upstream commit:
commit 45c8a6c
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Mon Sep 15 17:56:46 2025 +0000

    tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().

    syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
    in the TCP_ESTABLISHED state. [0]

    syzbot reused the server-side TCP Fast Open socket as a new client before
    the TFO socket completes 3WHS:

      1. accept()
      2. connect(AF_UNSPEC)
      3. connect() to another destination

    As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
    it to TCP_CLOSE and makes connect() possible, which restarts timers.

    Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
    retransmit timer triggered the warning and the intended packet was not
    retransmitted.

    Let's call reqsk_fastopen_remove() in tcp_disconnect().

    [0]:
    WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Modules linked in:
    CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
    RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
    RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
    RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
    RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
    R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
    R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
    FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
    Call Trace:
     <IRQ>
     tcp_write_timer (net/ipv4/tcp_timer.c:738)
     call_timer_fn (kernel/time/timer.c:1747)
     __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
     timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
     tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
     __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
     tmigr_handle_remote (kernel/time/timer_migration.c:1096)
     handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
     irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
     </IRQ>

    Fixes: 8336886 ("tcp: TCP Fast Open Server - support TFO listeners")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
github-actions bot pushed a commit that referenced this pull request Nov 4, 2025
JIRA: https://issues.redhat.com/browse/RHEL-115580
CVE: CVE-2025-39955

Upstream commit:
commit 45c8a6c
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Mon Sep 15 17:56:46 2025 +0000

    tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().

    syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
    in the TCP_ESTABLISHED state. [0]

    syzbot reused the server-side TCP Fast Open socket as a new client before
    the TFO socket completes 3WHS:

      1. accept()
      2. connect(AF_UNSPEC)
      3. connect() to another destination

    As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
    it to TCP_CLOSE and makes connect() possible, which restarts timers.

    Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
    retransmit timer triggered the warning and the intended packet was not
    retransmitted.

    Let's call reqsk_fastopen_remove() in tcp_disconnect().

    [0]:
    WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Modules linked in:
    CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
    RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
    RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
    RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
    RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
    R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
    R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
    FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
    Call Trace:
     <IRQ>
     tcp_write_timer (net/ipv4/tcp_timer.c:738)
     call_timer_fn (kernel/time/timer.c:1747)
     __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
     timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
     tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
     __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
     tmigr_handle_remote (kernel/time/timer_migration.c:1096)
     handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
     irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
     </IRQ>

    Fixes: 8336886 ("tcp: TCP Fast Open Server - support TFO listeners")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
github-actions bot pushed a commit to bmastbergen/kernel-src-tree that referenced this pull request Nov 6, 2025
JIRA: https://issues.redhat.com/browse/RHEL-119009
Upstream Status: kernel/git/torvalds/linux.git

commit 8d33a03
Author: Zheng Qixing <zhengqixing@huawei.com>
Date:   Tue Aug 26 15:42:04 2025 +0800

    dm: fix NULL pointer dereference in __dm_suspend()

    There is a race condition between dm device suspend and table load that
    can lead to null pointer dereference. The issue occurs when suspend is
    invoked before table load completes:

    BUG: kernel NULL pointer dereference, address: 0000000000000054
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b ctrliq#62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
    RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50
    Call Trace:
      <TASK>
      blk_mq_quiesce_queue+0x2c/0x50
      dm_stop_queue+0xd/0x20
      __dm_suspend+0x130/0x330
      dm_suspend+0x11a/0x180
      dev_suspend+0x27e/0x560
      ctl_ioctl+0x4cf/0x850
      dm_ctl_ioctl+0xd/0x20
      vfs_ioctl+0x1d/0x50
      __se_sys_ioctl+0x9b/0xc0
      __x64_sys_ioctl+0x19/0x30
      x64_sys_call+0x2c4a/0x4620
      do_syscall_64+0x9e/0x1b0

    The issue can be triggered as below:

    T1                                              T2
    dm_suspend                                      table_load
    __dm_suspend                                    dm_setup_md_queue
                                                    dm_mq_init_request_queue
                                                    blk_mq_init_allocated_queue
                                                    => q->mq_ops = set->ops; (1)
    dm_stop_queue / dm_wait_for_completion
    => q->tag_set NULL pointer!     (2)
                                                    => q->tag_set = set; (3)

    Fix this by checking if a valid table (map) exists before performing
    request-based suspend and waiting for target I/O. When map is NULL,
    skip these table-dependent suspend steps.

    Even when map is NULL, no I/O can reach any target because there is
    no table loaded; I/O submitted in this state will fail early in the
    DM layer. Skipping the table-dependent suspend logic in this case
    is safe and avoids NULL pointer dereferences.

    Fixes: c4576ae ("dm: fix request-based dm's use of dm_wait_for_completion")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
github-actions bot pushed a commit that referenced this pull request Nov 12, 2025
JIRA: https://issues.redhat.com/browse/RHEL-119008
Upstream Status: kernel/git/torvalds/linux.git

commit 8d33a03
Author: Zheng Qixing <zhengqixing@huawei.com>
Date:   Tue Aug 26 15:42:04 2025 +0800

    dm: fix NULL pointer dereference in __dm_suspend()

    There is a race condition between dm device suspend and table load that
    can lead to null pointer dereference. The issue occurs when suspend is
    invoked before table load completes:

    BUG: kernel NULL pointer dereference, address: 0000000000000054
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
    RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50
    Call Trace:
      <TASK>
      blk_mq_quiesce_queue+0x2c/0x50
      dm_stop_queue+0xd/0x20
      __dm_suspend+0x130/0x330
      dm_suspend+0x11a/0x180
      dev_suspend+0x27e/0x560
      ctl_ioctl+0x4cf/0x850
      dm_ctl_ioctl+0xd/0x20
      vfs_ioctl+0x1d/0x50
      __se_sys_ioctl+0x9b/0xc0
      __x64_sys_ioctl+0x19/0x30
      x64_sys_call+0x2c4a/0x4620
      do_syscall_64+0x9e/0x1b0

    The issue can be triggered as below:

    T1                                              T2
    dm_suspend                                      table_load
    __dm_suspend                                    dm_setup_md_queue
                                                    dm_mq_init_request_queue
                                                    blk_mq_init_allocated_queue
                                                    => q->mq_ops = set->ops; (1)
    dm_stop_queue / dm_wait_for_completion
    => q->tag_set NULL pointer!     (2)
                                                    => q->tag_set = set; (3)

    Fix this by checking if a valid table (map) exists before performing
    request-based suspend and waiting for target I/O. When map is NULL,
    skip these table-dependent suspend steps.

    Even when map is NULL, no I/O can reach any target because there is
    no table loaded; I/O submitted in this state will fail early in the
    DM layer. Skipping the table-dependent suspend logic in this case
    is safe and avoids NULL pointer dereferences.

    Fixes: c4576ae ("dm: fix request-based dm's use of dm_wait_for_completion")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant