リモートの CentOS Linux 9 ホストには、kernel-5.14.0-626.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer.
    This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP:
    0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100
    __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (CVE-2025-38461)

  - Linux カーネルでは、以下の脆弱性が解決されています: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). (CVE-2025-39718)

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

リモートの CentOS Linux 9 ホストには、cups-2.3.3op2-35.el9 ビルド変更ログで言及されているように、複数の脆弱性の影響を受けるパッケージがインストールされています。

  - CUPS 承認処理の認証バイパスCVE-2025-58060

  - リモート DoS につながる CUPS ipp_read_io() の Null ポインターデリファレンスCVE-2025-58364]

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

リモートの CentOS Linux 9 ホストには、kernel-5.14.0-620.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: libfs: fix get_stashed_dentry() get_stashed_dentry() tries to optimistically retrieve a stashed dentry from a provided location. It needs to ensure to hold rcu lock before it dereference the stashed location to prevent UAF issues. Use rcu_dereference() instead of READ_ONCE() it's effectively equivalent with some lockdep bells and whistles and it communicates clearly that this expects rcu protection. (CVE-2024-46801)

  - Linux カーネルでは、以下の脆弱性が解決されています: fs/fhandle.c: fix a race in call of has_locked_children() may_decode_fh() is calling has_locked_children() while holding no locks. That's an oopsable race... The rest of the callers are safe since they are holding namespace_sem and are guaranteed a positive refcount on the mount in question. Rename the current has_locked_children() to
    __has_locked_children(), make it static and switch the fs/namespace.c users to it. Make has_locked_children() a wrapper for __has_locked_children(), calling the latter under read_seqlock_excl(&mount_lock). (CVE-2025-38306)

  - Linux カーネルでは、以下の脆弱性が解決されています: do_change_type(): refuse to operate on unmounted/not ours mounts Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2).
    (CVE-2025-38498)

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

リモートの CentOS Linux 9 ホストには、kernel-5.14.0-617.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: sctp: linearize cloned gso packets in sctp_rcv A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs. syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG:
    KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline] and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
    __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] This patch fixes it by linearizing cloned gso packets in sctp_rcv(). (CVE-2025-38718)

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

リモートの CentOS Linux 9 ホストには、python3.9-3.9.23-2.el9 ビルド変更ログで言及されている脆弱性の影響を受けるパッケージがインストールされています。

  - CPython tarfile モジュールに、TarFile 抽出およびエントリ列挙 API に影響する不具合があります。tar の実装が負のオフセットの tar アーカイブをエラーなしで処理する可能性があります。その結果、悪意をもって細工された tar アーカイブの解析中に、無限ループおよびデッドロックが発生します。この脆弱性は、tarfile モジュールをインポートした後に、以下のパッチを含めることにより緩和できます
    https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1 (CVE-2025-8194)

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

リモートの CentOS Linux 9 ホストには、libarchive-3.5.3-6.el9 ビルド変更ログで言及されている脆弱性の影響を受けるパッケージがインストールされています。

  - libarchive ライブラリ、特に archive_read_format_rar_seek_data() 関数内で、脆弱性が特定されています。この欠陥には整数オーバーフローが含まれており、最終的に二重解放状態につながる可能性があります。二重解放の脆弱性を悪用するとメモリ破損が発生し、攻撃者は任意のコードを実行するか、サービス拒否状態を引き起こす可能性があります。(CVE-2025-5914)

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

