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

  - Linux カーネルでは、以下の脆弱性が解決されています: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. (CVE-2024-43839)

  - Linux カーネルでは、以下の脆弱性が解決されています: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. (CVE-2024-47659)

  - Linux カーネルでは、以下の脆弱性が解決されています: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN:
    use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 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 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
    __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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 RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP:
    002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX:
    0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11:
    0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem. (CVE-2024-47701)

  - Linux カーネルでは、以下の脆弱性が解決されています: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from ModelName, a string that was previously parsed out of some descriptor (Vital Product Data) in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, nffw.partno), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like netronome/nic_%s, and there shouldn't be any *folders* starting with netronome/nic_. The previous case was different because there, the %s is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing .. path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.
    (CVE-2024-47742)

  - Linux カーネルでは、以下の脆弱性が解決されています: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, test, 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open(/proc/self/maps, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024);
    if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] (CVE-2024-47745)

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

リモートの Ubuntu 20.04 LTS ホストには、USN-7518-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    Linux カーネルで、いくつかのセキュリティ上の問題が検出されました。攻撃者がこれらを使用して、システムを侵害する可能性があります。この更新では、以下のサブシステムの欠陥を修正しました。

    - ARM64 アーキテクチャ

    - PowerPC アーキテクチャ

    - ブロック層のサブシステム

    - ドライバーコア

    - ネットワークブロックデバイスドライバー

    - 文字デバイスドライバー

    - GPU ドライバー

    - HID サブシステム

    - InfiniBand ドライバー

    - メディアドライバー

    - ネットワークドライバー

    - PPS (Pulse Per Second) ドライバー

    - PTP クロックフレームワーク

    - RapidIO ドライバー

    - Real Time Clock ドライバー

    - SCSI サブシステム

    - SLIMbus ドライバー

    - QCOM SoC ドライバー

    - Trusted Execution Environment ドライバー

    - USB DSL ドライバー

    - USB Device Class ドライバー。

    - USB コアドライバー

    - USB ガジェットドライバー

    - USB ホストコントローラードライバー

    - Renesas USBHS コントローラードライバー

    - ファイルシステムインフラ

    - BTRFS ファイルシステム

    - Ceph 分散ファイルシステム

    - NILFS2 ファイルシステム

    - UBI ファイルシステム

    - KVM サブシステム

    - L3 マスターデバイスサポートモジュール

    - Netfilter

    - プロセス集計メカニズム

    - printk ロギングメカニズム

    - スケジューラインフラストラクチャ

    - トレースインフラ

    - メモリ管理

    - 802.1Q VLAN プロトコル

    - B.A.T.M.A.N. メッシングプロトコル

    - Bluetooth サブシステム

    - Networking コア

    - IPv4 ネットワーキング

    - IPv6 ネットワーキング

    - 論理リンク層

    - NFC サブシステム

    - Open vSwitch

    - Rose ネットワークレイヤー

    - ネットワークトラフィックコントロール

    - ワイヤレスネットワーキング

    - Tomoyoセキュリティモジュール;(CVE-2025-21760、 CVE-2025-21928、 CVE-2025-21877、 CVE-2024-58069、 CVE-2025-21909、 CVE-2025-21926、 CVE-2025-21731、 CVE-2025-21718、 CVE-2025-21763、 CVE-2025-21866、 CVE-2024-58009、 CVE-2025-21971、 CVE-2025-21787、 CVE-2025-21721、 CVE-2024-58072、 CVE-2025-21791、 CVE-2021-47191、 CVE-2025-21865、 CVE-2025-21762、 CVE-2024-58063、 CVE-2025-21910、 CVE-2025-21823、 CVE-2025-21905、 CVE-2025-21708、 CVE-2024-58090、 CVE-2025-21917、 CVE-2024-58051、 CVE-2025-21781、 CVE-2025-21898、 CVE-2025-21922、 CVE-2024-58002、 CVE-2024-58017CVE-2024-57986、 CVE-2024-58052、 CVE-2024-26982、 CVE-2025-21848、 CVE-2025-21835、 CVE-2025-21749、 CVE-2024-58014、 CVE-2024-58007、 CVE-2024-57980、 CVE-2025-21715、 CVE-2025-21858、 CVE-2025-21916、 CVE-2025-21811、 CVE-2025-21765、 CVE-2025-21736、 CVE-2025-21647、 CVE-2025-21934、 CVE-2025-21776、 CVE-2025-21761、 CVE-2025-21904、 CVE-2024-57979、 CVE-2024-58020、 CVE-2025-21935、 CVE-2025-21871、 CVE-2025-21704、 CVE-2024-57977、 CVE-2024-58083、 CVE-2025-21764、 CVE-2025-21814、 CVE-2025-21772、 CVE-2025-21719、 CVE-2024-58055、 CVE-2023-52664、 CVE-2024-56599、 CVE-2024-58001、 CVE-2025-21744、 CVE-2024-58085、 CVE-2025-21753、 CVE-2025-21846、 CVE-2024-58010、 CVE-2024-26996、 CVE-2023-52927、 CVE-2024-50055、 CVE-2025-21925、 CVE-2025-21782、 CVE-2024-57973、 CVE-2024-58071、 CVE-2025-21785、 CVE-2025-21859、 CVE-2025-21920、 CVE-2024-26689、 CVE-2023-52741、 CVE-2025-21806、 CVE-2024-58058、 CVE-2025-21722、 CVE-2025-21728、 CVE-2024-57981、 CVE-2025-21948、 CVE-2025-21914、 CVE-2025-21862、 CVE-2025-21735)

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

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

