Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 在 Linux 核心中，已解決下列弱點： nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at:
    nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at:
    __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770
    __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0
    __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0
    __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687):
    [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686):
    [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684):
    [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0:
    ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ?
    _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- (CVE-2021-47041)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 在 Linux 内核中，已解决以下漏洞： nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at:
    nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at:
    __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770
    __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0
    __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0
    __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687):
    [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686):
    [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684):
    [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0:
    ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ?
    _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- (CVE-2021-47041)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

リモートの SUSE Linux SLES15 / SLES_SAP15 ホストには、SUSE-SU-2024:1650-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    SUSE Linux Enterprise 15 SP2 カーネルが更新され、さまざまなセキュリティバグ修正が行われています。


    次のセキュリティバグを修正しました。

    - CVE-2024-26840: cachefiles_add_cache() のメモリリークを修正しました (bsc#1222976)。
    - CVE-2021-47113: 2 番目の ref の挿入に失敗した場合、btrfs rename_exchange を中止する (bsc#1221543)。
    - CVE-2021-47131: TLS デバイスが停止および起動した後のメモリ解放後使用 (Use After Free) を修正 (bsc#1221545)。
    - CVE-2024-26852: ip6_route_mpath_notify() で発生する可能性のある UAF を回避するために net/ipv6 を修正しました (bsc#1223057)。
    - CVE-2021-46955: IPv4 パケットをフラグメント化するときの、openvswitch の領域外読み取りを修正しました (bsc#1220513)。
    - CVE-2024-26862: ignore_outgoing 周辺のパケット注釈データの競合を修正しました (bsc#1223111)。
    - CVE-2024-0639: net/sctp/socket.c の sctp_auto_asconf_init で発見されたデッドロックによるサービス拒否の脆弱性を修正しました (bsc#1218917)。
    - CVE-2024-27043: 異なる場所での edia/dvbdev のメモリ解放後使用 (Use After Free) を修正しました (bsc#1223824)。
    - CVE-2022-48631: eh_entries == 0 かつ eh_depth > 0 となるエクステントを解析する際の ext4 でのバグを修正しました (bsc#1223475)。
    - CVE-2024-23307: x86、ARM md、raid、raid5 モジュールにおける整数オーバーフローまたはラップアラウンドの脆弱性が修正されました (bsc#1219169)。
    - CVE-2022-48651: skb->mac_header (bsc#1223513) の設定解除によって引き起こされる ipvlan の領域外バグを修正しました。
    - CVE-2024-26816: CONFIG_XEN_PV=y でビルドする場合に .notes セクションの再配置を無視するように修正しました (bsc#1222624)。
    - CVE-2024-26906: copy_from_kernel_nofault() の vsyscall ページ読み取りが許可されません (bsc#1223202)。
    - CVE-2024-26689: encode_cap_msg() のメモリ解放後使用 (Use After Free) を修正しました (bsc#1222503)。
    - CVE-2021-47041: write_lock なしで sk_user_data を設定しないでください (bsc#1220755)。
    - CVE-2021-47074: nvme_loop_create_ctrl() のメモリリークを修正しました (bsc#1220854)。
    - CVE-2024-26744: rdma/srpt の srpt_service_guid パラメーターにおける NULL ポインターデリファレンスを修正しました (bsc#1222449)。


Tenable は、前述の記述ブロックを SUSE セキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:1642-1 advisory.

    The SUSE Linux Enterprise 15 SP3 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2024-26840: Fixed a memory leak in cachefiles_add_cache() (bsc#1222976).
    - CVE-2021-47113: Abort btrfs rename_exchange if we fail to insert the second ref (bsc#1221543).
    - CVE-2021-47131: Fixed a use-after-free after the TLS device goes down and up (bsc#1221545).
    - CVE-2024-26852: Fixed net/ipv6 to avoid possible UAF in ip6_route_mpath_notify() (bsc#1223057).
    - CVE-2021-46955: Fixed an out-of-bounds read with openvswitch, when fragmenting IPv4 packets     (bsc#1220513).
    - CVE-2024-26862: Fixed packet annotate data-races around ignore_outgoing (bsc#1223111).
    - CVE-2024-0639: Fixed a denial-of-service vulnerability due to a deadlock found in sctp_auto_asconf_init     in net/sctp/socket.c (bsc#1218917).
    - CVE-2024-27043: Fixed a use-after-free in edia/dvbdev in different places (bsc#1223824).
    - CVE-2022-48631: Fixed a bug in ext4, when parsing extents where eh_entries == 0 and eh_depth > 0     (bsc#1223475).
    - CVE-2024-23307: Fixed Integer Overflow or Wraparound vulnerability in x86 and ARM md, raid, raid5     modules (bsc#1219169).
    - CVE-2022-48651: Fixed an out-of-bound bug in ipvlan caused by unset skb->mac_header (bsc#1223513).
    - CVE-2024-26906: Disallowed vsyscall page read for copy_from_kernel_nofault() (bsc#1223202).
    - CVE-2024-26816: Fixed relocations in .notes section when building with CONFIG_XEN_PV=y by ignoring them     (bsc#1222624).
    - CVE-2024-26610: Fixed memory corruption in wifi/iwlwifi (bsc#1221299).
    - CVE-2024-26689: Fixed a use-after-free in encode_cap_msg() (bsc#1222503).
    - CVE-2021-47041: Don't set sk_user_data without write_lock (bsc#1220755).
    - CVE-2021-47074: Fixed memory leak in nvme_loop_create_ctrl() (bsc#1220854).
    - CVE-2024-26744: Fixed null pointer dereference in srpt_service_guid parameter in rdma/srpt     (bsc#1222449).


Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in     state_change sk callback We are not changing anything in the TCP connection state so we should not take a     write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same     system, where state_change callbacks on the host and on the controller side have causal relationship and     made lockdep report on this with blktests: ================================ WARNING: inconsistent lock     state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-     ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at:
    nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at:
    __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80     nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20     tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430     ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420     ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770
    __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0
    __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0
    __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310     inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0     [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core]     nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610     vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40     entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687):
    [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686):
    [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684):
    [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>]     do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ----     lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0:
    ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090     (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38     (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0     (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30     (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme     Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call     Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ?     stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ?
    _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ?     enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ?     tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150     [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ?     sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]     nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- (CVE-2021-47041)

Note that Nessus relies on the presence of the package as reported by the vendor.

リモートの SUSE Linux SLES15 / SLES_SAP15 ホストには、SUSE-SU-2024:1642-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    SUSE Linux Enterprise 15 SP3 カーネルが更新され、さまざまなセキュリティバグ修正が行われています。


    次のセキュリティバグを修正しました。

    - CVE-2024-26840: cachefiles_add_cache() のメモリリークを修正しました (bsc#1222976)。
    - CVE-2021-47113: 2 番目の ref の挿入に失敗した場合、btrfs rename_exchange を中止する (bsc#1221543)。
    - CVE-2021-47131: TLS デバイスが停止および起動した後のメモリ解放後使用 (Use After Free) を修正 (bsc#1221545)。
    - CVE-2024-26852: ip6_route_mpath_notify() で発生する可能性のある UAF を回避するために net/ipv6 を修正しました (bsc#1223057)。
    - CVE-2021-46955: IPv4 パケットをフラグメント化するときの、openvswitch の領域外読み取りを修正しました (bsc#1220513)。
    - CVE-2024-26862: ignore_outgoing 周辺のパケット注釈データの競合を修正しました (bsc#1223111)。
    - CVE-2024-0639: net/sctp/socket.c の sctp_auto_asconf_init で発見されたデッドロックによるサービス拒否の脆弱性を修正しました (bsc#1218917)。
    - CVE-2024-27043: 異なる場所での edia/dvbdev のメモリ解放後使用 (Use After Free) を修正しました (bsc#1223824)。
    - CVE-2022-48631: eh_entries == 0 かつ eh_depth > 0 となるエクステントを解析する際の ext4 でのバグを修正しました (bsc#1223475)。
    - CVE-2024-23307: x86、ARM md、raid、raid5 モジュールにおける整数オーバーフローまたはラップアラウンドの脆弱性が修正されました (bsc#1219169)。
    - CVE-2022-48651: skb->mac_header (bsc#1223513) の設定解除によって引き起こされる ipvlan の領域外バグを修正しました。
    - CVE-2024-26906: copy_from_kernel_nofault() の vsyscall ページ読み取りが許可されません (bsc#1223202)。
    - CVE-2024-26816: CONFIG_XEN_PV=y でビルドする場合に .notes セクションの再配置を無視するように修正しました (bsc#1222624)。
    - CVE-2024-26610: wifi/iwlwifi (bsc#1221299) のメモリ破損を修正しました。
    - CVE-2024-26689: encode_cap_msg() のメモリ解放後使用 (Use After Free) を修正しました (bsc#1222503)。
    - CVE-2021-47041: write_lock なしで sk_user_data を設定しないでください (bsc#1220755)。
    - CVE-2021-47074: nvme_loop_create_ctrl() のメモリリークを修正しました (bsc#1220854)。
    - CVE-2024-26744: rdma/srpt の srpt_service_guid パラメーターにおける NULL ポインターデリファレンスを修正しました (bsc#1222449)。


Tenable は、前述の記述ブロックを SUSE セキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルにおいて、以下の脆弱性は解決されました： nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at:
    nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at:
    __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770
    __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0
    __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0
    __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687):
    [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686):
    [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684):
    [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0:
    ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ?
    _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- (CVE-2021-47041)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:1650-1 advisory.

    The SUSE Linux Enterprise 15 SP2 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2024-26840: Fixed a memory leak in cachefiles_add_cache() (bsc#1222976).
    - CVE-2021-47113: Abort btrfs rename_exchange if we fail to insert the second ref (bsc#1221543).
    - CVE-2021-47131: Fixed a use-after-free after the TLS device goes down and up (bsc#1221545).
    - CVE-2024-26852: Fixed net/ipv6 to avoid possible UAF in ip6_route_mpath_notify() (bsc#1223057).
    - CVE-2021-46955: Fixed an out-of-bounds read with openvswitch, when fragmenting IPv4 packets     (bsc#1220513).
    - CVE-2024-26862: Fixed packet annotate data-races around ignore_outgoing (bsc#1223111).
    - CVE-2024-0639: Fixed a denial-of-service vulnerability due to a deadlock found in sctp_auto_asconf_init     in net/sctp/socket.c (bsc#1218917).
    - CVE-2024-27043: Fixed a use-after-free in edia/dvbdev in different places (bsc#1223824).
    - CVE-2022-48631: Fixed a bug in ext4, when parsing extents where eh_entries == 0 and eh_depth > 0     (bsc#1223475).
    - CVE-2024-23307: Fixed Integer Overflow or Wraparound vulnerability in x86 and ARM md, raid, raid5     modules (bsc#1219169).
    - CVE-2022-48651: Fixed an out-of-bound bug in ipvlan caused by unset skb->mac_header (bsc#1223513).
    - CVE-2024-26816: Fixed relocations in .notes section when building with CONFIG_XEN_PV=y by ignoring them     (bsc#1222624).
    - CVE-2024-26906: Disallowed vsyscall page read for copy_from_kernel_nofault() (bsc#1223202).
    - CVE-2024-26689: Fixed a use-after-free in encode_cap_msg() (bsc#1222503).
    - CVE-2021-47041: Don't set sk_user_data without write_lock (bsc#1220755).
    - CVE-2021-47074: Fixed memory leak in nvme_loop_create_ctrl() (bsc#1220854).
    - CVE-2024-26744: Fixed null pointer dereference in srpt_service_guid parameter in rdma/srpt     (bsc#1222449).


Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
230198	Linux Distros 未修補弱點：CVE-2021-47041	Nessus	Misc.	2025/3/5	2025/3/5	medium
230198	Linux Distros 未修补的漏洞: CVE-2021-47041	Nessus	Misc.	2025/3/5	2025/3/5	medium
197173	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2024:1650-1)	Nessus	SuSE Local Security Checks	2024/5/16	2024/12/27	high
197045	SUSE SLES15 Security Update : kernel (SUSE-SU-2024:1642-1)	Nessus	SuSE Local Security Checks	2024/5/15	2024/12/27	high
230198	Linux Distros Unpatched Vulnerability : CVE-2021-47041	Nessus	Misc.	2025/3/5	2025/3/5	medium
195267	EulerOS 2.0 SP10 : kernel (EulerOS-SA-2024-1592)	Nessus	Huawei Local Security Checks	2024/5/9	2024/7/9	high
202681	EulerOS Virtualization 2.10.0 : kernel (EulerOS-SA-2024-1984)	Nessus	Huawei Local Security Checks	2024/7/18	2024/7/19	high
202537	EulerOS 2.0 SP9 : kernel (EulerOS-SA-2024-1964)	Nessus	Huawei Local Security Checks	2024/7/16	2025/2/17	high
197045	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2024:1642-1)	Nessus	SuSE Local Security Checks	2024/5/15	2024/12/27	high
230198	Linux Distros のパッチ未適用の脆弱性: CVE-2021-47041	Nessus	Misc.	2025/3/5	2025/3/5	medium
197173	SUSE SLES15 Security Update : kernel (SUSE-SU-2024:1650-1)	Nessus	SuSE Local Security Checks	2024/5/16	2024/12/27	high

检测

插件搜索

medium

medium

high

high

medium

high

high

high

high

medium

high