リモートの CentOS Linux 9 ホストには、kernel-5.14.0-605.el9 ビルド変更ログで言及されているように、複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak. (CVE-2022-49024)

  - Linux カーネルでは、以下の脆弱性が解決されています: udp: Fix memory accounting leak. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to
    __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 (net: implement per-cpu reserves for memory_allocated), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data) (CVE-2025-22058)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-604.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: idpf: fix adapter NULL pointer dereference on reboot With SRIOV enabled, idpf ends up calling into idpf_remove() twice. First via idpf_shutdown() and then again when idpf_remove() calls into sriov_disable(), because the VF devices use the idpf driver, hence the same remove routine. When that happens, it is possible for the adapter to be NULL from the first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net/<netif>/device/sriov_numvfs reboot BUG: kernel NULL pointer dereference, address:
    0000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() call in idpf_shutdown() with idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform the bulk of the cleanup, such as stopping the init task, freeing IRQs, destroying the vports and freeing the mailbox. This avoids the calls to sriov_disable() in addition to a small netdev cleanup, and destroying workqueues, which don't seem to be required on shutdown. (CVE-2025-22065)

  - Linux カーネルでは、以下の脆弱性が解決されています: idpf: convert workqueues to unbound When a workqueue is created with `WQ_UNBOUND`, its work items are served by special worker-pools, whose host workers are not bound to any specific CPU. In the default configuration (i.e. when `queue_delayed_work` and friends do not specify which CPU to run the work item on), `WQ_UNBOUND` allows the work item to be executed on any CPU in the same node of the CPU it was enqueued on. While this solution potentially sacrifices locality, it avoids contention with other processes that might dominate the CPU time of the processor the work item was scheduled on. This is not just a theoretical problem: in a particular scenario misconfigured process was hogging most of the time from CPU0, leaving less than 0.5% of its CPU time to the kworker. The IDPF workqueues that were using the kworker on CPU0 suffered large completion delays as a result, causing performance degradation, timeouts and eventual system crash. * I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`. (CVE-2024-58057)

  - Linux カーネルでは、以下の脆弱性が解決されています: idpf: fix checksums set in idpf_rx_rsc() idpf_rx_rsc() uses skb_transport_offset(skb) while the transport header is not set yet. This triggers the following warning for CONFIG_DEBUG_NET=y builds.
    DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)) [ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth [ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697 [ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748) [69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261687] ? report_bug (lib/bug.c:?) [ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285) [ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309) [ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf [69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf [ 69.261712]
    __napi_poll (net/core/dev.c:7194) [ 69.261716] net_rx_action (net/core/dev.c:7265) [ 69.261718] ?
    __qdisc_run (net/sched/sch_generic.c:293) [ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288) [ 69.261726] handle_softirqs (kernel/softirq.c:561) (CVE-2025-21890)

  - Linux カーネルでは、以下の脆弱性が解決されています: idpf: check error for register_netdev() on init Current init logic ignores the error code from register_netdev(), which will cause WARN_ON() on attempt to unregister it, if there was one, and there is no info for the user that the creation of the netdev failed. WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641] unregister_netdev+0x1c/0x30 [3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf] [3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739] idpf_remove+0xbf/0x780 [idpf] [3707.563769] pci_device_remove+0xab/0x1e0 [ 3707.563786] device_release_driver_internal+0x371/0x530 [3707.563803] driver_detach+0xbf/0x180 [ 3707.563816] bus_remove_driver+0x11b/0x2a0 [ 3707.563829] pci_unregister_driver+0x2a/0x250 Introduce an error check and log the vport number and error code. On removal make sure to check VPORT_REG_NETDEV flag prior to calling unregister and free on the netdev. Add local variables for idx, vport_config and netdev for readability. (CVE-2025-22116)

  - Linux カーネルでは、以下の脆弱性が解決されています: idpf: fix null-ptr-deref in idpf_features_check idpf_features_check is used to validate the TX packet. skb header length is compared with the hardware supported value received from the device control plane. The value is stored in the adapter structure and to access it, vport pointer is used. During reset all the vports are released and the vport pointer that the netdev private structure points to is NULL. To avoid null-ptr-deref, store the max header length value in netdev private structure. This also helps to cache the value and avoid accessing adapter pointer in hot path. BUG: kernel NULL pointer dereference, address: 0000000000000068 ...
    RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...
    (CVE-2025-38053)

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

リモートの CentOS Linux 9 ホストに、libxml2-2.9.13-12.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - libxml2 のバージョン 2.13.8 および 2.14.x 以前、2.14.2 以前では、xmlSchemaIDCFillNodeTables 関数 (xmlschemas.c 内) にヒープベースのバッファアンダーリードが存在します。これを悪用するには、細工された XML ドキュメントを特定の ID 制約のある XML スキーマに照らして検証するか、細工された XML スキーマを使用する必要があります。(CVE-2025-32415)

  - 2.13.8 および 2.14.xより前、2.14.2 より前の libxml2 では、戻り値が正しくないため、Python API (Python バインディング) で領域外のメモリアクセスが発生する可能性があります。これは、xmlPythonFileRead と xmlPythonFileReadRaw でバイトと文字が異なることにより発生します。(CVE-2025-32414)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-601.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: sched/fair: Fix potential memory corruption in child_cfs_rq_on_list child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.
    This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list, making the conversion invalid and potentially leading to memory corruption. Depending on the relative positions of leaf_cfs_rq_list and the task group (tg) pointer within the struct, this can cause a memory fault or access garbage data. The issue arises in list_add_leaf_cfs_rq, where both cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list. This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main conditional in child_cfs_rq_on_list. This ensures that the container_of operation will convert a correct cfs_rq struct. This check is sufficient because only cfs_rqs on the same CPU are added to the list, so verifying the 'prev' pointer against the current rq's list head is enough. Fixes a potential memory corruption issue that due to current struct layout might not be manifesting as a crash but could lead to unpredictable behavior when the layout changes. (CVE-2025-21919)

  - Linux カーネルでは、以下の脆弱性が解決されています: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ...
    Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem. (CVE-2022-49788)

  - Linux カーネルでは、以下の脆弱性が解決されています: RDMA/rxe: Fix the warning
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] The Call Trace is as below: <TASK> ? show_regs.cold+0x1a/0x1f ?
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __warn+0x84/0xd0 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? report_bug+0x105/0x180 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ?
    __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x118/0x190 [ib_core] rdma_destroy_qp.cold+0x43/0x5e [rdma_cm] rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core] rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server] process_one_work+0x21d/0x3f0 worker_thread+0x4a/0x3c0 ? process_one_work+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly. Compared with other rdma drivers, a bigger timeout is used.
    (CVE-2025-21829)

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

リモートの CentOS Linux 9 ホストに、libxml2-2.9.13-10.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - libxml2 に脆弱性が見つかりました。入力 XML ファイルから特定の sch:name 要素を処理すると、メモリ破損の問題が発生する可能性があります。この欠陥により、攻撃者が悪意のある XML 入力ファイルを作成して libxml をクラッシュさせ、機密データがメモリで破損することで、サービス拒否やその他の未定義の動作を引き起こす可能性があります。(CVE-2025-49796)

  - libxml2 に use-after-free の脆弱性が見つかりました。この問題は、XML スキマトロンに <sch:name path=.../> スキーマ要素が含まれる場合、特定の条件下で XPath 要素を解析する際に発生します。この欠陥により、悪意のある攻撃者は、libxml の入力として使用される悪意ある XML ドキュメントを作成でき、その結果、libxml を使用してプログラムをクラッシュさせたり、その他の未定義の動作を起こしたりする可能性があります。(CVE-2025-49794)

  libxml2 の xmlBuildQName 関数で欠陥が見つかりました。バッファサイズ計算の整数オーバーフローにより、スタックベースのバッファオーバーフローが発生する可能性があります。この問題により、細工された入力を処理する際にメモリ破損やサービス拒否が発生する可能性があります。(CVE-2025-6021)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-598.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: udf: Fix a slab-out-of-bounds write bug in udf_find_entry() Syzbot reported a slab-out-of-bounds Write bug: loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP:
    0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX:
    0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11:
    0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline]
    __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900) The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw:
    00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c: ---truncated--- (CVE-2022-49846)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf: Fix deadlock when freeing cgroup storage The following commit bc235cdb423a (bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]) first introduced deadlock prevention for fentry/fexit programs attaching on bpf_task_storage helpers. That commit also employed the logic in map free path in its v6 version. Later bpf_cgrp_storage was first introduced in c4bcfb38a95e (bpf: Implement cgroup storage available to non-cgroup-attached bpf progs) which faces the same issue as bpf_task_storage, instead of its busy counter, NULL was passed to bpf_local_storage_map_free() which opened a window to cause deadlock: <TASK> (acquiring local_storage->lock) _raw_spin_lock_irqsave+0x3d/0x50 bpf_local_storage_update+0xd1/0x460 bpf_cgrp_storage_get+0x109/0x130 bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170 ?
    __bpf_prog_enter_recur+0x16/0x80 bpf_trampoline_6442485186+0x43/0xa4 cgroup_storage_ptr+0x9/0x20 (holding local_storage->lock) bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160 bpf_selem_unlink_storage+0x6f/0x110 bpf_local_storage_map_free+0xa2/0x110 bpf_map_free_deferred+0x5b/0x90 process_one_work+0x17c/0x390 worker_thread+0x251/0x360 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Progs: - A: SEC(fentry/cgroup_storage_ptr) - cgid (BPF_MAP_TYPE_HASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpf_cgroup_from_id(). This trusted pointer can then be passed to bpf_cgrp_storage_get() to finally trigger the deadlock issue. - B:
    SEC(tp_btf/sys_enter) - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpf_cgrp_storage_get() for as many userspace tasks as possible. Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; } Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking. (CVE-2024-58088)

  - Linux カーネルでは、以下の脆弱性が解決されています: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU. If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e.
    acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec (mm/zswap: move to use crypto_acomp API for hardware acceleration) when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
    The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression. Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
    [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: remove comment] (CVE-2025-21693)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep.
    Change `irqs_disabled()` to `!preemptible()`. (CVE-2025-21728)

  - Linux カーネルでは、以下の脆弱性が解決されています: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. (CVE-2025-21759)

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

リモートの CentOS Linux 9 ホストには、bzip2-1.0.8-10.el9 ビルド変更ログで言及されている脆弱性の影響を受けるパッケージがインストールされています。

  - 1.0.6 までの bzip2 の decompress.c の BZ2_decompress に、セレクターが多い場合の領域外書き込みがあります。（CVE-2019-12900）

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

リモートの CentOS Linux 9 ホストに、ncurses-6.2-12.20210508.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 6.4 20230408 より前の ncurses により、setuid アプリケーションによって使用される場合、ローカルユーザーは、$HOME/.terminfo にある、または TERMINFO または TERM 環境変数を介して到達する、terminfo データベースファイルの無効な形式のデータを介して、セキュリティ関連のメモリ破損を発生させることができます。(CVE-2023-29491)

  - パッチ 20220416 より前の ncurses 6.3には、terminfo ライブラリの tinfo/read_entry.c の convert_strings に領域外読み取りおよびセグメンテーション違反があります。(CVE-2022-29458)

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

リモートの CentOS Linux 9 ホストに、libarchive-3.5.3-5.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - 3.7.7 までの libarchive の tar/util.c の list_item_verbose は、strftime の戻り値をチェックしません。これにより、verbose 値 2 で読み込まれる細工された TAR アーカイブを介して、サービス拒否や詳細不明なその他の影響が引き起こされる可能性があります。たとえば、100 バイトのバッファはカスタムロケールに十分でない可能性があります。
    (CVE-2025-25724)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-587.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations. (CVE-2025-21863)

  - Linux カーネルの SGI GRU ドライバーで、ユーザーが最初の gru_file_unlocked_ioctl 関数を呼び出す方法にメモリ解放後使用 (Use-After-Free) の欠陥が見つかりました。この場合、gru_check_chiplet_assignment 関数でフェイルパスが発生します。この欠陥によりローカルユーザーがクラッシュさせたり、システムで自分の権限を昇格させたりする可能性があります。(CVE-2022-3424)

  - Linux カーネルでは、以下の脆弱性が解決されています: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - Linux カーネルでは、以下の脆弱性が解決されています: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG:
    KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] (CVE-2024-50301)

  - Linux カーネルでは、以下の脆弱性が解決されています: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP:
    0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP:
    0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08:
    ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline]
    __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-57901)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-585.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
    ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves struct ext4_dir_entry_2 *de point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in
    __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ?
    __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400]
    __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ?
    __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ?
    __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ?
    __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ?
    __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ?
    __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561]
    __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2025-37785)

  - Linux カーネルでは、以下の脆弱性が解決されています: RDMA/rxe: Fix the qp flush warnings in req When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear. [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP:
    0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX:
    0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10:
    ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14:
    ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2:
    00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.624356] ? report_bug+0xfb/0x150 [ 920.624594] ? handle_bug+0x3c/0x60 [ 920.624796] ? exc_invalid_op+0x14/0x70 [920.624976] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe] [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe] [920.626037] rxe_requester+0x625/0xde0 [rdma_rxe] [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? sort_range+0x20/0x20 [ 920.627942] run_ksoftirqd+0x1f/0x30 [ 920.628158] smpboot_thread_fn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [920.628504] ? kthread_complete_and_exit+0x20/0x20 [ 920.628709] ret_from_fork+0x1f/0x30 [ 920.628892] </TASK> (CVE-2024-53229)

  - Linux カーネルでは、以下の脆弱性が解決されています: vsock: Keep the binding until socket destruction Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect(). Prevents socket unbinding during a transport reassignment, which fixes a use-after-free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before
    __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does:
    list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420
    __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0
    __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID:
    2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150
    __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free.
    WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP:
    0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2025-21756)

  - Linux カーネルでは、以下の脆弱性が解決されています: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference. (CVE-2025-21844)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4, data = 0xffff88803346f416 :\377, truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo] (CVE-2025-37749)

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

リモートの CentOS Linux 9 ホストには、kernel-5.14.0-583.el9 ビルド変更ログで言及されている脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit(). (CVE-2025-21745)

  - Linux カーネルでは、以下の脆弱性が解決されています: io_uring/uring_cmd: unconditionally copy SQEs at prep time This isn't generally necessary, but conditions have been observed where SQE data is accessed from the original SQE after prep has been done and outside of the initial issue. Opcode prep handlers must ensure that any SQE related data is stable beyond the prep phase, but uring_cmd is a bit special in how it handles the SQE which makes it susceptible to reading stale data. If the application has reused the SQE before the original completes, then that can lead to data corruption. Down the line we can relax this again once uring_cmd has been sanitized a bit, and avoid unnecessarily copying the SQE.
    (CVE-2025-21837)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-582.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 (ipv6: Always allocate pcpu memory in a fib6_nh) moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git. (CVE-2025-22005)

  - Linux カーネルでは、以下の脆弱性が解決されています: igb: Fix potential invalid memory access in igb_init_module() The pci_register_driver() can fail and when this happened, the dca_notifier needs to be unregistered, otherwise the dca_notifier can be called when igb fails to install, resulting to invalid memory access. (CVE-2024-52332)

  - Linux カーネルでは、以下の脆弱性が解決されています: nfsd: release svc_expkey/svc_export with rcu_work The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below.
    ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830:
    kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.
    However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0
    ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period. (CVE-2024-53216)

  - Linux カーネルでは、以下の脆弱性が解決されています: Bluetooth: iso: Fix circular lock in iso_conn_big_sync This fixes the circular locking dependency warning below, by reworking iso_sock_recvmsg, to ensure that the socket lock is always released before calling a function that locks hdev. [ 561.670344] ====================================================== [ 561.670346] WARNING: possible circular locking dependency detected [ 561.670349] 6.12.0-rc6+ #26 Not tainted [ 561.670351]
    ------------------------------------------------------ [ 561.670353] iso-tester/3289 is trying to acquire lock: [ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3}, at: iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670405] but task is already holding lock: [ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}, at: iso_sock_recvmsg+0xbf/0x500 [bluetooth] [ 561.670450] which lock already depends on the new lock. [ 561.670452] the existing dependency chain (in reverse order) is: [ 561.670453]
    -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}: [ 561.670458] lock_acquire+0x7c/0xc0 [ 561.670463] lock_sock_nested+0x3b/0xf0 [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth] [ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth] [ 561.670547] do_accept+0x3dd/0x610 [ 561.670550]
    __sys_accept4+0xd8/0x170 [ 561.670553] __x64_sys_accept+0x74/0xc0 [ 561.670556] x64_sys_call+0x17d6/0x25f0 [ 561.670559] do_syscall_64+0x87/0x150 [ 561.670563] entry_SYSCALL_64_after_hwframe+0x76/0x7e [561.670567] -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 561.670571] lock_acquire+0x7c/0xc0 [561.670574] lock_sock_nested+0x3b/0xf0 [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth] [ 561.670617]
    __sys_listen_socket+0xef/0x130 [ 561.670620] __x64_sys_listen+0xe1/0x190 [ 561.670623] x64_sys_call+0x2517/0x25f0 [ 561.670626] do_syscall_64+0x87/0x150 [ 561.670629] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670632] -> #0 (&hdev->lock){+.+.}-{3:3}: [ 561.670636]
    __lock_acquire+0x32ad/0x6ab0 [ 561.670639] lock_acquire.part.0+0x118/0x360 [ 561.670642] lock_acquire+0x7c/0xc0 [ 561.670644] __mutex_lock+0x18d/0x12f0 [ 561.670647] mutex_lock_nested+0x1b/0x30 [561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth] [ 561.670722] sock_recvmsg+0x1d5/0x240 [ 561.670725] sock_read_iter+0x27d/0x470 [ 561.670727] vfs_read+0x9a0/0xd30 [ 561.670731] ksys_read+0x1a8/0x250 [ 561.670733] __x64_sys_read+0x72/0xc0 [561.670736] x64_sys_call+0x1b12/0x25f0 [ 561.670738] do_syscall_64+0x87/0x150 [ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670744] other info that might help us debug this: [561.670745] Chain exists of: &hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH [561.670751] Possible unsafe locking scenario: [ 561.670753] CPU0 CPU1 [ 561.670754] ---- ---- [561.670756] lock(sk_lock-AF_BLUETOOTH); [ 561.670758] lock(sk_lock AF_BLUETOOTH-BTPROTO_ISO); [561.670761] lock(sk_lock-AF_BLUETOOTH); [ 561.670764] lock(&hdev->lock); [ 561.670767] *** DEADLOCK *** (CVE-2024-54191)

  - Linux カーネルでは、以下の脆弱性が解決されています: RDMA/mlx5: Fix implicit ODP use after free Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below.
    refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP:
    0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
    0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11:
    0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> (CVE-2025-21714)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-580.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: ipvlan: ensure network headers are in skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1] BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
    __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
    __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline] (CVE-2025-21891)

  - Linux カーネルでは、以下の脆弱性が解決されています: ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - Linux カーネルでは、以下の脆弱性が解決されています: pfifo_tail_enqueue: Drop new packet when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. (CVE-2025-21702)

  - Linux カーネルでは、以下の脆弱性が解決されています: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear. (CVE-2025-21765)

  - Linux カーネルでは、以下の脆弱性が解決されています: vxlan: check vxlan_vnigroup_init() return value vxlan_init() must check vxlan_vnigroup_init() success otherwise a crash happens later, spotted by syzbot. Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c:
    0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP:
    0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI:
    ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14:
    0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3:
    000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942 unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736 register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901 __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407 rtnl_newlink_create net/core/rtnetlink.c:3795 [inline] __rtnl_newlink net/core/rtnetlink.c:3906 [inline] (CVE-2025-21790)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-578.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. (CVE-2024-58007)

  - Linux カーネルでは、以下の脆弱性が解決されています: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context> padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.
    (CVE-2025-21726)

  - Linux カーネルでは、以下の脆弱性が解決されています: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP:
    ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS:
    0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ?
    __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ?
    __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered. (CVE-2025-21796)

  - Linux カーネルでは、以下の脆弱性が解決されています: tcp: drop secpath at the same time as we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point. We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore.
    However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions. (CVE-2025-21864)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-575.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルで、以下の脆弱性は解決されています: vrf: l3mdev_l3_out() での RCU 保護の使用。l3mdev_l3_out() は、RCU を保持せずに呼び出すことができます: rraw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()。rcu_read_lock() / rcu_read_unlock() のペアを追加して、潜在的な UAF を回避します。(CVE-2025-21791)

  - Linux カーネルで、以下の脆弱性は解決されています: tpm: eventlog/acpi.c での kvalloc() への変更。次の失敗が HPE ProLiant で報告されました D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ ここでカット]------------- [10.853559][ T1] 警告: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [10.862827][ T1] 次へのモジュールのリンク: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 汚染なし 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (未リリース) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] ハードウェア名: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP:
    0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX:
    0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 上記のトランスクリプトは、RSI が __alloc_pages_noprof() の「order」パラメーターにマッピングされているため、ACPI がログイベント用に 16 MiB のバッファを指していたことを示しています。
    devm_kmalloc() から devm_add_action()、kvmalloc()、および devm_add_action() に移動することで、このバグに対処します。
    (CVE-2024-58005)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-573.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、次の脆弱性が解決されました: scsi: sg: sg_release() での slab-use-after-free 読み取りを修正。KASAN を使用した syzbot によって検出された sg_release() での use-after-free バグを修正: バグ: KASAN: lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 の slab-use-after-free
    __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 sg_release() では、open_rel_lock mutex を解放する前に関数 kref_put(&sfp->f_ref, sg_remove_sfp) が呼び出されます。kref_put() 呼び出しにより、sfp の参照カウントがゼロに減算され、sg_remove_sfp() によるクリーンアップがトリガーされる可能性があります。このクリーンアップには、sg_remove_sfp_usercontext() を介して延期された作業をスケジュールすることが含まれており、最終的に sfp が解放されます。kref_put() の後、sg_release() は open_rel_lock のロックを解除し続け、sfp または sdp を参照する場合があります。sfp がすでに解放されている場合、slab-use-after-free エラーが発生します。open_rel_lock mutex のロックを解除した後に、kref_put(&sfp->f_ref, sg_remove_sfp) 呼び出しを移動します。これにより、次のことが保証されます: - 参照カウントが減算された後、sfp または sdp への参照は発生しません。- sg_remove_sfp() や sg_remove_sfp_usercontext() などのクリーンアップ関数は、sg_release() での mutex 処理に影響を与えることなく、安全に実行できます。修正は syzbot によってテストおよび検証されています。このパッチは、以下の syzkaller リンクで報告されているバグを解決します。また、リソースのクリーンアップと mutex の操作が適切に順序付けられるようにして、sg_release() の use-after-free エラーのリスクを排除します。(CVE-2024-56631)

  - Linux カーネルでは、次の脆弱性が解決されました: can: isotp_bind() で CAN ID チェックをサニタイズすると、Syzbot は準拠した CAN ID アドレス設定では到達できないステートマシンステータスにつながる環境を作成しました。提供されたアドレス情報は CAN ID 0x6000001 と 0xC28001 で構成されており、どちらも送信および受信において 11 ビット CAN ID 0x001 になります。アドレスチェックを実行する前に、SFF/EFF CAN ID の値をサニタイズします。(CVE-2022-49269)

  - Linux カーネルでは、次の脆弱性が解決されました: can: bcm: bcm_proc_show() の UAF を修正。バグ: KASAN: bcm_proc_show+0x969/0xa80 の slab-use-after-free。タスク cat/7862 によるアドレス ffff888155846230 でのサイズ 8 の読み取り。CPU: 1 PID: 7862 Comm: cat 汚染なし 6.5.0-rc1-00153-gc8746099c197 #230 ハードウェア名:
    QEMU Standard PC (i440FX + PIIX、1996)、BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0
    __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd タスク 7846 により解放: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40
    ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_release() で procfs エントリが削除される前に bcm_op が解放されるため、bcm_proc_show() が解放された bcm_op を読み取る可能性があります。(CVE-2023-52922)

  - Linux カーネルでは、次の脆弱性が解決されました: x86/xen: ハイパーコールページを介して PV iret ハイパーコールを実行しないでください。iret ハイパーコールを実行するために Xen ハイパーコールページにジャンプする代わりに、xen-asm.S で必要なシーケンスを直接コーディングします。これは、投機の緩和で問題が発生することが判明したため、ハイパーコールページをまったく使用しないようにするための準備として行われます。これは XSA-466 / CVE-2024-53241 の一部です。(CVE-2024-53241)

  - Linux カーネルでは、次の脆弱性が解決されました: scsi: megaraid_sas: 潜在的なデッドロックの修正 これにより、「循環ロック依存関係が検出されました」という警告が修正されます CPU0 CPU1 ----
    ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex);
    lock(&shost->scan_mutex); これを修正するには、reset_mutex を一時的にリリースします。(CVE-2024-57807)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-572.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、次の脆弱性が解決されました: arm64: cacheinfo: キャッシュ情報配列への領域外書き込みを回避しました。キャッシュ情報を検出/入力するループはすでに配列サイズの境界チェックを行っていますが、データ/命令キャッシュが分離されたキャッシュレベルには対応していませんでした。これを修正するには、任意のポピュレートされたレベルではなく、ポピュレートされたリーフごとにインデックスを増加させます。(CVE-2025-21785)

  - Linux カーネルでは、次の脆弱性が解決されました: powerpc/xive/spapr: ビットマップの割り当てサイズの修正。kasan が、xibm->bitmap の割り当ての終端を超えるアクセスを検出: バグ: KASAN: タスク swapper/0/1 により _find_first_zero_bit+0x40/0x140 サイズ 8 の読み取りがスラブの領域外のアドレス c00000001d1d0118 で実行された。CPU: 0 PID: 1 Comm: swapper/0 カーネルバージョン: 5.19.0-rc2-00001-g90df023b36dd #28呼び出しトレース:
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 問題のあるアドレスは、c00000001d1d0118 のオブジェクトに属しており、これはサイズ 8 の kmalloc-8 キャッシュに属しています。問題のあるアドレスは、8 バイト領域 [c00000001d1d0118, c00000001d1d0120) の内部 0 バイトに位置しています。問題のあるアドレスは物理ページに属しており、ページ: c00c000000074740、参照カウント: 1、マップカウント: 0、マッピング: 0000000000000000、インデックス: 0xc00000001d1d0558、pfn: 0x1d1d、フラグ: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) です。raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 ページは、kasan による不正アクセスが検出されたためダンプされました。問題のあるアドレス周辺のメモリ状態:
    c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc これは、割り当てが間違った単位 (ビット) を使用しているために発生します。正しくは、(BITS_TO_LONGS(count) * sizeof(long)) またはそれに相当する値を渡す必要があります。ビット数が少ない場合、割り当てられたオブジェクトは sizeof(long) よりも小さくなる可能性があり、その結果、無効なアクセスが発生します。bitmap_zalloc() を使用して IRQ ビットマップを割り当てて初期化し、一貫性を保つために bitmap_free() と組み合わせて使用します。(CVE-2022-49623)

  Linux カーネルでは、次の脆弱性が解決されました: soc: qcom: cmd-db: 共有メモリを WB ではなく WC としてマッピングします。Linux は cmd-db 領域に書き込みを行いません。このメモリ領域は、XPU により書き込み保護されています。
    XPU は、クリーンキャッシュの削除を書き込み保護領域への書き込みとして誤って検出し、セキュア割り込みを引き起こして Trust Zone の任意の場所で無限ループを引き起こす可能性があります。現在機能している唯一の理由は、Qualcomm Hypervisor がステージ 2 変換テーブルのキャッシュ不可能なメモリと同じ領域をマッピングしているためです。この問題は、特定のマッピングについて何も認識していない別のハイパーバイザー (Xen や KVM など) を使用する場合に発生します。cmd-db メモリのマッピングを MEMREMAP_WB から MEMREMAP_WT/WC に変更すると、ステージ 2 テーブル内の適切なマッピングに対する依存関係が削除されます。このパッチは、MEMREMAP_WC へのマッピングを更新することで問題を修正します。Xen 搭載の SA8155P でテストを行いました。(CVE-2024-46689)

  - Linux カーネルでは、次の脆弱性が解決されました: io_uring: オーバーフローのフラッシュ中に再スケジュールする必要があるかどうかを確認する。通常のアプリケーションの使用では、このリストは常に空になる。アプリケーションが少しオーバーフローした場合でも、いくつかのエントリが存在します。しかし、syzbot が大量のオーバーフローエントリを生成するテストケースを実行することを明示的に防ぐものはなく、それらのエントリをフラッシュするには、かなり時間がかかる可能性があります。フラッシュ中に再スケジュールする必要があるかどうかを確認し、必要に応じてロックを解除して再スケジュールします。
    ここでは状態を保持する必要はありません。オーバーフローは常にリストの先頭から切り詰められるため、ループの最後でロックを解除して再取得しても問題はありません。(CVE-2024-50060)

  - Linux カーネルでは、次の脆弱性が解決されました: io_uring/rw: O_DIRECT 開始書き込みの NOWAIT チェックの欠落を修正。io_uring が書き込みを開始すると、kiocb_start_write() を呼び出してスーパーブロックの rwsem を増加させ、その書き込みが進行中の間、フリーズが発生しないようにします。フリーズ側は、書き込み用にその rwsem を取得し、新しい書き込みが行われないようにして、既存の書き込みが完了するまで待機します。しかし、io_uring は kiocb_start_write() を無条件に使用するため、誰かが現在マウントポイントをフリーズしようとしている場合はブロックされます。これにより、freeze は以前の書き込みが完了するのを待機しますが、以前の書き込みを完了するはずのタスクが新しい書き込みの開始を待機してブロックされているため、以前の書き込みを完了できないデッドロックが発生します。これにより、次のようなスタックトレースが発生します。これは、新しい書き込みの開始を待機している書き込みとの依存関係がブロックされていることを示しています: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8
    __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110
    __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO:
    タスク fsfreeze:7364 が 15 秒以上ブロックされました。Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 で、フリーザーが rwsem を取得しようとしてスタックしています: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 呼び出しトレース: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18
    __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 これを修正するには、io_uring 側で IOCB_NOWAIT を尊重し、設定されていない場合にのみスーパーブロックの rwsem をブロックして取得しようとするようにします。通常の問題では、IOCB_NOWAIT が常に設定されるため、これにより -EAGAIN が返され、io_uring コアが書き込みのブロッキング試行を行います。これにより、完了処理も実行され、進行が確保されます。フリーズにはそもそも CAP_SYS_ADMIN が必要なため、これは通常のユーザーによってトリガーされることはありません。(CVE-2024-53052)

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

リモートの CentOS Linux 9 ホストに、libxml2-2.9.13-9.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - 2.12.10 より前および 2.13.6 より前の 2.13.x の libxml2 では、valid.c の xmlSnprintfElements にスタックベースのバッファオーバーフローがあります。これを悪用するには、信頼できないドキュメントまたは信頼できない DTD に対して DTD 検証が行われる必要があります。注意:
    これはCVE-2017-9047に類似しています。(CVE-2025-24928)

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

リモートの CentOS Linux 9 ホストに、microcode_ctl-20250211-1.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 一部の Intel (R) プロセッサーの UEFI ファームウェアでの入力の検証が不適切なため、特権ユーザーがローカルアクセスで権限の昇格を有効にできる可能性があります。(CVE-2023-43758)

  - 一部の Intel (R) プロセッサーの UEFI ファームウェアでの入力の検証が不適切なため、特権ユーザーがローカルアクセスで権限の昇格を有効にできる可能性があります。(CVE-2023-34440、CVE-2024-28127)

  一部の Intel(R) プロセッサーの UEFI ファームウェアの XmlCli 機能における入力の検証が不適切なため、特権ユーザーがローカルアクセスを介して権限の昇格を有効にできる可能性があります。(CVE-2024-24582)

  - 一部の Intel(R) プロセッサーの UEFI ファームウェアにおける入力の検証が不適切なため、特権ユーザーがローカルアクセスを介して情報漏洩を起こす可能性があります。(CVE-2024-28047)

  - 一部の Intel(R) プロセッサーの UEFI ファームウェア CseVariableStorageSmm における入力の検証が不適切なため、特権ユーザーがローカルアクセスを介して権限の昇格を有効にできる可能性があります。(CVE-2024-29214)

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

リモートの CentOS Linux 9 ホストに、openssh-8.7p1-45.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - VerifyHostKeyDNS オプションが有効な場合に、OpenSSH に脆弱性が見つかりました。中間マシン攻撃は、正当なサーバーになりすました悪意のあるマシンによって実行される可能性があります。この問題は、ホストキーを検証するときに OpenSSH が特定の条件下でエラーコードを不適切に処理することによって発生します。攻撃が成功したと見なされるためには、攻撃者はまずクライアントのメモリリソースを使い果たす必要があり、攻撃の複雑度が高くなります。(CVE-2025-26465)

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

リモートの CentOS Linux 9 ホストに、gcc-11.5.0-5.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - 1.0.3 以降 3.5.0 より前のバージョンの jQuery では、信頼できないソースからの <option> 要素を含む HTML を jQuery の DOM 操作メソッドの 1 つ (.html()、.append() など) に渡すと、HTML がサニタイズされた後でも、信頼できないコードが実行されることがあります。jQuery 3.5.0でこの問題に対するパッチが適用されています。
    (CVE-2020-11023)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-565.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、次の脆弱性が解決されました。Bluetooth: btmtk: btmtk_process_coredump の UAF を回避します。hci_devcd_append は skb のリリースにつながるため、一度呼び出されるとアクセスできなくなります。================================================================== BUG: KASAN: btmtk_process_coredump+0x2a7/0x2d0 の slab-use-after-free [btmtk] タスク kworker/0:3/82 による addr ffff888033cfabb0 でのサイズ 4 の読み取り CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c Hardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024 Workqueue: events btusb_rx_work [btusb] Call Trace: <TASK> dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0 btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 </TASK> タスク 82 で割り当て:
    stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60 kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb] btusb_rx_work+0x9e/0xe0 [btusb] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 タスク 1733 で解放: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0 hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 バグのあるアドレスは、サイズ 232 のキャッシュ skbuff_head_cache に属する ffff888033cfab40 のオブジェクトに属します。バグのあるアドレスは、解放済みの 232 バイト領域 [ffff888033cfab40、ffff888033cfac28) の 112 バイト内にあります。バグのあるアドレスは物理ページに属します。page:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa head:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags:
    0x4000000000000840(slab|head|zone=1) page_type: 0xffffffff() raw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000 ページがダンプされました。理由: kasan: 不正なアクセスが検出されました。バグのあるアドレス周辺のメモリ状態: ffff888033cfaa80:
    fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== hci_devcd_append を呼び出す前に hci_devcd_complete を呼び出す必要があるかどうかを確認します。そのためには、data->cd_info.cnt >= MTK_COREDUMP_NUM ではなく、data->cd_info.cnt > MTK_COREDUMP_NUM を確認する必要があります。これは、hci_devcd_append の呼び出しが成功した場合にのみ data->cd_info.cnt を増分するためです。(CVE-2024-56653)

  - Linux カーネルで、次の脆弱性が解決されました。Bluetooth: MGMT: set_powered_sync の slab-use-after-free 読み取りを修正。これにより、次のクラッシュが修正されます。
    ================================================================== BUG: KASAN: set_powered_sync+0x3a/0xc0 の slab-use-after-free net/bluetooth/mgmt.c:1353 タスク kworker/u9:0/54 による addr ffff888029b4dd18 でのサイズ 8 の読み取り CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 q kasan_report+0x143/0x180 mm/kasan/report.c:601 set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd10 kernel/workqueue.c:3389 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> タスク 5247 によって割り当て: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193 kmalloc_noprof include/linux/slab.h:681 [inline] kzalloc_noprof include/linux/slab.h:807 [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f タスク 5246 によって解放: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x149/0x360 mm/slub.c:4598 settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
    __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455 hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-53208)

  - Linux カーネルで、次の脆弱性が解決されました。Bluetooth: device_for_each_child() の use-after-free を修正 Syzbot が次の KASAN スプラットを報告しました。BUG: KASAN: device_for_each_child+0x18f/0x1a0 の slab-use-after-free タスク kbnepd bnep0/4980 によるアドレス ffff88801f605308 でのサイズ 8 の読み込み CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ?
    __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0 kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ?
    __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ?
    __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ?
    __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ?
    __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> タスク 4974 によって割り当て: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0
    __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f タスク 4979 によって解放: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250 do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210 arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f「hci_conn_del_sysfs()」において、下層の (kobject) 参照カウンターが 1 より大きい場合、「device_unregister()」が呼び出される可能性があります。これは、再親子化 (デバイスが実際に解放された際に発生) が遅延し、その遅延中に親コントローラーデバイス (hciX) が削除される可能性があることを意味します。後者は解放された親へのダングリングポインターを作成する可能性があるため、明示的に NULL に親を変更することでそのシナリオを回避します。(CVE-2024-53237)

  - Linux カーネルでは、次の脆弱性が解決されました。Bluetooth: iso: iso_listen_bis の最後に hdev を常にリリース hci_get_route は戻る前にデバイスを保持するため、関数がエラーで戻った場合でも、iso_listen_bis の終了時に hci_dev_put を使用して hdev を解放する必要があります。
    (CVE-2024-57879)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-559.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルにおいて、以下の脆弱性は解決されています。iommu/vt-d: ATS を無効にする前にキャッシュタグを削除する。現在の実装では、ATS を無効にした後にキャッシュタグを削除するため、メモリ漏洩とカーネルクラッシュを引き起こす可能性があります。具体的には、ドメインが解放された後でも、CACHE_TAG_DEVTLB タイプのキャッシュタグがリストに残る可能性があり、メモリ解放後使用 (Use After Free) 状態を引き起こします。この問題は、異なる PF からの複数の VF が vfio-pci を介して単一のユーザー空間プロセスにパススルーされたときに実際に発生します。このような場合、カーネルは次のようなカーネルメッセージでクラッシュする可能性があります。BUG: カーネル NULL ポインターデリファレンス、アドレス:
    0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ? asm_exc_page_fault+0x22/0x30 ? cache_tag_flush_range+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250 intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0 vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] iommu_disable_pci_caps() の前に cache_tag_unassign_domain() を移動して修正します。(CVE-2024-56669)

  - Linux カーネルで、次の脆弱性が解決されています: erofs: UP プラットフォームの pcluster メモリ解放後使用 (Use After Free) を修正します。CONFIG_SMP を無効にしたストレステスト中に、KASAN が以下のようにレポートします。
    ================================================================== BUG: KASAN: 
    __mutex_lock+0xe5/0xc30 におけるメモリ解放後使用 (Use After Free) タスクによる addr ffff8881094223f8 でのサイズ 8 の読み取り stress/7789 CPU:0 PID:7789 Comm:
    stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 ハードウェア名: Red Hat KVM、BIOS 0.5.1 01/01/2011 呼び出しトレース: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 ..
    z_erofs_readahead+0x31c/0x580 .. タスク 7787 によって解放 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 関連の可能性がある最後の作業作成:
    kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 根本原因は、erofs_workgroup_unfreeze() が orig_val にリセットされないため、pcluster が解放前に予期せずに再利用するという競合が発生することです。UP プラットフォームは現在非常にまれであるため、このようなパスは不要になります。代わりに、このような特定に設計されたパスを直接ドロップしましょう。(CVE-2022-48674)

  - Linux カーネルで、次の脆弱性が解決されています: erofs: LZMA グローバル圧縮重複排除のメモリリークを修正します。新しいグローバル圧縮重複排除機能を有効にして (「-Ededupe」) microLZMA EROFS 画像にストレスを与えると、短命の一時的ページが適切にリリースされないため、数時間後に予期しない OOM がゆっくりと発生する可能性があります。今すぐ修正しましょう (LZ4 および DEFLATE にはこの問題はありません)。(CVE-2023-52526)

  - Linux カーネルで、以下の脆弱性が解決されています。iommu/s390: ブロッキングドメインを実装します。これにより、PCI デバイスを不意にホットアンプラグしたときのクラッシュを修正します。このクラッシュは、ホットアンプラグ中であるために発生します
    既定ドメインをアタッチする __iommu_group_set_domain_nofail() は、デバイスがすでに削除されているためにプラットフォームがデバイスを認識しなくなり、ドメインポインターおよび UAF が NULL になる場合に失敗します。
    これは、__iommu_device_set_domain() の 2 番目のコメントで言及されているとおり、代わりにブロッキングドメインを添付できる場合、すでに削除されているデバイスを処理できるため、UAF が防止されます。この処理を使用するには、ブロッキングドメインを実装します。この変更により、クラッシュは修正されましたが、ブロックされたデバイスで DMA 所有権を変更しようとすると、依然として警告が表示されます。(CVE-2024-53232)

  - Linux カーネルでは、次の脆弱性が解決されています: i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check init_dyn_addr i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free dyn_addr init_dyn_addr と置き換えることでコピー/貼り付けエラー dyn_addr を修正します。(CVE-2024-56562)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-554.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルで、次の脆弱性が解決されています。ALSA: asihpi: OOB 配列アクセスの可能性を修正します。ASIHPI ドライバーが、ドライバーからの応答時に一部の値を静的配列に保存し、そのインデックスはファームウェアに依存します。盲目的に信頼すべきではありません。このパッチは、配列サイズに適合するように配列インデックスのサニティチェックを追加します。(CVE-2024-50007)

  - Linux カーネルにおいて、次の脆弱性が解決されています。ALSA: hda: cs35l41: cs35l41_hda_unbind() の NULL ポインターデリファレンスの可能性。cs35l41_hda_unbind() 関数は、そのインデックスに一致する hda_component エントリを消去し、最初の要素に保持されているコーデックポインターをデリファレンスします。これはデバイスインデックスが 0 の場合の問題です。代わりに、cs35l41_hda 構造体に格納されているコーデック ポインターを使用します。このポインターは引き続き有効です。(CVE-2024-40964)

  - Linux カーネルでは、次の脆弱性が解決されています。ASoC: SOF: Intel: hda: システムの中断エントリの null deref を修正します。システムがアクティブストリームで中断に入ると、SOF コアは hw_params_upon_resume() を呼び出します。HDA DMA をリンク DMA の管理に使用する Intel プラットフォームでは、これにより hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() の呼び出しチェーンが発生します。最初に hda_link_dma_cleanup() が実行され、hext_stream->link_substream がクリアされ、次に hda_ipc4_post_trigger() が NULL snd_pcm_substream ポインターで呼び出されるためです。(CVE-2024-41037)

  - Linux カーネルで、次の脆弱性が解決されています。ASoC: topology: 解放されたメモリへの参照を修正します。ほとんどのユーザーはトポロジーファイルを解析した後、使用しているメモリをリリースします。そのため、トポロジーファイルのコンテンツにポインターを直接参照することは不適切です。必要に応じて、devm_kmemdup() を使用してメモリを割り当てます。(CVE-2024-41069)

  - Linux カーネルで、以下の脆弱性が解決されています。ASoC: amd: acp: chip_pdev 構造体の NULL チェックを追加します。acp プラットフォームのデバイス作成がスキップされても、chip->chip_pdev の値は NULL のままです。
    snd_acp_resume() 関数の chip->chip_pdev 構造体の NULL チェックを追加し、NULL ポインターデリファレンスを回避します。(CVE-2024-42074)

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

リモートの CentOS Linux 9 ホストに、microcode_ctl-20241112-1.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Intel(R) SGX の使用時に一部の Intel(R) Xeon(R) プロセッサーのメモリコントローラー設定で不適切な条件チェックが行われる場合、特権ユーザーがローカルアクセスで権限昇格を有効にできる可能性があります。
    (CVE-2024-23918)

  - Intel(R) SGX の使用時に一部の Intel(R) Xeon(R) プロセッサーのメモリコントローラー設定で不適切なデフォルトアクセス許可がある場合、特権ユーザーがローカルアクセスで権限昇格を有効にできる可能性があります。(CVE-2024-21820)

  - 一部の第 4 世代および第 5 世代 Intel(R) Xeon(R) プロセッサーのハードウェアロジックにある有限状態マシン (FSM) が不適切なため、認証されたユーザーがローカルアクセスを介してサービス拒否を引き起こす可能性があります。
    (CVE-2024-21853)

  - 一部の Intel(R) プロセッサー用の RAPL インターフェースに不一致が見られるため、特権ユーザーがローカルアクセスを介して情報漏洩を引き起こす可能性があります。(CVE-2024-23984)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-547.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルで、次の脆弱性が解決されています。netfilter: nfnetlink: ACK で使用する前に extack を初期化する。BATCH_BEGIN と BATCH_END を ACK する際に、不足している extack 初期化を追加する。
    (CVE-2024-44945)

  - Linux カーネルで、次の脆弱性が解決されています。net: gso_max_size/gso_ipv4_max_size を小さく設定するとクラッシュする問題を修正。gso_max_size/gso_ipv4_max_size を小さく設定すると、sk_dst_gso_max_size() でアンダーフローが発生し、sk->sk_gso_max_size がデバイス制限よりもはるかに大きくなるため、BUG_ON クラッシュが発生する可能性があります。Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now);
    tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) gso_max_size と gso_ipv4_max_size の最小値のチェックを追加する。(CVE-2024-50258)

  - Linux カーネルで、次の脆弱性が解決されています。mm: mmap_region() エラーパスの動作不良を修正。mmap_region() 関数は、スパゲッティのような制御フローと、問題が発生する可能性のある多数の手段、不完全な状態、メモリリーク、その他の不都合が発生する可能性があるという点で、やや恐ろしいものです。複雑性の大部分は、VMA のマッピングプロセスの後半でエラーを処理しようとすることで発生します。これは、最近確認されたリソースリークや一貫性のない状態に関する問題の根本原因です。このシリーズの以前のパッチを利用して、コード内の多数のチェックをより早い段階に移動させ、ロジックの中心部分を静的な内部関数 __mmap_region() に移動させることで、処理を簡素化します。これにより、実際の作業を行う前に事前に多数のチェックを実行でき、書き込み可能なマップ解除チェックを必要に応じて無条件にアンワインドでき、CONFIG_DEBUG_VM_MAPLE_TREE 検証も無条件に実行できます。ここではいくつかの処理を行います。1. ファイルベースのメモリフックを呼び出す前にイテレータ用のメモリを事前に割り当てることで、早期終了が可能になり、複雑でエラーが発生しやすいクローズ/解放ロジックを実行する必要がなくなります。成功パスとエラーパスの両方でイテレータの状態を慎重に解放します。2. 囲む mmap_region() 関数は、早い段階で mapping_map_writable() ロジックを処理します。以前は、ロジックには、新しく割り当てられた file-backed VMA のマッピングポイントで mapping_map_writable() があり、成功およびエラーパスでの一致する mapping_unmap_writable() がありました。これが file-backed の共有書き込み可能なマッピングである場合は、無条件でこれを行うようになりました。ドライバーが VM_MAYWRITE を排除するためにフラグを変更した場合、実行したシールチェックは無効になりません。また、いかなる場合でも、ラッパーのカウンターを常に減少させます。ドライバーが逆のことを試みないようにするために、デバッグアサーションを実行します。
    3. また、arch_validate_flags() を mmap_region() 関数に移動します。これは arm64 および sparc64 にのみ関連し、このチェックは ADI が有効化された SPARC にのみ意味があります。ドライバーがこのチェックを無効にする場合は、このアーキテクチャに警告を明示的に追加しますが、最終的にはコードを修正してその必要をなくす必要があります。これらすべての対策を講じたので、エラーパスの VMA を明示的に閉じる必要がなくなりました。これは、任意のドライバー mmap フックへの呼び出しの前に、失敗する可能性のあるすべてのチェックを配置するためです。これにより、エラーのクラス全体が排除され、コードの推論が容易になり、堅牢性が向上します。
    (CVE-2024-53096)

  - Linux カーネルで、次の脆弱性が解決されています。media: uvcvideo: uvc_parse_format の UVC_VS_UNDEFINED タイプのフレーム解析をスキップする。これは、uvc_parse_streaming でフレームバッファのサイズを計算する際に、このタイプのフレームが考慮されていないため、領域外書き込みにつながる可能性があります。
    (CVE-2024-53104)

  - Linux カーネルで、次の脆弱性が解決されています。mm: alloc_pages_bulk_noprof の NULL ポインターデリファレンスを修正。タスクが cpusets 間で移行される際に、alloc_pages_bulk_noprof() の ac.preferred_zoneref->zone で NULL ポインターデリファレンスが発生していました。cpuset が有効な場合、prepare_alloc_pages() で、ac->nodemask が t->mems_allowed になる可能性があります。first_zones_zonelist() が呼び出されて preferred_zoneref が検索される際に、タスクが異なる cpusets 間で移行されると、ac->nodemask が同時に変更される可能性があります。2 つの NUMA ノードがあると仮定すると、ac->zonelist で Node1 をトラバースするときのノードマスクは 2、ac->zonelist で Node2 をトラバースするときのノードマスクは 1 となります。その結果、ac->preferred_zoneref は NULL ゾーンを指します。alloc_pages_bulk_noprof() で、for_each_zone_zonelist_nodemask() が許容可能なゾーンを見つけて zonelist_node_idx (ac.preferred_zoneref) を呼び出し、NULL ポインターデリファレンスが発生します。
    __alloc_pages_noprof() は、コミット ea57485af8f4 (mm、page_alloc:
    NULL preferred_zone のチェックを修正) およびコミット df76cee6bbeb (mm、page_alloc: alloc 高速パスから冗長チェックを削除) で NULL ポインターをチェックすることで、この問題を修正します。これを修正するには、preferred_zoneref->zone の NULL ポインターをチェックします。(CVE-2024-53113)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-542.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、次の脆弱性は解決されています。nfsd: nfs4_state_shutdown_net で同期モードを使用して nfsd_shrinker_work をキャンセルします。通常の場合、「echo 0 > /proc/fs/nfsd/threads」を実行すると、内の関数「nfs4_state_destroy_net」が「nfs4_state_shutdown_net」は、ハッシュされた「nfs4_client」に関連するすべてのリソースを解放します。「nfsd_client_shrinker」が同時に実行されている場合、「expire_client」関数はまずこのクライアントをハッシュ化解除してから、破棄します。これにより、次の警告が表示される可能性があります。
    さらに、多数のメモリ解放後使用 (Use After Free) エラーも発生する可能性があります。nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */ __destroy_client ==================================================================== BUG nfsd_file (Not tainted): __kmem_cache_shutdown() の nfsd_file に残っているオブジェクト
    -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================== BUG nfsd_file_mark (Tainted: G B W ):
    __kmem_cache_shutdown() の nfsd_file_mark に残っているオブジェクト
    -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e この問題を解決するには、nfs4_state_shutdown_net の同期モードを使用して「nfsd_shrinker_work」をキャンセルします。(CVE-2024-50121)

  - Linux カーネルで、次の脆弱性が解決されています: fscache: cookie_lru および use_cookie との競合による oops を修正します。クッキーが LRU から期限切れになり、LRU_DISCARD フラグが設定されていても、状態マシンがまだ実行されていない場合、別のスレッドは、fscache_use_cookie を呼び出して使用を開始できます。
    cookie_worker が最終的に実行されると、LRU_DISCARD フラグが設定されていることがわかり、cookie->state が LRU_DISCARDING に移行し、その後クッキーが撤回されます。クッキーが取り消されると、オブジェクトが削除されます。クッキーに関連付けられたオブジェクトが現在 NULL であるため、以下の oops が発生します。cookie_worker が実行される前に別のスレッドがクッキーを使用する場合、LRU_DISCARD ビットをクリアして oops を修正します。バグ: カーネル NULL ポインターデリファレンス、アドレス: 0000000000000008 ... PU: 31 PID: 44773 Comm: kworker/u130:1 汚染: GE 6.0.0-5.dneg.x86_64 #1 ハードウェア名: Google Compute Engine/Google Compute Engine、BIOS Google 2022 年 8 月 26 日。作業キュー: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP:
    0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... 呼び出しトレース:
    netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 (CVE-2022-48989)

  - Linux カーネルでは、次の脆弱性が解決されています: scsi: aacraid: プローブ失敗時の二重解放を修正。aac_probe_one() が、aac_driver_ident::init ポインターを通じてハードウェア固有の init 関数を呼び出し、そのすべてが最終的に aac_init_adapter() にまで呼び出します。aac_dev::queues にメモリを割り当てた後に aac_init_adapter() が失敗した場合、メモリは解放されますが、そのメンバーはクリアされません。ハードウェア固有の init 関数がエラーを返した後、aac_probe_one() がエラーパスをたどり、aac_dev::queues が指し示すメモリを解放するため、二重解放が発生します。(CVE-2024-46673)

  - Linux カーネルで、次の脆弱性が解決されています: cachefiles: cachefiles_open_file() の dentry 漏洩を修正します。検索クッキーとカリングが同時に行われると、dentry 漏洩が引き起こされる可能性があります: P1 | P2
    ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // エラーを返しますが、dentry を置きません。その後、バックエンドフォルダのアンマウント時に次の警告がトリガーされます: ================================================================== バグ: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [ext4 sda のアンマウント] 警告: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: アンマウント Not tainted 6.6.0-dirty #25 RIP:
    0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== cachefiles_open_file() が true を返すか false を返すかにかかわらず、cachefiles_look_up_object() の lookup_positive_unlocked() によって取得された参照カウントはリリースされる必要があります。したがって、cachefiles_look_up_object() でその参照カウントをリリースし、上記の問題を修正し、コードを簡素化してください。(CVE-2024-49870)

  - Linux カーネルで、次の脆弱性が解決されています: uprobes: [uprobes] vma を介してカーネル情報漏洩を修正します。xol_add_vma() は、__create_xol_area() によって割り当てられた初期化されていないページをユーザー空間にマッピングします。
    一部のアーキテクチャ (x86) では、このメモリは VM_READ なしでも読み取り可能です。VM_EXEC では VM_EXEC|VM_READ と同じ pgprot_t が発生します。これは実際には問題ではありませんが、デバッガはこのメモリを読み取ることができます。
    (CVE-2024-49975)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-539.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D:
    mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync. (CVE-2024-49951)

  - Linux カーネルでは、以下の脆弱性が解決されています: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (sctp: add size validation when walking chunks) is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG:
    KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 (CVE-2024-50299)

  - カーネルntbinteldebugfs_create_dir() の NULL 対 IS_ERR() のバグを修正しますCVE-2023-52917

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-536.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: HCI: hci_le_big_sync_ emergeed_evt() の潜在的な null-ptr-deref を修正。(CVE-2024-36011)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: L2CAP: l2cap_connect のメモリ解放後使用 (uaf) を修正 [Syzbot による報告] バグ: KASAN: l2cap_connect.constprop.0+0x10d8/0x1270 の slab-use-after-free net/bluetooth/l2cap_core.c:3949 タスク kworker/u9:0/54 によるアドレス ffff8880241e9800 でのサイズ 8 の読み取り CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 汚染されていない 6.11.0-rc6-syzkaller-00268-g788220eee30d #0ハードウェア名:
    Google Google Compute Engine/Google Compute Engine、BIOS Google 2024 年 8 月 6 日 Workqueue: hci2 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [インライン] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm /kasan/report.c:377 [インライン] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0/1270 net bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [インライン] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [インライン] l2cap_sig_channel net/bluetooth/l2c_core.c:4080 [インライン] l2cap_sig_channel net/bluetooth/l2cap_core.c:4772 0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [インライン] hci_rc/core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [インライン] worker_thread+0x6c8/0xed0 kernel/workqueue. c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_644.S:244 ... タスク 5245 による解放: 
    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
    __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [インライン] slab_free_hook mm/slub.c:2256 [インライン] slab_free mm/slub.c:4477 [インライン] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [インライン] kref_put include/linux/kref.h:65 [インライン] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [インライン] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [インライン] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [インライン] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 (CVE-2024-49950)

  - Linux カーネルで、次の脆弱性が解決されました: Bluetooth: hci_conn: hci_enhanced_setup_sync の UAF を修正。これは、hci_enhanced_setup_sync が cmd_sync で保留されている間に ACL 接続が破棄される可能性があるため、ACL 接続が有効のままであるかどうかをチェックし、次のトレースを生成します。バグ: KASAN: hci_enhanced_setup_sync+0x91b/0xa60 の slab-use-after-free により、タスク kworker/u5:2/37 によってアドレス ffff888002328ffd でサイズ 1 が読み取られる。CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099ハードウェア名: QEMU Standard PC (Q35+ ICH9、2009)、BIOS 1.16.3-2.fc40 2014 年 4 月 1 日 Workqueue: hci0 hci_cmd_sync_work 呼び出しトレース: <TASK>dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ?
    __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ?
    __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ?
    __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> タスク 34 による割り当て
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80
    __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e タスク 37 による解放: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30 (CVE-2024-50029)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: RFCOMM: rfcomm_sk_state_change でのデッドロックの可能性の修正。rfcomm_sk_state_change は sock_lock を使おうとするため、ロックされた状態で呼び出すことはできませんが、rfcomm_sock_ioctl は常にそれをロックしようとします。そのため、次のトレースが発生します。
    ============================================================ 警告: 循環ロックの依存関係が検出されました。6.8.0-syzkaller-08951-gfe46a7dd189e #0 は汚染されていません
    ------------------------------------------------------ syz-executor386/5093 がロックを取得しようとしています:
    ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}、場所: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}、場所:
    rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 ただし、タスクはすでにロックを保持しています:
    ffff88807badfd28 (&d->lock){+.+.}-{3:3}、場所: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491 (CVE-2024-50044)

  - Linux カーネルでは、次の脆弱性が解決されました: uprobe: 引数のフェッチによる境界外のメモリアクセスを回避。Uprobe は、非アトミックコンテキストの問題を回避するために、引数を percpu バッファにフェッチし、リングバッファにコピーする必要があります。ユーザー空間の文字列や配列は非常に大きくなる場合がありますが、percpu バッファのサイズはページサイズのみです。また、store_trace_args() は、これらのデータが単一ページを超えているかどうかをチェックしません。これにより、領域外メモリアクセスが発生しました。この問題は以下の手順で再現できます: 1. CONFIG_KASAN を有効にしてカーネルをビルドする 2. 次のプログラムを test.c として保存する ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // 文字列の長さが MAX_STRING_SIZE より大きい場合、fetch_store_strlen() は 0 を返します。これにより、__get_data_size() はより短いサイズを返し、// store_trace_args() は範囲外アクセスをトリガーしません。// したがって、文字列の長さを 4096 未満にします。\#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf(%s\n, str); } int main() { char tmp[STRLEN];
    generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. プログラム「gcc -o test test.c」をコンパイルする。4. 「print_string()」のオフセットを取得する。``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. オフセット 0x1199 で uprobe を設定する。``` off=0x1199 cd /sys/kernel/debug/tracing/ echo p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6.「test」を実行すると、kasan がエラーを報告します。 ============================================================================ バグ: KASAN: strncpy_from_user+0x1d6/0x1f0 でのメモリ解放後使用、タスク test/499 によるアドレス ffff88812311c004 へのサイズ 8 の書き込み、CPU: 0、UID: 0、PID: 499、Comm: test、汚染なし、6.12.0-rc3+ #18、ハードウェア名: Red Hat KVM、BIOS 1.16.0-4.al8、2014 年 4 月 1 日、呼び出しトレース: <TASK> dump_stack_lvl+0x55/0x70、print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ?
    __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ?
    __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ?
    __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ?
    __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP:
    002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08:
    00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> このコミットは、store_trace_args() のメモリ不足アクセスを回避するために、バッファの maxlen をページサイズより小さくすることを強制します。(CVE-2024-50067)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: ISO: debugfs が無効になっている場合の複数の init を修正。bt_debugfs が正常に作成されない場合 (CONFIG_DEBUG_FS または CONFIG_DEBUG_FS_ALLOW_ALL のいずれかが設定されていない場合に発生します)、iso_init() は早期に戻り、iso_inited を true に設定しません。
    これは、iso_init() への後続の呼び出しにより、proto_register()、bt_sock_register() などが重複して呼び出されることを意味します。CONFIG_LIST_HARDENED と CONFIG_BUG_ON_DATA_CORRUPTION を有効にした状態で、proto_register() を重複して呼び出すと、この BUG(): list_add double add: new=ffffffffc0b280d0、prev=ffffffffbab56250、next=ffffffffc0b280d0 がトリガーされます。------------[ここをカット]------------ lib/list_debug.c:35! のカーネルバグエラー: 無効な opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd 汚染されていません 6.10.11-1-ao-desktop #1RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ...
    __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev +0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... この変更により、早期リターンが削除されます。iso_debugfs が NULL かどうかのチェックは不要でした。iso_inited が false の場合は常に NULL になります。(CVE-2024-50077)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: モジュールのアンロード時に iso_exit() を呼び出す iso_init() が呼び出された場合、モジュールのアンロード時に iso_exit() を呼び出す必要があります。これがないと、iso_init() が proto_register() で登録した struct proto が無効になり、後で予期しない問題が発生する可能性があります。私の場合、CONFIG_LIST_HARDENED と CONFIG_BUG_ON_DATA_CORRUPTION が有効になっているため、モジュールを再度ロードすると、通常、この BUG() がトリガーされます: list_add の破損。next->prev は prev (ffffffffb5355fd0) である必要がありますが、0000000000000068 でした。(next=ffffffffc0a010d0)。-----------[ここでカット]------------- lib/list_debug.c:29! のカーネルバグエラー: 無効な opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe 汚染されていません 6.10.11-4+bt2-ao-desktop #1 RIP:
    0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth]
    __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230
    __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ... (CVE-2024-50078)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: SCO: sco_sock_timeout のメモリ解放後使用 (UAF) を修正 conn->sk は sco_conn_lock を待機している間にリンク解除/解放された可能性があるため、これは conn->sk が sco_sk_list の一部であるかどうかをチェックすることによって、conn->sk がまだ有効かどうかを確認します。(CVE-2024-50125)

  - Linux カーネルでは、次の脆弱性が解決されています: Bluetooth: bnep: proto_unregister のワイルドメモリアクセスを修正。次の問題があります: KASAN: 範囲 [0xdead...108-0xdead...10f] でワイルドメモリアクセスが発生している可能性 CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP:
    0010:proto_unregister+0xee/0x400 呼び出しトレース: <TASK>__do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f bnep_init() は bnep_sock_init() の戻り値を無視し、bnep_sock_init() はすべてのリソースをクリーンアップします。次に、bnep モジュールを削除すると、bnep_sock_cleanup() が呼び出され、sock のリソースがクリーンアップされます。bnep_exit() で bnep_sock_init() の戻り値を返すだけで上記の問題を解決できます。(CVE-2024-50148)

  - Linux カーネルでは、次の脆弱性が解決されました: Bluetooth: hci: hci_read_supported_codecs の null-ptr-deref を修正し、不明なオペコードに対して NULL 以外を返すように __hci_cmd_sync_sk() を修正しました。
    コマンドがステータスイベントを返した場合、__hci_cmd_sync_sk() が NULL を返します。ただし、hci_cmd_complete_evt() は不明なオペコードに対して status = skb->data[0] と想定するため、hci_cc テーブルにオペコードが存在しない場合は NULL を返します。これにより、HCI_OP_READ_LOCAL_CODECS の cmd_sync で null-ptr-deref が発生します。これは、HCI_OP_READ_LOCAL_CODECS に hci_cc がないためであり、これは常に status = skb->data[0] であると想定します。KASAN: 範囲 [0x0000000000000070-0x0000000000000077] 内の null-ptr-deref CPU: 1 PID: 2000 Comm: kworker/u9:5 汚染されていません 6.9.0-ga6bcb805883c-dirty #10 ハードウェア名: QEMU 標準 PC (i440FX + PIIX、1996)、BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 コード: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP:
    ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS:
    0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 コールトレース: <TASK> hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [インライン] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [インライン] hci_init4_sync net/bluetooth/hci_sync.c:4706 [インライン] hci_init_sync net/bluetooth/hci_sync.c:4742 [インライン] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [インライン] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [インライン] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [インライン] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 (CVE-2024-50255)

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