リモートの Ubuntu 20.04 LTS ホストには、USN-7516-2 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    Linux カーネルで、いくつかのセキュリティ上の問題が検出されました。攻撃者がこれらを使用して、システムを侵害する可能性があります。この更新では、以下のサブシステムの欠陥を修正しました。

    - ARM64 アーキテクチャ

    - PowerPC アーキテクチャ

    - ブロック層のサブシステム

    - ドライバーコア

    - ネットワークブロックデバイスドライバー

    - 文字デバイスドライバー

    - GPU ドライバー

    - HID サブシステム

    - InfiniBand ドライバー

    - メディアドライバー

    - ネットワークドライバー

    - PPS (Pulse Per Second) ドライバー

    - PTP クロックフレームワーク

    - RapidIO ドライバー

    - Real Time Clock ドライバー

    - SCSI サブシステム

    - SLIMbus ドライバー

    - QCOM SoC ドライバー

    - Trusted Execution Environment ドライバー

    - USB DSL ドライバー

    - USB Device Class ドライバー。

    - USB コアドライバー

    - USB ガジェットドライバー

    - USB ホストコントローラードライバー

    - Renesas USBHS コントローラードライバー

    - ファイルシステムインフラ

    - BTRFS ファイルシステム

    - NILFS2 ファイルシステム

    - UBI ファイルシステム

    - KVM サブシステム

    - L3 マスターデバイスサポートモジュール

    - プロセス集計メカニズム

    - printk ロギングメカニズム

    - スケジューラインフラストラクチャ

    - トレースインフラ

    - メモリ管理

    - 802.1Q VLAN プロトコル

    - B.A.T.M.A.N. メッシングプロトコル

    - Bluetooth サブシステム

    - Networking コア

    - IPv4 ネットワーキング

    - IPv6 ネットワーキング

    - 論理リンク層

    - NFC サブシステム

    - Open vSwitch

    - Rose ネットワークレイヤー

    - ネットワークトラフィックコントロール

    - ワイヤレスネットワーキング

    - Tomoyo セキュリティモジュール (CVE-2025-21866、CVE-2025-21846、CVE-2025-21971、CVE-2025-21909、CVE-2024-58083、CVE-2025-21811、CVE-2025-21776、CVE-2024-58051、CVE-2025-21917、CVE-2025-21935、CVE-2025-21785、CVE-2021-47191、CVE-2025-21765、CVE-2025-21704、CVE-2025-21647、CVE-2024-58069、CVE-2025-21877、CVE-2025-21948、CVE-2024-58007、CVE-2024-58001、CVE-2025-21871、CVE-2024-58055、CVE-2025-21848、CVE-2025-21925、CVE-2024-58058、CVE-2025-21814、CVE-2025-21905、CVE-2025-21898、CVE-2025-21926、CVE-2025-21760、CVE-2024-57973、CVE-2025-21806、CVE-2024-58071、CVE-2025-21761、CVE-2025-21762、CVE-2024-57986、CVE-2025-21708、CVE-2025-21744、CVE-2024-26996、CVE-2024-50055、CVE-2024-58020、CVE-2025-21858、CVE-2025-21715、CVE-2025-21904、CVE-2025-21920、CVE-2024-56599、CVE-2025-21781、CVE-2025-21764、CVE-2025-21865、CVE-2025-21772、CVE-2024-58072、CVE-2025-21928、CVE-2025-21859、CVE-2025-21721、CVE-2025-21719、CVE-2025-21914、CVE-2025-21753、CVE-2024-58009、CVE-2024-57981、CVE-2024-58063、CVE-2024-58052、CVE-2025-21722、CVE-2024-57977、CVE-2025-21736、CVE-2025-21922、CVE-2024-26982、CVE-2025-21718、CVE-2025-21916、CVE-2025-21749、CVE-2025-21787、CVE-2024-58085、CVE-2024-58010、CVE-2024-57979、CVE-2024-57980、CVE-2025-21782、CVE-2025-21791、CVE-2025-21728、CVE-2023-52741、CVE-2025-21934、CVE-2024-58002、CVE-2025-21735、CVE-2025-21910、CVE-2025-21823、CVE-2024-58090、CVE-2025-21862、CVE-2025-21731、CVE-2025-21835、CVE-2024-58017、CVE-2024-58014、CVE-2025-21763)

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

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

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2025:1743193221アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 (CVE-2021-47101)

  - Linux カーネルの fs/locks.c 関数の filelock_init で欠陥が見つかりました。この問題により、memcg が Portable Operating System Interface (POSIX) ファイルロックの数を制限しないために、ホストメモリが枯渇する可能性があります。(CVE-2022-0480)

  - Linux カーネルに、脆弱性が見つかりました。問題があると分類されています。この脆弱性の影響を受けるのは、コンポーネント BPF の drivers/net/usb/r8152.c ファイルの intr_callback 関数です。操作により、過剰なデータのロギングが発生します。攻撃がリモートで起動される可能性があります。この問題を修正するパッチを適用することが推奨されます。この脆弱性の関連識別子は VDB-211363 です。
    (CVE-2022-3594)

  - Linux カーネルでは、以下の脆弱性が解決されています: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam.
    (CVE-2022-48804)

  - Linux カーネルに欠陥が見つかりました。tls_is_tx_ready() がリストの空を不適切にチェックし、型の取り違えられたエントリを list_head にアクセスして、rec->tx_ready と重複する、取り違えられたフィールドの最後のバイトを漏洩する可能性があります。(CVE-2023-1075)

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

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2024:1731933167アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: of: fdt: fix off-by-one error in unflatten_dt_nodes() Commit 78c44d910d3e (drivers/of: Fix depth when unflattening devicetree) forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
    (CVE-2022-48672)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.
    (CVE-2024-36978)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: do not leave a dangling sk pointer, when socket creation fails It is possible to trigger a use-after-free by: * attaching an fentry probe to __sock_release() and the probe calling the bpf_get_socket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299 CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __sock_release (net/socket.c:652) __sock_create (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s:
    kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 299 on cpu 2 at 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) poison_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)
    __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
    __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by clearing the struct socket reference in sk_common_release() to cover all protocol families create functions, which may already attached the reference to the sk object with sock_init_data(). (CVE-2024-40954)

  - Linux カーネルでは、以下の脆弱性が解決されています: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen. (CVE-2024-41049)

  - Linux カーネルでは、以下の脆弱性が解決されています: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0:
    GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716]
    __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210]
    __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 (drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a (drm/i915/gt: Make fence revocation unequivocal) replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) (CVE-2024-41092)

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

