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

  - Linux カーネルでは、以下の脆弱性が解決されています: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit The following setup can trigger a WARNING in htb_activate due to the condition: !cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 \ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which causes packet dropping. However, cake_enqueue still returns NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an empty child qdisc. We should return NET_XMIT_CN when packets are dropped from the same tin and flow. I do not believe return value of NET_XMIT_CN is necessary for packet drops in the case of ack filtering, as that is meant to optimize performance, not to signal congestion.
    (CVE-2025-39766)

  - Linux カーネルでは、以下の脆弱性が解決されています: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with ima_appraise=fix evm=fix ima_policy=appraise_tcb and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = /usr/sbin/test_binary; const char* hex_string = 030204d33204490066306402304; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(Error opening file); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) {sscanf(hex_string + i, %2hhx, &ima_attr_value[j]); } if (fsetxattr(fd, security.ima, ima_attr_value, length/2, 0) == -1) { perror(Error setting extended attribute); close(fd); return 1; } const char* selinux_value= system_u:object_r:bin_t:s0; if (fsetxattr(fd, security.selinux, selinux_value, strlen(selinux_value), 0) == -1) { perror(Error setting extended attribute); close(fd); return 1; } close(fd); return 0; } (CVE-2025-68183)

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

リモートのCentOS Linux 9ホストには、rust-rpm-sequoia-1.10.2.1-1.el9ビルド変更ログで参照されている脆弱性の影響を受けるパッケージがインストールされています。

  - sequoia-openpgp をバージョン 2.3.0 に更新してください。これには、3 つのセキュリティ関連の修正(割り当てられた CVE-2026-42783、 CVE-2026-42784、CVE-not-assigned-yet)が含まれます。リリースノートの重要な修正を参照してください:
    <https://gitlab.com/sequoia-pgp/sequoia/-/raw/openpgp/v2.3.0/openpgp/NEWS>This 更新には、影響を受けるすべてのアプリケーションのリビルドが含まれており、これらの問題を修正する必要があります。(CVE-2026-42784)

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

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

  - polkit に欠陥が見つかりました。ローカルユーザーが、特別に細工された、極端に長い入力を標準入力(stdin)を介して「polkit-agent-helper-1」setuid バイナリに提供することで、これを悪用する可能性があります。この制限のない入力はメモリ不足(OOM)状態につながり、システムのサービス拒否(DoS)が発生する可能性があります。
    (CVE-2026-4897)

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

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

  - 問題の概要: KeyTransportRecipientInfo を含む細工された CMS EnvelopedData メッセージの処理中に、NULL ポインタ参照が発生する可能性があります。影響の概要: 攻撃者が制御する CMS データを処理するアプリケーションは、認証または暗号処理が行われる前にクラッシュし、サービス拒否が発生する可能性があります。
    RSA-OAEP 暗号化で KeyTransportRecipientInfo を使用する CMS EnvelopedData メッセージが処理される際、RSA-OAEP SourceFunc アルゴリズム識別子のオプションのパラメーターフィールドは、その存在を確認せずに検査されます。そのため、フィールドが存在しない場合に NULL ポインタデリファレンスが発生します。
    信頼できない入力に対して CMS_decrypt() を呼び出すアプリケーションおよびサービス (例: S/MIME 処理や CMS ベースのプロトコル) は、脆弱です。3.6、3.5、3.4、3.3、3.0 の FIPS モジュールは、この問題による影響を受けません。これは、影響を受けるコードが OpenSSL FIPS モジュール境界の外部にあるためです。(CVE-2026-28390)

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

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

  - Python-Markdown バージョン 3.8 脆弱性を含んでおり、無効な形式の HTML のようなシーケンスにより、Markdown 解析中に html.parser.HTMLParser が処理されない AssertionError を引き起こす可能性があります。Python-Markdown はこの例外をキャッチしないため、攻撃者が制御する Markdown を処理するアプリケーションがクラッシュする可能性があります。これにより、Webアプリケーション、ドキュメントシステム、CI/CDパイプライン、および信頼できないMarkdownを生成するサービスで、認証されていないリモートのサービス拒否が可能になります。この問題はベンダーによって認識され、バージョン 3.8.1 で修正されました。この問題により、信頼できないMarkdownを解析するアプリケーションでリモートのサービス拒否が引き起こされ、捕捉されない例外による情報漏えいにつながる可能性があります。(CVE-2025-69534)

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

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

  - rsync に欠陥が見つかりました。これにより、サーバーがクライアントのマシンから任意のファイルのコンテンツを列挙できる可能性があります。この問題は、ファイルがクライアントからサーバーにコピーされているときに発生します。このプロセス中、rsync サーバーは比較するローカルデータのチェックサムをクライアントに送信し、サーバーに送信する必要があるデータを判断します。任意のファイルに対して特別に構成されたチェックサム値を送信することで、攻撃者は、クライアントからの応答を基に、これらのファイルのデータをバイト単位で再構築できることがあります。(CVE-2024-12086)

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

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

  - GLib (Gnome Lib) で欠陥が見つかりました。この脆弱性により、リモートの攻撃者がヒープ破損を引き起こし、悪意のある細工された入力文字列を処理する際に GVariant パーサーでのバッファアンダーフローを介して、サービス拒否またはコード実行を引き起こす可能性があります。(CVE-2025-14087)

  - glib で欠陥が見つかりました。この脆弱性により、悪意のあるファイルまたはリモートファイルシステムの属性値を処理する際に、GLib の GIO (GLib 入出力) escape_byte_string() 関数における整数オーバーフローによって、ヒープバッファオーバーフローおよびサービス拒否 (DoS) を引き起こす可能性があります。(CVE-2025-14512)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: iommu: disable SVA when CONFIG_X86 is set Patch series Fix stale IOTLB entries for kernel address space, v7. This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel page table entries. When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption. This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused. This patch (of 8): In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries.
    The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA. Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables. Currently, SVA contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out. This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern. Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages. (CVE-2025-71089)

  - Linux カーネルでは、以下の脆弱性が解決されています: md: init bioset in mddev_init IO operations may be needed before md_run(), such as updating metadata after writing sysfs. Without bioset, this triggers a NULL pointer dereference as below: BUG: kernel NULL pointer dereference, address:
    0000000000000020 Call Trace: md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernfs_fop_write_iter+0x141/0x2a0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180
    __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reproducer ``` mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level ``` mddev_init() can only be called once per mddev, no need to test if bioset has been initialized anymore. (CVE-2025-68368)

  - Linux カーネルでは、以下の脆弱性が解決されています: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace:
    <TASK> __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition. (CVE-2025-68373)

  - Linux カーネルでは、以下の脆弱性が解決されています: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free. (CVE-2025-68374)

  - Linux カーネルでは、以下の脆弱性が解決されています: md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt() The variable mddev->private is first assigned to conf and then checked: conf = mddev->private; if (!conf) ... If conf is NULL, then mddev->private is also NULL. In this case, null-pointer dereferences can occur when calling raid5_quiesce(): raid5_quiesce(mddev, true);
    raid5_quiesce(mddev, false); since mddev->private is assigned to conf again in raid5_quiesce(), and conf is dereferenced in several places, for example: conf->quiesce = 0; wake_up(&conf->wait_for_quiescent); To fix this issue, the function should unlock mddev and return before invoking raid5_quiesce() when conf is NULL, following the existing pattern in raid5_change_consistency_policy(). (CVE-2025-71135)

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

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

  - SSSD の領域外読み取り(CVE-2026-6245)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero. (CVE-2026-31677)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs. (CVE-2026-23060)

  - Linux カーネルでは、以下の脆弱性が解決されています: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free.
    Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths. (CVE-2026-31408)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. (CVE-2026-31431)

  - Linux カーネルでは、以下の脆弱性が解決されています: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG:
    KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input) and b78d830f0049 (usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (usb: usbip: fix integer overflow in usbip_recv_iso(), v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.
    (CVE-2026-31607)

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

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

  - gnutlsに欠陥が見つかりました。この脆弱性は、gnutls が「nameConstraints」ラベルを大文字と小文字を区別して比較することにより発生します。具体的には、「excludedSubtrees」または「permittedSubtrees」内の「dNSName」(DNS) または「rfc822Name」(メール) 制約に関するものです。リモートの攻撃者は、Subject Alternative Name (SAN) の大文字と小文字の違いを含むリーフ証明書を細工することでこの問題を悪用でき、本来拒否されるべき証明書が受け入れられるポリシーバイパスにつながる可能性があります。これにより、不正アクセスまたは情報漏洩が発生する可能性があります。(CVE-2026-3833)

  - GnuTLS ライブラリの gnutls_pkcs11_token_init() 関数に不具合が見つかりました。この関数は PKCS#11 トークンの初期化を処理します。予想よりも長いトークンラベルが処理されると、関数は固定サイズのスタックバッファの範囲外に書き込みます。このプログラミングエラーにより、GnuTLS を使用しているアプリケーションがクラッシュしたり、特定の条件下ではコード実行につながる可能性があります。その結果、GnuTLS に依存するシステムまたはアプリケーションは、サービス拒否またはローカル権限昇格攻撃の影響を受ける可能性があります。(CVE-2025-9820)

  - GnuTLS の DTLS ハンドシェイク解析における欠陥により、ゼロ長かつ非ゼロオフセットの不正なフラグメントの処理時に、再アセンブリ中に整数アンダーフローが発生し、その結果として領域外読み取りが発生する可能性があります。この問題はリモートから悪用可能であり、情報漏洩またはサービス拒否を引き起こす可能性があります。(CVE-2026-33845)

  - GnuTLS の DTLS ハンドシェイクフラグメント再アセンブリロジックにヒープバッファオーバーフローの脆弱性が存在します。この問題は、merge_handshake_packet() において発生します。この関数では、受信したハンドシェイクフラグメントがハンドシェイクタイプのみに基づいて照合およびマージされ、同一の論理メッセージに属するすべてのフラグメント間で message_length フィールドが一貫していることの検証が行われていません。攻撃者は、不整合な message_length 値を持つ細工された DTLS フラグメントを送信することでこの問題を悪用できます。これにより、実装は小さな初期フラグメントに基づいてバッファを割り当てた後、不整合なより大きなフラグメントによってその範囲外に書き込む可能性があります。マージ操作では、割り当てられたバッファサイズに対する適切な境界チェックが行われないため、ヒープ上で領域外書き込みが発生します。この脆弱性は、認証なしで DTLS ハンドシェイク経路を通じてリモートから悪用可能であり、アプリケーションのクラッシュやメモリ破損につながる可能性があります。(CVE-2026-33846)

  - gnutlsに欠陥が見つかりました。リモートの攻撃者は、TLS ハンドシェイク中に特別に細工された Online Certificate Status Protocol (OCSP) 応答を返すことで、この脆弱性を悪用する可能性があります。gnutls がマルチレコードの OCSP 応答を処理する方法に論理エラーがあるため、OCSP 検証が有効になっているクライアントが失効したサーバー証明書を誤って受け入れる可能性があり、これにより信頼性が損なわれる可能性があります。(CVE-2026-3832)

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

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

  - 1.22.3以前のMIT Kerberos 5(別名krb5)では、NegoEx機構が登録されたシステム上でアプリケーションがgss_accept_sec_context()を呼び出すと整数アンダーフローと境界外の読み取りが発生します。認証されていないリモート攻撃者がこれをトリガーし、プロセスがparse_messageで終了する可能性もあります。(CVE-2026-40356)

  - 1.22.3以前のMIT Kerberos 5(別名krb5)では、/etc/gss/mechに登録されたNegoEx機構を持つシステム上でアプリケーションがgss_accept_sec_context()を呼び出す場合、NULLポインタデリファレンスがあります。認証されていないリモート攻撃者がこれをトリガーし、プロセスがparse_nego_messageで終了することがあります。
    (CVE-2026-40355)

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

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

  - 特権ドロップコールの失敗による特権のエスカレーション(CVE-2026-35535)

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

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

  - gssapi-keyex の初期化されていない変数による情報漏洩またはサービス拒否を修正しますCVE-2026-3497

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane:
    nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. (CVE-2026-23231)

  - Linux カーネルでは、以下の脆弱性が解決されています: autofs: fix memory leak of waitqueues in autofs_catatonic_mode Syzkaller reports a memory leak: BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm syz-executor399, pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue structs should be freed if their wait_ctr becomes zero. Otherwise they will be lost. In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places.
    Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage counter to zero which is not a correct behaviour. edit:imk This description is of course not correct. The umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the autofs mount itself. They happen independently, usually after everything mounted within the autofs file system has been expired away. If everything hasn't been expired away the automount daemon can still exit leaving mounts in place. But expires done in both cases will result in a notification that calls autofs_wait_release() with a result status. The problem case is the summary execution of of the automount daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount is umounted. end edit: imk So in catatonic mode we should free waitqueues which counter becomes zero.
    edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode() was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is removed from the list when either of these two functions are called. Consequently the wait entry will be freed by only one of these functions or by the woken process in autofs_wait() depending on the order of the calls. end edit: imk (CVE-2023-54134)

  - Linux カーネルでは、以下の脆弱性が解決されています: mm: hugetlb: independent PMD page table shared count The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared.
    The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID:
    0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name:
    QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110
    __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table.
    1. The page table itself will be discarded after reporting the nonzero mapcount. 2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped. Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count. (CVE-2024-57883)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF. (CVE-2025-38180)

  - Linux カーネルでは、以下の脆弱性が解決されています: HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in
    _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510
    __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ?
    __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. (CVE-2025-39818)

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

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

  - gssapi-keyex の初期化されていない変数による情報漏洩またはサービス拒否を修正しますCVE-2026-3497

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

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

  - 細工されたスワップファイルによるサービス拒否および情報漏洩CVE-2026-28421

  - netrw プラグインの OS コマンドインジェクションを通じた任意のコードの実行CVE-2026-28417

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

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

  - Linux 用の nfs-utils パッケージの rpc.mountd デーモンに脆弱性が最近発見されました。これにより、NFSv3 クライアントが、マウント時に /etc/exports ファイルで割り当てられた権限を昇格することが可能です。特に、これにより、クライアントは、設定されたファイル権限に関係なく、また通常はそのクライアントに適用されることが期待される「root_squash」属性または「all_squash」属性に関係なく、エクスポートされたディレクトリの任意のサブディレクトリまたはサブツリーにアクセスできます。CVE-2025-12801

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

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

  - png_image_write_*bit のヒープバッファオーバーリードRHEL-147356CVE-2026-22801]

  - png_image_finish_read のヒープバッファオーバーリードRHEL-149000CVE-2026-22695]

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

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

  - GnuTLS に欠陥が見つかりました。この脆弱性により、多数の名前制約とサブジェクト代替名SANが含まれる特別に細工された悪意ある証明書を介して、過剰な CPU中央処理ユニットとメモリ消費によるサービス拒否DoSが可能になります。CVE-2025-14831

  - GnuTLS ライブラリ、特に PKCS#11 トークン初期化を処理する gnutls_pkcs11_token_init() 関数に欠陥が見つかりました。想定より長いトークンラベルが処理されたとき、関数が固定サイズのスタックバッファの終端を超えて書き込みます。このプログラミングエラーにより、GnuTLSを使用するアプリケーションがクラッシュしたり、特定の条件下ではコード実行に悪用されたりする可能性があります。その結果、GnuTLS に依存するシステムまたはアプリケーションは、サービス拒否またはローカルの権限昇格の攻撃に脆弱である可能性があります。CVE-2025-9820

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

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

  - Vim でのヒープオーバーフローCVE-2026-25749

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

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

  - openCryptoki は PKCS#11 ライブラリで、Linux および AIX 用のツールを提供しています。バージョン 2.3.2 以降は、権限のあるコンテキストで実行しているときに、シンボリックリンクのフォローに脆弱です。トークングループユーザーは、グループ書き込み可能なトークンディレクトリにシンボリックリンクを配置することで、ファイル操作を任意のファイルシステムターゲットにリダイレクトできます。これにより、権限昇格やデータ漏洩が発生します。トークンおよびロックのディレクトリは 0770トークンユーザーはグループ書き込み可能であるため、token-group のメンバーはすべて、ファイルやシンボリックリンクをその内部に配置できます。rootとして実行された場合、管理目的で使用されるいくつかのopenCryptokiツールと同様に、トークンディレクトリのファイルアクセスを処理するベースコードにより、トークンディレクトリ内の既存ファイルの所有権や権限がリセットされる可能性があります。管理者が通常のメンテナンス時にトークンディレクトリ内のファイルで chown を実行する PKCS#11 アプリケーションまたは管理ツールを実行する際に、トークングループメンバーシップを持つ攻撃者がシステムを悪用する可能性があります。この問題はコミット 5e6e4b4 で修正されていますが、公開時にリリースされたバージョンには含まれていません。CVE-2026-23893

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: audit: fix out-of-bounds read in audit_compare_dname_path() When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in audit_compare_dname_path().
    The helper parent_len() returns 1 for /. In audit_compare_dname_path(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read. Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access. [PM: subject tweak, sign-off email fixes] (CVE-2025-39840)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure. (CVE-2025-38403)

  - Linux カーネルでは、以下の脆弱性が解決されています: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length) added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT both pointers NULL 2. H2C_DATA PDU for READ command cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands:
    both allocated (CVE-2026-22998)

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

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

  - urllib3 は Python 用の HTTP クライアントライブラリです。 urllib3 のストリーミング API は、応答本体全体を一度にメモリにロードするのではなく、チャンクのコンテンツを読み取ることで、大きな HTTP 応答を効率的に処理するように設計されています。 urllib3 は、HTTP「Content-Encoding」ヘッダー例「gzip」、「deflate」、「br」、「zstd」に基づいてデコードまたは展開を実行できます。ストリーミング API を使用している場合、ライブラリは必要なバイトのみを展開し、部分的なコンテンツの消費が可能になります。バージョン 1.22 からバージョン 2.6.3より前のバージョン以降、HTTP リダイレクト応答に対して、ライブラリが応答本文全体を読み、接続をドレインし、コンテンツを不必要に展開します。この展開は、読み込みメソッドが呼び出される前でも発生し、構成された読み取り制限は展開されたデータ量を制限しませんでした。その結果、展開爆弾に対する保護がありませんでした。悪意のあるサーバーがこれを悪用して、クライアントで過剰なリソース消費を引き起こす可能性があります。アプリケーションとライブラリは、リダイレクトを無効にしていない場合に「preload_content=False」を設定することで信頼できないソースからコンテンツをストリームする際に影響を受けます。ユーザーは、「preload_content=False」時にライブラリがリダイレクト応答のコンテンツをデコードしない、少なくとも urllib3 v2.6.3 にアップグレードする必要があります。すぐにアップグレードできない場合は、信頼できないソースへのリクエストに対して「redirect=False」を設定してリダイレクトを無効にしてください。CVE-2026-21441

  - urllib3 は、Python 用の使いやすい HTTP クライアントライブラリです。バージョン 1.24 および 2.6.0より前の から、展開チェーンのリンク数に制限がなくなり、悪意のあるサーバーがほぼ無制限の圧縮ステップを挿入し、展開されたデータのために高い CPU 使用率と大量のメモリ割り当てを引き起こす可能性があります。この脆弱性は 2.6.0 で修正されました。(CVE-2025-66418)

  - urllib3 は、Python 用の使いやすい HTTP クライアントライブラリです。バージョン 1.0 および 2.6.0より前の から、Streaming API は高度に圧縮されたデータを不適切に処理します。 urllib3 のストリーミング API は、応答本体全体を一度にメモリにロードするのではなく、チャンクのコンテンツを読み取ることで、大きな HTTP 応答を効率的に処理するように設計されています。圧縮された応答をストリーミングするとき、urllib3はHTTP Content-Encodingヘッダー例gzip、deflate、br、zstdに基づいてデコードまたは展開を実行できます。
    ライブラリは、ネットワークから圧縮されたデータを読み取り、リクエストされたチャンクサイズを満たすまで展開する必要があります。その結果リクエストされた量を超える展開データは、次の読み取り操作のために内部バッファに保持されます。展開ロジックにより、urllib3 は 1 回の操作で少量の高度に圧縮されたデータを完全にデコードできる可能性があります。これにより、リソースが過剰に消費される可能性があります展開されたデータに対して高い CPU 使用率と大量のメモリ割り当てが発生しますCVE-2025-66471

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

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

  - SSSD のデフォルト Kerberos 構成により、AD に参加した Linux で権限昇格が可能になりますCVE-2025-11561

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

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

  - _clear_id_cache() と依存関係がある appendChild() などの xml.dom.minidom メソッドを使用してネスト化された要素を構築する場合、アルゴリズムは二次的になります。過度にネスト化されたドキュメントを構築すると、可用性に影響が生じる可能性があります。CVE-2025-12084

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

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

  - 2.4.9より前の GnuPG では、g10/armor.c の armor_filter に、意図されたインデックス変数が 2 つあり、細工された入力に対する領域外書き込みを引き起こします。ExtendedLTS では、 2.2.51 およびそれ以降が修正されたバージョンです。CVE-2025-68973

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (dlm: fix use count with multiple joins). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations. (CVE-2025-23131)

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

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

  - NULL 文字を持つ URL 文字列を拒否しますCVE-2025-61985

  - 制御文字を持つユーザー名を拒否しますCVE-2025-61984

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0
    _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c
    __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac
    __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c
    ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ... (CVE-2025-39843)

  - Linux カーネルでは、以下の脆弱性が解決されています: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. Wouldn't be able to undo may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above. (CVE-2025-38499)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: ath12k: Fix buffer overflow in debugfs If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users. (CVE-2025-38317)

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: iwlwifi: mld: avoid panic on init failure In case of an error during init, in_hw_restart will be set, but it will never get cleared.
    Instead, we will retry to init again, and then we will act like we are in a restart when we are actually not. This causes (among others) to a NULL pointer dereference when canceling rx_omi::finished_work, that was not even initialized, because we thought that we are in hw_restart. Set in_hw_restart to true only if the fw is running, then we know that FW was loaded successfully and we are not going to the retry loop.
    (CVE-2025-38121)

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init(). (CVE-2025-38155)

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init() (CVE-2025-38156)

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled. (CVE-2025-38157)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (can: j1939: move j1939_priv_put() into sk_destruct callback) expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on struct j1939_priv held by j1939_sk_bind() call prevents struct net_device from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label] (CVE-2025-39925)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d (bus:
    mhi: ep: Update read pointer only after buffer is written)'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. [mani: added stable tag and reworded commit message] (CVE-2025-39790)

  - Linux カーネルでは、以下の脆弱性が解決されています: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability. (CVE-2025-38429)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX:
    ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11:
    ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ> (CVE-2025-39955)

  - Linux カーネルでは、以下の脆弱性が解決されています: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm fio, pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560
    __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7e V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions. (CVE-2025-38444)

  - Linux カーネルでは、以下の脆弱性が解決されています: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() {mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool.wait after assigning newpool. (CVE-2025-38445)

  - Linux カーネルでは、以下の脆弱性が解決されています: md/md-bitmap: fix GPF in bitmap_get_stats() The commit message of commit 6ec1f0239485 (md/md-bitmap: fix stats collection for external bitmaps) states: Remove the external bitmap check as the statistics should be available regardless of bitmap storage location. Return -EINVAL only for invalid bitmap with no storage (neither in superblock nor in external file). But, the code does not adhere to the above, as it does only check for a valid super-block for internal bitmaps. Hence, we observe: Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028 RIP: 0010:bitmap_get_stats+0x45/0xd0 Call Trace: seq_read_iter+0x2b9/0x46a seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0x8c/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e We fix this by checking the existence of a super-block for both the internal and external case. (CVE-2025-38451)

  - Linux カーネルでは、以下の脆弱性が解決されています: md: make rdev_addable usable for rcu mode Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops:
    Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.
    (CVE-2025-38621)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: xts - Handle EBUSY correctly As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
    (CVE-2023-53494)

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

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

ID	名前	深刻度
315236	CentOS 9:kernel-5.14.0-706.el9	high
315235	CentOS 9:rust-rpm-sequoia-1.10.2.1-1.el9	critical
315234	CentOS 9:polkit-0.117-16.el9	medium
315233	CentOS 9:openssl-3.5.5-3.el9	high
314434	CentOS 9:python-markdown-3.3.4-5.el9	medium
314433	CentOS 9:rsync-3.2.5-7.el9	medium
314432	CentOS 9 : glib2-2.68.4-20.el9	critical
314431	CentOS 9:kernel-5.14.0-704.el9	high
314430	CentOS 9:sssd-2.9.9-1.el9	medium
313111	CentOS 9:kernel-5.14.0-701.el9	high
312106	CentOS 9 : gnutls-3.8.10-4.el9	critical
312105	CentOS 9 : krb5-1.21.1-10.el9	medium
310556	CentOS 9 : sudo-1.9.17p2-4.el9	high
304416	CentOS 9openssh-9.9p1-7.el9	medium
304415	CentOS 9kernel-5.14.0-688.el9	high
303361	CentOS 9openssh-9.9p1-5.el9	medium
303360	CentOS 9vim-8.2.2637-26.el9	high
302517	CentOS 9nfs-utils-2.5.4-42.el9	medium
299792	CentOS 9libpng-1.6.37-14.el9	high
299202	CentOS 9gnutls-3.8.10-3.el9	medium
299201	CentOS 9vim-8.2.2637-25.el9	medium
299200	CentOS 9opencryptoki-3.26.0-2.el9	medium
298400	CentOS 9kernel-5.14.0-677.el9	high
297557	CentOS 9kernel-5.14.0-669.el9	high
297556	CentOS 9python-urllib3-1.26.5-7.el9	high
296911	CentOS 9sssd-2.9.8-1.el9	high
294801	CentOS 9python3.9-3.9.25-3.el9	medium
294800	CentOS 9gnupg2-2.3.3-5.el9	high
282592	CentOS 9kernel-5.14.0-658.el9	medium
278722	CentOS 9openssh-9.9p1-3.el9	low
278721	CentOS 9kernel-5.14.0-651.el9	medium
277738	CentOS 9kernel-5.14.0-648.el9	high
276945	CentOS 9 : kernel-5.14.0-645.el9	medium
272229	CentOS 9kernel-5.14.0-632.el9	high
272003	CentOS 9kernel-5.14.0-631.el9	high
271731	CentOS 9kernel-5.14.0-630.el9	medium
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 9libxml2-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

検出

Nessus の CentOS Local Security Checks ファミリー

high

critical

medium

high

medium

medium

critical

high

medium

high

critical

medium

high

medium

high

medium

high

medium

high

medium

medium

medium

high

high

high

high

medium

high

medium

low

medium

high

medium

high

high

medium

high

high

medium

high

high

high

medium

medium

high

high

critical

high

critical

high