リモートの CentOS Linux 9 ホストに、tuned-2.24.0-2.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Tuned パッケージで、スクリプトインジェクションの脆弱性が特定されました。「instance_create()」D-Bus 関数は、ローカルでログインしているユーザーが認証なしで呼び出す可能性があります。この欠陥により、特権のないローカルユーザーが、絶対パスを持つ任意のスクリプトが渡される「script_pre」または「script_post」オプション付きの D-Bus 呼び出しを実行する可能性があります。これらのユーザーまたは攻撃者が制御する実行可能スクリプトまたはプログラムは、root 権限を使用して Tuned によって実行される可能性があります。これにより、攻撃者がローカルの権限昇格を行う可能性があります。(CVE-2024-52336)

  - 一部の API 引数のサニタイズが不適切なために、Tuned パッケージにログスプーフィングの欠陥が見つかりました。
    この欠陥により、攻撃者が制御された文字シーケンスを渡す可能性があります。ログに改行が挿入される可能性があります。攻撃者は「evil」の代わりに有効な tuneD ログ行を偽装し、管理者を騙す可能性があります。引用符 '' は通常、生のユーザー入力を引用する TuneD ログで使用されるため、偽装された入力の末尾には常に ' 文字が存在し、管理者はこれを簡単に見落とす可能性があります。このログに記録された文字列は、後でログ記録や、たとえば「tuned-adm get_instances」や、このような操作に Tuned の D-Bus インターフェイスを使用するその他のサードパーティプログラムなどのユーティリティの出力で使用されます。(CVE-2024-52337)

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