CentOS Linux 8.4 ホストには、TuxCare CENTOS8.4:CLSA-2024:1731430561アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Unix ドメインソケットファイルハンドラーの Linux カーネルのガベージコレクションで、ユーザーが close() と fget() を同時に呼び出し、競合状態をトリガーする可能性のある方法で、read-after-free メモリ欠陥が見つかりました。この欠陥により、ローカル ユーザーがシステムをクラッシュさせたり、システム上で権限を昇格させたりする可能性があります。
    この欠陥は、5.16-rc4 より前の Linux カーネルバージョンに影響を与えます。(CVE-2021-4083)

  - テーブルの混乱サイズが小さいため、net/ipv4/tcp.c の TCP ソースポート生成アルゴリズムにメモリ漏洩の問題が見つかりました。この欠陥により、攻撃者が情報を漏洩する可能性があり、サービス拒否の問題を引き起こす可能性があります。(CVE-2022-1012)

  - vmwgfx ドライバーにはローカルの権限昇格の脆弱性が含まれているため、権限のないユーザーがダングリング [ファイル] ポインターを通じて、システム上の他のプロセスによって開かれたファイルにアクセスする可能性があります。
    (CVE-2022-22942)

  - net/ipv4/esp4.c および net/ipv6/esp6.c の IPsec ESP 変換コードにヒープバッファオーバーフローの欠陥が見つかりました。この欠陥により、通常のユーザー権限を持つローカルの攻撃者がカーネルヒープオブジェクトを上書きし、ローカル権限昇格の脅威を引き起こす可能性があります。(CVE-2022-27666)

  - Linux カーネルでは、以下の脆弱性が解決されています: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded.
    (CVE-2022-48771)

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