リモートの CentOS Linux 9 ホストには、kernel-5.14.0-533.el9 ビルド変更ログで言及されているように、複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
    __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
    __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at:
    nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
    __netif_receive_skb_one_core ---truncated--- (CVE-2024-47685)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. (CVE-2024-38564)

  - Linux カーネルでは、以下の脆弱性が解決されています: mm/huge_memory: don't unpoison huge_zero_folio When I did memory failure tests recently, below panic occurs: kernel BUG at include/linux/mm.h:1135! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP:
    0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08:
    ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 Call Trace: <TASK> do_shrink_slab+0x14f/0x6a0 shrink_slab+0xca/0x8c0 shrink_node+0x2d0/0x7d0 balance_pgdat+0x33a/0x720 kswapd+0x1f3/0x410 kthread+0xd5/0x100 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in:
    mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP:
    0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX:
    000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10:
    00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 The root cause is that HWPoison flag will be set for huge_zero_folio without increasing the folio refcnt.
    But then unpoison_memory() will decrease the folio refcnt unexpectedly as it appears like a successfully hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when releasing huge_zero_folio. Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. We're not prepared to unpoison huge_zero_folio yet. (CVE-2024-40914)

  - Linux カーネルでは、以下の脆弱性が解決されています: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the remove single subflow subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR. (CVE-2024-45009)

  - Linux カーネルでは、以下の脆弱性が解決されています: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the remove single address subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW.
    This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before. (CVE-2024-45010)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-529.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルで、次の脆弱性が解決されています。ipvs: ip_vs_add_service の pe を適切に逆参照します。pe を直接使用してスパース警告を解決: net/netfilter/ipvs/ip_vs_ctl.c:1471:27:
    警告: noderef 式の逆参照 (CVE-2024-42322)

  - Linux カーネルで、次の脆弱性は解決されています。fscache: UAF を回避するために fscache が存在する場合、fscache_cookie_lru_timer を削除します。fscache_cookie_lru_timer は、fscache モジュールが挿入されるときに初期化されますが、fscache モジュールが削除されるときに削除されません。fscache モジュールを削除する前に timer_reduce() が呼び出されると、fscache_cookie_lru_timer が現在の cpu のタイマーリストに追加されます。その後、fscache モジュールを削除した後、softIRQ で次のようにメモリ解放後使用 (Use After Free) がトリガーされます。=========================== ====================================== BUG: アドレスのページ障害を処理できません: fffffbfff803c9e9 PF: カーネルモードのスーパーバイザー読み取りアクセス PF: 
    error_code(0x0000) - ページが存在しない PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops:
    Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 呼び出しトレース: <IRQ> tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 </TASK> リンクされたモジュール: [最終アンロード: netfs] ================================================================== したがって、fscahe モジュールを削除する場合は、fscache_cookie_lru_timer を削除してください。(CVE-2024-46786)

  - Linux カーネルでは、次の脆弱性が解決されました。NFSD: 同時非同期 COPY 操作の数を制限します。クライアントが開始できる同時非同期 COPY 操作の数を制限するものはありません。さらに、AFAICT each async COPY は 4MB のチャンクを無制限にコピーできるため、長時間実行できます。したがって、IMO async COPY は DoS ベクトルになる可能性があります。同時バックグラウンド COPY 操作の数を制限する制限メカニズムを追加します。シンプルに始めて、公平になるようにします -- このパッチは、名前空間ごとの制限を実装します。この制限を超えている間に発生する非同期 COPY リクエストは、NFS4ERR_DELAY を取得します。
    リクエストを出したクライアントは、しばらくしてからリクエストを再送信するか、従来の読み取り/書き込みスタイルのコピーに戻すかを選択できます。メカニズムをより洗練させる必要がある場合は、将来のパッチでそうすることができます。(CVE-2024-49974)

  - Linux カーネルで、次の脆弱性が解決されました。netfilter: xtables: 必要な NFPROTO_UNSPEC を回避します syzbot は ebtables を介して xt_cluster の一致を呼び出すことができました。警告: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+ 0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 モジュールは NFPROTO_UNSPEC に登録しますが、ipv4/ipv6 パケット処理を前提としています。これは、ローカルで終了する TCP/UDP トラフィックを制限する場合にのみ有用であるため、ipv4 および ipv6 ファミリーに対してのみ登録してください。Pablo 氏は、これは一般的な問題であり、set/getsockopt インターフェースの直接ユーザーは、ip(6) テーブルでの使用のみを意図していたターゲット/マッチに呼び出す可能性があると指摘しています。同様の問題について、すべての UNSPEC のマッチとターゲットをチェックします: - skb_network_header() が有効であると想定する場合を除いて、マッチとターゲットは問題ありません -- これは inet 層から呼び出された場合にのみ当てはまります: ip(6) スタックは ip/ipv6 ヘッダーを線形データ領域にプルします。- XT_CONTINUE または他の xtables 判定を返すターゲットも制限する必要があります。これらのターゲットは、ebtables トラバーサーと非互換です。たとえば、EBT_CONTINUE は XT_CONTINUE とは完全に異なる値です。ほとんどのマッチ/ターゲットは、ip(6)tables で使用するために提供されているため、NFPROTO_IPV4/IPV6 に登録するように変更されます。MARK ターゲットは arptables でも使用されるため、NFPROTO_ARP にも登録してください。その際、connbytes が対応する conntrack ファミリーの有効化に失敗した場合にベイルアウトします。この変更により、iptables.git のセルフテストに合格します。(CVE-2024-50038)

  - Linux カーネルで、以下の脆弱性が解決されています。platform/x86/intel/pmc: pmc_core_iounmap が、有効なアドレスに対して iounmap を呼び出すように修正します。コミット 50c6dbdfd16e (x86/ioremap: Improve iounmap() アドレス範囲チェックを改善) は、iounmap のアドレス範囲が無効な場合に WARN を導入します。Thinkpad P1 Gen 7 (Meteor Lake-P) では、これにより次の警告が表示されました。警告: CPU: 7 PID: 713 at arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 リンクされたモジュール: rfkill(+) snd_timer(+) fjes(+) snd soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3 nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted 6.12.0-rc2iounmap+ #42 ハードウェア名: LENOVO 21KWCTO1WW/21KWCTO1WW、BIOS N48ET19W (1.06 ) 07/18/2024 RIP:
    0010:iounmap+0x58/0x1f0 コード: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX:
    ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12:
    00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS:
    00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
    0000000000000400 PKRU: 55555554 呼び出しトレース: <TASK> ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ? report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? iounmap+0x58/0x1f0 pmc_core_ssram_get_pmc+0x477/0x6c0 [intel_pmc_core] ?
    __pfx_pmc_core_ssram_get_pmc+0x10/0x10 [intel_pmc_core] ? __pfx_do_pci_enable_device+0x10/0x10 ? pci_wait_for_pending+0x60/0x110 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10 [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core] ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0 ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ?
    __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0 platform_probe+0x9f/0x150 real_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ?
    __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ?
    __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ? klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ?
    __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ?
    __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800 load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ?
    __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ?
    __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ? init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0
    ---truncated--- (CVE-2024-50107)

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

リモートの CentOS Linux 9 ホストに、expat-2.5.0-4.el9 ビルド変更ログに記載されている脆弱性の影響を受けるパッケージがインストールされています。

  - 2.6.4 より前に libexpat で問題が見つかりました。XML_StopParser が起動されていないパーサーを停止/中断する可能性があるため、XML_ResumeParser 関数内でクラッシュがあります。(CVE-2024-50602)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-527.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルで、次の脆弱性が解決されています。USB: core: 記述子の予約ビットをクリアすることでエンドポイントの重複を修正。Syzbot は、usbcore でバグを特定しました (下記の [Closes:] タグを参照)。これは、エンドポイント記述子の bEndpointAddress フィールド内の予約ビットは常に 0 になるという仮定により引き起こされます。バグの結果として、config.c の endpoint_is_duplicate() ルーチン (およびおそらくは他のルーチンも) は、2 つの記述子が同じ方向とエンドポイント番号を持っているのにもかかわらず、異なるエンドポイントに対するものであると考える可能性があります。これにより、syzbot (エンドポイント番号と方向が一致する2つの記述子。一方が割り込みで、他方がバルク) によって特定されたバグなどの混乱が発生する可能性があります。このバグを修正するために、記述子を解析するときに bEndpointAddress の予約ビットをクリアします。
    (USB-2.0 仕様と USB-3.1 仕様の両方が、これらのビットが Reserved で、ゼロにリセットされていると規定しています。) これには、usb_parse_endpoint() の早い段階で記述子のコピーを作成し、重複をチェックする際に現物の代わりにコピーを使用する必要があります。(CVE-2024-41035)

  - Linux カーネルでは、以下の脆弱性が解決されています。USB: シリアル: mos7840: 再開時のクラッシュを修正。コミット c49cfa917025 以降 (USB: シリアル: USB シリアルレイヤーに代替手段が提供されない場合は汎用メソッドを使用)、ドライバーが実装を提供していない場合は、USB シリアルコアが一般的な実装を再開します。複数の読み取り URB のサポートが 2011 年に追加されたため、これにより mos7840 の再開時にクラッシュが発生する可能性があります。具体的には、両方のポート読み取り URB が開いているポートの再開時に送信されるようになりましたが、2 番目の URB のコンテキストポインターは mos7840 ポート構造ではなくコアに設定されたままになります。mos7840 のための専用の中断および再開機能を実装することによってこれを修正します。Delock 87414 USB 2.0 to 4x シリアルアダプターでテスト。[ johan: クラッシュを分析し、コミットメッセージを書き直します。再開時にビジーフラグを設定します。バルクインチェックをドロップします。不要な usb_kill_urb() をドロップします] (CVE-2024-42244)

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