リモートの Oracle Linux 9 ホストに、ELSA-2025-6966アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

    - netstmmacdwmac-tegraデバイスツリーから iommu ストリーム ID を読み取りますIzabela Bakollari 氏[RHEL-75649] {CVE-2025-21663}
    - netstmmactc cbs を無効にする際のゼロ除算エラーを修正しますIzabela Bakollari 氏[RHEL-63931] {CVE-2024-49977}
    - scsiqla2xxxアンロードの use-after-free を修正Ewan D. Milne 氏[RHEL-75828{CVE-2024-56623}

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

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
352214	CentOS Linux 7 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-debug/kernel-debug-devel/kernel-devel/etcの複数の脆弱性(CENTOS7:CLSA-2024:1731348593)	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
236963	Ubuntu 20.04 LTS:Linuxカーネル(Azure FIPS)の脆弱性(USN-7518-1)	Nessus	Ubuntu Local Security Checks	2025/5/20	2026/6/11	high
320582	Ubuntu 20.04 LTS:Linuxカーネル(GCP FIPS)の脆弱性(USN-7516-2)	Nessus	Ubuntu Local Security Checks	2026/6/11	2026/6/11	high
361440	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-abi-stablelists/kernel-core/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2025:1743193221)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	medium
361222	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-abi-stablelists/kernel-core/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2024:1731933167)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	critical
366964	CentOS Linux 8.4 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-core/kernel-cross-headers/etcの複数の脆弱性(CENTOS8.4:CLSA-2024:1731430561)	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/19	critical
237030	Oracle Linux 9 : kernel (ELSA-2025-6966)	Nessus	Oracle Linux Local Security Checks	2025/5/22	2026/2/9	critical

検出

プラグインの検索

high

high

high

medium

critical

critical

critical