リモートの CentOS Linux 9 ホストに、kernel-5.14.0-516.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルにおいて、以下の脆弱性は解決されました： r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
    (CVE-2024-38586)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： dmaengine: idxd: Avoid unnecessary destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
    (CVE-2024-38629)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： ionic: fix kernel panic in XDP_TX action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So, it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address:
    ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops:
    0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11 Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP:
    0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX:
    0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ?
    __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ? asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ?
    __pfx_net_rx_action+0x10/0x10 (CVE-2024-40907)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 Call Trace: <TASK> ?
    __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50 devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ? process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 [] (CVE-2024-42268)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： tipc: Return non-zero value from tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address. (CVE-2024-42284)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation.
    Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 (CVE-2024-43856)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. And the panic of accessing error pointer is also fixed. (CVE-2024-43864)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
    (CVE-2024-43866)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 (mm: memcontrol: fix cgroup creation failure after many small jobs) decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
    Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. (CVE-2024-43892)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. (CVE-2024-44970)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： bnxt_en: Fix double DMA unmapping for XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING:
    CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm:
    ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10:
    ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en]
    __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 (CVE-2024-44984)

  - Linux カーネルにおいて、以下の脆弱性は解決されました： KVM: s390: fix validity interception issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via using kernel parameter kvm.use_gisa=0 or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm:
    CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW :
    0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118:
    c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>]
    __warn_printk+0xe8/0xf0 (CVE-2024-45005)

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

リモートの CentOS Linux 7 ホストに、RHSA-2020:0028 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 複数の Intel(R) プロセッサー用の仮想ゲストオペレーティングシステムによるページテーブル更新の不適切な無効化により、認証されたユーザーがローカルアクセスを介してホストシステムのサービス拒否を有効にする可能性があります。(CVE-2018-12207)

  - 投機的実行を利用する一部の CPU 上の TSX Asynchronous Abort 状態により、認証されたユーザーがローカルアクセスのサイドチャネルを介して情報を漏洩させることが可能です。(CVE-2019-11135)

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

リモートの CentOS Linux 7 ホストにインストールされているパッケージは、RHSA-2020:5561 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - 87.0.4280.88より前のGoogle ChromeのV8を初期化せずに使用すると、リモートの攻撃者が、細工されたHTMLページを介して、プロセスメモリから機密性の高い情報を取得する可能性がありました。(CVE-2020-16042)

  - ユーザーが提供した特定のblit値が適切に制約されず、一部のビデオドライバーでヒープバッファオーバーフローが発生しました。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。(CVE-2020-26971)

  - CSSサニタイザーへの特定の入力で混乱し、不適切なコンポーネントが削除されました。これは、サニタイザーバイパスとして使用された可能性があります。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。(CVE-2020-26973)

  - テーブルラッパーでflex-basisが使用される場合、StyleGenericFlexBasisオブジェクトが誤ったタイプに不適切にキャストされる可能性がありました。これにより、ヒープのメモリ解放後使用(Use After Free)、メモリ破損、悪用可能なクラッシュを引き起こす可能性があります。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。
    (CVE-2020-26974)

  - スリップストリームの研究に基づいた技術を使用して、悪意のあるWebページが、内部ネットワークのホストおよびユーザーのローカルマシンで実行されているサービスの両方を漏洩していた可能性があります。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。(CVE-2020-26978)

  - プロキシ権限で拡張が登録されて<all_urls>を受信する場合、proxy-onRequestコールバックはビューソースURLでトリガーされませんでした。WebコンテンツはこのようなURLに移動できませんが、View Sourceを開いているユーザーが不注意でIPアドレスを漏洩していた可能性があります。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。（CVE-2020-35111）

  - Mozilla開発者が、Firefox 83およびFirefox ESR 78.5に存在するメモリの安全性に関するバグを報告しました。これらのバグの一部にはメモリ破損の証拠が示されており、当社では、手間をかけることにより、これらの一部が悪用され、任意のコードが実行される可能性があると推測しています。この脆弱性の影響を受けるのは、Firefox < 84、Thunderbird < 78.6、Firefox ESR < 78.6です。(CVE-2020-35113)

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

リモートの CentOS Linux 7 ホストに、RHSA-2021:3381 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - v2.6.19-rc1以降の Linux がnet/netfilter/x_tables.cで発見されるヒープ領域外書き込み。
    これにより、攻撃者が特権を得るか、ユーザー名の空間を介してのDoS (ヒープメモリの破損経由) を引き起こすことができます (CVE-2021-22555)

  - 5.12.2 までの Linux カーネルの net/bluetooth/hci_request.c には競合状態があり、HCI コントローラーが除去されます。(CVE-2021-32399)

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

リモートの CentOS Linux 7 ホストにインストールされているパッケージは、RHSA-2022:1302 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - <code>NSSToken</code> オブジェクトがダイレクトポイントを介して参照され、異なるスレッドで安全でない方法でアクセスされ、メモリ解放後使用 (Use After Free) および悪用可能なクラッシュにつながる可能性があります。この脆弱性の影響を受けるのは、Thunderbird < 91.8、Firefox < 99、および Firefox ESR < 91.8 です。(CVE-2022-1097)

  - VR Process が破壊された後、それに対する参照が保持および使用され、メモリ解放後使用 (Use-After-Free) および悪用可能なクラッシュにつながる可能性があります。この脆弱性の影響を受けるのは、Thunderbird < 91.8 および Firefox ESR < 91.8 です。(CVE-2022-1196)

  - 失効理由としてキーの侵害を指定した、失効したキーをインポートすると、Thunderbird はまだ失効していないキーの既存のコピーを更新せず、既存のキーは失効しないものとして保持されていました。別の失効理由を使用した失効ステートメント、または失効理由を指定していない失効ステートメントは影響を受けませんでした。この脆弱性の影響を受けるのは、Thunderbird < 91.8です。(CVE-2022-1197)

  - regex は、Rust 言語用の正規表現の実装です。regex crate は、信頼できない正規表現によって引き起こされるサービス拒否攻撃、または信頼できる正規表現に一致する信頼できない入力を防ぐ作り込みの緩和機能を備えています。これらの (調整可能な) 緩和策は、攻撃を防ぐための適切なデフォルトをすでに提供しています。この保証は文書化されており、クレートの API の一部と見なされています。残念ながら、信頼できない正規表現が解析中に任意の時間がかかることを防ぐために設計された緩和にバグが発見されました。このような緩和をバイパスする正規表現を作成することが可能です。これにより、特別に細工された正規表現を、ユーザーが制御する信頼できない正規表現を受け入れるサービスに送信することで、サービス拒否攻撃を実行できます。

リモートの CentOS Linux 6 ホストには、 RHSA-2020:3548 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 3.18 より前の Linux カーネル内の KEYS サブシステムにより、ローカルユーザーが、keyring.cのkeyring_search_iterator 関数に関連して、特定の一致フィールドに対する NULL 値を含むベクトルを介して、権限を取得したり、サービス拒否 (NULL ポインター逆参照とシステムクラッシュ) を引き起こしたりする可能性がありまます。(CVE-2017-2647)

  - Marvell WiFi チップドライバーの Linux カーネル、バージョンカーネル 2.6.32 でヒープベースのバッファオーバーフローが見つかりました。STAがAPに接続した後にlbs_ibss_join_existing関数が呼び出されると、リモート攻撃者が、サービス拒否(システムクラッシュ) を引き起こしたり、任意のコードを実行したりする可能性がありました。
    (CVE-2019-14896)

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

リモートの CentOS Linux 6 ホストには、 RHSA-2020:4235 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 86.0.4240.75 より前の Google Chrome の支払いにおける use-after-free により、リモートの攻撃者が、細工された HTML ページを通じて、サンドボックス回避を実行する可能性がありました。 （CVE-2020-15967）

  - 86.0.4240.75より前の Google Chrome の Blink でのメモリ解放後使用 (Use After Free) により、リモート攻撃者が、細工された HTML ページを介してヒープ破損を悪用する可能性がありました。(CVE-2020-15968)

  - 86.0.4240.75より前のGoogle ChromeのWebRTCでのメモリ解放後使用 (Use After Free ) により、リモートの攻撃者が、細工されたHTMLページを介してヒープ破損を悪用する可能性がありました。 (CVE-2020-15969 )

  - 86.0.4240.75 より前の Google Chrome の NFC の use-after-free により、レンダラープロセスを侵害したリモートの攻撃者が、細工された HTML ページを通じてサンドボックス回避を実行する可能性があります。 （CVE-2020-15970）

  - 86.0.4240.75 より前の Google Chrome の印刷における use-after-free により、レンダラープロセスを侵害したリモートの攻撃者が、細工された HTML ページを通じてサンドボックス回避を実行する可能性がありました。
    (CVE-2020-15971)

  - 86.0.4240.75 より前の Google Chrome のオーディオにおける use-after-free により、リモートの攻撃者が、細工された HTML ページを介して、ヒープ破損を悪用する可能性があります。 （CVE-2020-15972）

  - より前の Google Chrome の拡張機能におけるポリシーの実施が不十分なため、ユーザーに悪意のある拡張機能をインストールさせる 86.0.4240.75 よう誘導した攻撃者が、細工された Chrome 拡張機能を介して同一オリジンポリシーをバイパスする可能性があります。 （CVE-2020-15973）

  - 86.0.4240.75 より前の Google Chrome の Blink における整数オーバーフローにより、リモートの攻撃者が、細工された HTML ページを通じて、サイト分離をバイパスする可能性がありました。 （CVE-2020-15974）

  - 86.0.4240.75 より前の Google Chrome の SwiftShader の整数オーバーフローにより、リモートの攻撃者が、細工された HTML ページを介して、ヒープ破損を悪用する可能性があります。 （CVE-2020-15975）

  - 86.0.4240.75 以前の Android 上の Google Chrome の WebXR の use-after-free により、リモートの攻撃者が、細工された HTML ページを介して、ヒープ破損を悪用する可能性があります。 （CVE-2020-15976）

  - 86.0.4240.75 以前の OS X 上の Google Chrome のダイアログのデータ検証が不十分なため、リモートの攻撃者が、細工された HTML ページを通じて、ディスクから潜在的な機密情報を取得することが可能でした。 （CVE-2020-15977）

  - より前 86.0.4240.75 のAndroid の Google Chrome のナビゲーションにおける不十分なデータ検証により、レンダラープロセスを侵害したリモートの攻撃者が、細工された HTML ページを通じて、ナビゲーション制限をバイパスすることが可能でした。 （CVE-2020-15978）

  - 86.0.4240.75以前の Google Chrome の V8 での不適切な実装により、リモートの攻撃者が、細工された HTML ページを介してヒープ破損を悪用する可能性がありました。(CVE-2020-15979)

  - 86.0.4240.75 より前の Android 上の Google Chrome では、Intents でポリシーを実施しているため、ローカルの攻撃者が、細工された Intents を通じて、ナビゲーション制限をバイパスすることが可能でした。 （CVE-2020-15980）

  - 86.0.4240.75 より前の Google Chrome のオーディオにおける領域外読み取りにより、リモートの攻撃者が、細工された HTML ページを介して、プロセスメモリから潜在的な機密情報を取得する可能性がありました。 （CVE-2020-15981）

  - 86.0.4240.75 より前の Google Chrome のキャッシュにおける不適切な実装により、リモートの攻撃者が、細工された HTML ページを介して、プロセスメモリから潜在的な機密情報を取得することが可能でした。 （CVE-2020-15982）

  - 86.0.4240.75 以前の ChromeOS 上の Google Chrome の webUI の不十分なデータ検証により、ローカルの攻撃者が、細工された HTML ページを通じて、コンテンツセキュリティポリシーをバイパスすることが可能でした。 （CVE-2020-15983）

  - 86.0.4240.75 より前の iOS 上の Google Chrome の Omnibox におけるポリシーの実施が不十分なため、リモートの攻撃者が、細工された URL を介して、Omnibox（URL バー）のコンテンツを偽装することが可能でした。 （CVE-2020-15984）

  - 86.0.4240.75 より前の Google Chrome の Blink の不適切な実装により、リモートの攻撃者が、細工された HTML ページを通じて、セキュリティ UI を偽装することが可能でした。 （CVE-2020-15985）

  - 86.0.4240.75 以前の Google Chrome のメディアにおける整数オーバーフローにより、リモートの攻撃者が、細工された HTML ページを介して、ヒープ破損を悪用する可能性があります。 （CVE-2020-15986）

  - 86.0.4240.75 より前の Google Chrome の WebRTC の use-after-free により、リモートの攻撃者が、細工された WebRTC ストリームを介して、ヒープ破損を悪用する可能性があります。 （CVE-2020-15987）

  - より前 86.0.4240.75 のWindows 上の Google Chrome でのダウンロードにおけるポリシーの実施が不十分なため、リモートの攻撃者が、ユーザーを誘導してファイルを開かせ、細工された HTML ページを通じて任意のコードを実行する可能性があります。
    (CVE-2020-15988)

  - 86.0.4240.75 より前の Google Chrome の PDFium の初期化されていないデータにより、リモートの攻撃者が、細工された PDF ファイルを介して、プロセスメモリから潜在的な機密情報を取得する可能性がありました。 （CVE-2020-15989）

  - 86.0.4240.75 より前の Google Chrome のオートフィルでの use-after-free により、レンダラープロセスを侵害したリモートの攻撃者は、細工された HTML ページを通じてサンドボックス回避を実行する可能性があります。
    (CVE-2020-15990)

  - 86.0.4240.75 より前の Google Chrome のパスワードマネージャーの use-after-free により、レンダラープロセスを侵害したリモートの攻撃者が、細工された HTML ページを通じてサンドボックス回避を実行する可能性がありました。
    (CVE-2020-15991)

  - より前の Google Chrome のネットワーキングにおけるポリシーの実施が不十分なため、レンダラープロセスを侵害したリモートの攻撃者が、細工された HTML ページを介して同一生成元ポリシーをバイパス 86.0.4240.75 する可能性がありました。
    (CVE-2020-15992)

  - 86.0.4240.75 より前の Google Chrome のネットワーキングにおける不適切な実装により、リモートの攻撃者が、細工された HTML ページを通じて、ドメインのなりすましを実行する可能性がありました。 （CVE-2020-6557）

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

リモートの CentOS Linux 7 ホストに、RHSA-2021:0346 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 5.0.0までのQEMUのネットワークパケット処理でアサーション失敗が発生する可能性があります。この問題はe1000eおよびvmxnet3ネットワークデバイスに影響します。悪意のあるゲストユーザー/プロセスがこの欠陥を利用して、ホストのQEMUプロセスを中止させる可能性があります。その結果、hw/net/net_tx_pkt.cのnet_tx_pkt_add_raw_fragmentでサービス拒否が発生します。（CVE-2020-16092）

  - libslirp 4.2.0 以前のリリースの ip_input.c 内の ip_reass() のメモリ解放後使用の脆弱性は、細工したパケットでサービス拒否を引き起こすことができます。(CVE-2020-1983)

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

リモートの CentOS Linux 7 ホストに、RHSA-2021:0354 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  -5.8より前のLinuxカーネルのfs/block_dev.cにおけるメモリ解放後使用 (Use After Free) の脆弱性により、ローカルユーザーが特定のエラーフィールドへの不適切なアクセスを利用して、権限を取得したり、サービス拒否を引き起こす可能性があります。
    (CVE-2020-15436)

  -IPv6経由のVXLANトンネルやGENEVEトンネルなど、IPsec内の一部のネットワーキングプロトコルのLinuxカーネルの実装で欠陥が見つかりました。2つのホスト間で暗号化されたトンネルが作成されると、カーネルは暗号化されたリンク経由でトンネルされたデータを正しくルーティングせず、暗号化されていないデータを送信します。そのため、2つのエンドポイント間にいる何者かが暗号化されていないトラフィックを読み取ることができます。この脆弱性による主な脅威は、データの機密性に対するものです。(CVE-2020-1749)

  - 5.9.13までのLinuxカーネルのttyサブシステムで、ロックの矛盾の問題が発見されました。
    drivers/tty/tty_jobctrl.cにより、TIOCSPGRP (別名 CID-54ffccbf053b) に対するメモリ解放後使用 (Use After Free) 攻撃が可能になります。
    (CVE-2020-29661)

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

ID	名前	深刻度
270810	CentOS 9kernel-5.14.0-626.el9	high
269726	CentOS 9cups-2.3.3op2-35.el9	high
266320	CentOS 9kernel-5.14.0-620.el9	medium
265707	CentOS 9kernel-5.14.0-617.el9	high
255191	CentOS 9python3.9-3.9.23-2.el9	high
251238	CentOS 9libarchive-3.5.3-6.el9	high
251237	CentOS 9kernel-5.14.0-605.el9	medium
249174	CentOS 9 : kernel-5.14.0-604.el9	medium
245570	CentOS 9 : libxml2-2.9.13-12.el9	high
242944	CentOS 9 : kernel-5.14.0-601.el9	high
242071	CentOS 9: libxml2-2.9.13-10.el9	critical
242070	CentOS 9: kernel-5.14.0-598.el9	high
241518	CentOS 9bzip2-1.0.8-10.el9	critical
241454	CentOS 9 : ncurses-6.2-12.20210508.el9	high
238237	CentOS 9 : libarchive-3.5.3-5.el9	medium
237260	CentOS 9: kernel-5.14.0-587.el9	high
236987	CentOS 9 : kernel-5.14.0-585.el9	high
235716	CentOS 9 : kernel-5.14.0-583.el9	medium
235376	CentOS 9: kernel-5.14.0-582.el9	medium
234895	CentOS 9 : kernel-5.14.0-580.el9	medium
234322	CentOS 9 : kernel-5.14.0-578.el9	high
233578	CentOS 9 : kernel-5.14.0-575.el9	high
233298	CentOS 9 : kernel-5.14.0-573.el9	high
232849	CentOS 9 : kernel-5.14.0-572.el9	high
217011	CentOS 9 : libxml2-2.9.13-9.el9	high
217010	CentOS 9 : microcode_ctl-20250211-1.el9	high
216704	CentOS 9 : openssh-8.7p1-45.el9	medium
215234	CentOS 9: gcc-11.5.0-5.el9	medium
215233	CentOS 9: kernel-5.14.0-565.el9	high
214888	CentOS 9 : kernel-5.14.0-559.el9	high
214579	CentOS 9 : kernel-5.14.0-554.el9	high
213504	CentOS 9 : microcode_ctl-20241112-1.el9	high
213467	CentOS 9: kernel-5.14.0-547.el9	high
213059	CentOS 9 : kernel-5.14.0-542.el9	high
212193	CentOS 9 : kernel-5.14.0-539.el9	medium
212094	CentOS 9 : kernel-5.14.0-536.el9	high
212093	CentOS 9 : tuned-2.24.0-2.el9	high
211829	CentOS 9kernel-5.14.0-533.el9	critical
211516	CentOS 9 : kernel-5.14.0-529.el9	high
210768	CentOS 9 : expat-2.5.0-4.el9	medium
210767	CentOS 9 : kernel-5.14.0-527.el9	medium
208962	CentOS 9 : kernel-5.14.0-516.el9	high
208653	CentOS 7 : kpatch-patch (RHSA-2020:0028)	medium
208652	CentOS 7 : firefox (RHSA-2020:5561)	high
208651	CentOS 7 : kpatch-patch (RHSA-2021:3381)	high
208650	CentOS 7 : thunderbird (RHSA-2022:1302)	high
208649	CentOS 6：カーネル（RHSA-2020:3548）	critical
208648	CentOS 6：chromium-browser（RHSA-2020:4235）	high
208647	CentOS 7：qemu-kvm-ma（RHSA-2021:0346）	medium
208646	CentOS 7：kernel-alt（RHSA-2021:0354）	high

検出

Nessus の CentOS Local Security Checks ファミリー

high

high

medium

high

high

high

medium

medium

high

high

critical

high

critical

high

medium

high

high

medium

medium

medium

high

high

high

high

high

high

medium

medium

high

high

high

high

high

high

medium

high

high

critical

high

medium

medium

high

medium

high

high

high

critical

high

medium

high