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

  - Linux カーネルでは、以下の脆弱性が解決されています: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - Linux カーネルでは、以下の脆弱性が解決されています: i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - Linux カーネルでは、以下の脆弱性が解決されています: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - Linux カーネルでは、以下の脆弱性が解決されています: net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - Linux カーネルでは、以下の脆弱性が解決されています: be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - Linux カーネルでは、以下の脆弱性が解決されています: i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - Linux カーネルでは、以下の脆弱性が解決されています: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - Linux カーネルでは、以下の脆弱性が解決されています: net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - Linux カーネルでは、以下の脆弱性が解決されています: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

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

  - Kernel: メモリマネージャーでデバイスプライベートページに障害が発生したときの競合 (CVE-2022-3523)

  - kernel: l1oip タイマーハンドラーでのメモリ解放後使用 (Use After Free) (CVE-2022-3565)

  - kernel: intr_callback の r8152 のレート制限オーバーフローメッセージ (CVE-2022-3594)

  - kernel: vmwgfx: vmw_cmd_res_check でのメモリ解放後使用 (Use After Free) (CVE-2022-38457)

  - kernel: vmwgfx: vmw_execbuf_tie_context でのメモリ解放後使用 (Use After Free) (CVE-2022-40133)

  - hw: Intel: Gather Data Sampling (GDS) のサイドチャネル脆弱性 (CVE-2022-40982)

  - kernel: net/bluetooth/l2cap_core.c 内の l2cap_parse_conf_req における情報漏洩 (CVE-2022-42895)

  - kernel: x86/mm: cpu ごとのエントリ領域をランダム化します (CVE-2023-0597)

  - kernel: HID: hid_validate_values() の空の report_list をチェックします (CVE-2023-1073)

  - kernel: sctp: 所定のスコープに対して使用できるバインドアドレスがない場合に失敗 (CVE-2023-1074)

  - kernel: net/tls: tls_is_tx_ready() が list_entry をチェックしました (CVE-2023-1075)

  - kernel: tap: tap_open(): ソケット uid を正しく初期化 (CVE-2023-1076)

  - kernel: hid: asus_remove() のメモリ解放後使用 (Use After Free) (CVE-2023-1079)

  - kernel: IPv6 接続検索テーブルにおけるハッシュ衝突 (CVE-2023-1206)

  - kernel: file_files_note に mmap_lock がありません。これにより、coredump コードのメモリ解放後使用 (Use After Free) につながる可能性があります (CVE-2023-1249)

  - kernel: ovl: struct ovl_aio_req のメモリ解放後使用 (Use After Free) を修正します (CVE-2023-1252)

  - kernel: fs/nfsd/nfs4proc.c の nfsd4_ssc_setup_dul におけるメモリ解放後使用 (Use After Free) (CVE-2023-1652)

  - kernel: 関数削除 xgene_hwmon_remove のメモリ解放後使用 (Use After Free) のバグ (CVE-2023-1855)

  - kernel: 競合状態による btsdio_remove でのメモリ解放誤使用 (Use After Free) (CVE-2023-1989)

  - kernel: dm- ioctl.c の dm_get_inactive_table での、dos の原因となるデッドロックの可能性 (CVE-2023-2269)

  - kernel: r592_remove におけるメモリ解放後使用 (Use After Free) バグ (CVE-2023-3141)

  - kernel: fbcon: fbcon_set_font() の領域外シフト (CVE-2023-3161)

  - kernel: gfs2: gfs2_evict_inode() の NULL ポインターデリファレンス (CVE-2023-3212)

  - kernel: relay_file_read における領域外アクセス (CVE-2023-3268)

  - kernel: shtp_cl_get_dma_send_buf() における kalloc() 戻り値チェックの欠落による、NULL ポインターデリファレンス (CVE-2023-3358)

  - kernel: net/sched: tcf_change_indev() が失敗した場合の cls_u32 コンポーネントの参照カウンターの漏洩 (CVE-2023-3609)

  - kernel: xfrm: xfrm_update_ae_params() の NULL ポインターデリファレンス (CVE-2023-3772)

  - kernel: xfrm: XFRMA_MTIMER_THRESH nlattr の領域外読み取り (CVE-2023-3773)

  - kernel: KVM: SEV-ES / SEV-SNP VMGEXIT ダブルフェッチの脆弱性 (CVE-2023-4155)

  - kernel: tap: tap_open(): ソケット uid を正しく初期化 current_fsuid への i_uid の次の修正 (CVE-2023-4194)

  - kernel: net/sched: net/sched 分類子のメモリ解放後使用 (Use After Free) の脆弱性: cls_fw、cls_u32 および cls_route (CVE-2023-4206、CVE-2023-4207、CVE-2023-4208)

  - kernel: exFAT: exfat_get_uniname_from_ext_entry のスタックオーバーフロー (CVE-2023-4273)

  - kernel: mpls: sysctl 割り当てエラーでの二重解放 (CVE-2023-26545)

  - kernel: KVM: nVMX: CR0 および CR4 の一貫性チェックの欠落 (CVE-2023-30456)

  - kernel: net: qcom/emac: emac_remove() でのメモリ解放後使用 (Use After Free) につながる競合状態 (CVE-2023-33203)

  - kernel: vmwgfx: 情報漏洩の脆弱性につながる競合状態 (CVE-2023-33951)

  - kernel: vmwgfx: vmw_buffer_object オブジェクトの処理内での二重解放 (CVE-2023-33952)

  - kernel: r592: r592_remove() でのメモリ解放後使用 (Use After Free) につながる競合状態 (CVE-2023-35825)

  - kernel: eBPF: dynptr における不十分なスタックタイプチェック (CVE-2023-39191)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly. (CVE-2023-53077)

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.
    Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate.
    Note, active needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is active but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits) (CVE-2022-49882)

  - Linux カーネルでは、以下の脆弱性が解決されています: coresight: Clear the connection field properly coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data() b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match(). However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode. e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like : [ 91.990153] ------------[ cut here]------------ [ 91.990163] refcount_t: addition on 0; use-after-free. [ 91.990212] WARNING: CPU: 0 PID:
    461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Modules linked in:
    coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53 [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27:
    ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [ 91.990659] x20:
    0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [ 91.990708] x17: 0000000000000000 x16:
    0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12:
    657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28 [91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572 [ 91.990903] x5 :
    ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027 [ 91.990952] x2 : 0000000000000000 x1 :
    0000000000000000 x0 : ffff00080260ba00 [ 91.991000] Call trace: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c ---truncated--- (CVE-2022-50214)

  - Linux カーネルでは、以下の脆弱性が解決されています: wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897]
    __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [47.633002][ ---truncated--- (CVE-2022-50258)

  - Linux カーネルでは、以下の脆弱性が解決されています: netlink: prevent potential spectre v1 gadgets Most netlink attributes are parsed and validated from __nla_validate_parse() or validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ } @type is then used as an array index and can be used as a Spectre v1 gadget. array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. This should take care of vast majority of netlink uses, but an audit is needed to take care of others where validation is not yet centralized in core netlink functions. (CVE-2023-53000)

  - Linux カーネルでは、以下の脆弱性が解決されています: scsi: mpi3mr: Bad drive in topology results kernel crash When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the driver frees up the memory allocated for an internal HBA port data structure. However, in some places, the reference to the freed memory is not cleared. When the firmware sends the Device Info change event for the same device again, the freed memory is accessed and that leads to memory corruption and OS crash. (CVE-2023-53037)

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

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

    カーネルパッケージには、Linux オペレーティングシステムのコアである Linux カーネルが含まれています。

    セキュリティ修正プログラム:

    * カーネルtuntun_free_netdev の二重解放を回避しますCVE-2022-4744

    * カーネルnet/sched複数の脆弱性CVE-2023-3609、 CVE-2023-3611、 CVE-2023-4128、 CVE-2023-4206、 CVE-2023-4207、 CVE-2023-4208

    * kernel: qfq_change_class 関数での領域外書き込み (CVE-2023-31436)

    * カーネルhw_atl_utils_fw_rpc_wait の領域外書き込みCVE-2021-43975

    * カーネルintr_callback の r8152 におけるレート制限オーバーフローメッセージCVE-2022-3594

    * カーネルl2cap_conn_del の use-after-free 欠陥CVE-2022-3640

    * カーネルusb_8dev_start_xmit の二重解放CVE-2022-28388

    * カーネルvmwgfx複数の脆弱性CVE-2022-38457、 CVE-2022-40133、 CVE-2023-33951、 CVE-2023-33952]

    * hwIntel Collect Data SamplingGDSサイドチャネルの脆弱性CVE-2022-40982

    * カーネルl2cap_parse_conf_req の情報漏洩CVE-2022-42895

    * カーネルKVM複数の脆弱性CVE-2022-45869、 CVE-2023-4155、 CVE-2023-30456]

    * カーネルttusb_dec_exit_dvb のメモリリークCVE-2022-45887

    * カーネルdo_prlimit における投機的ポインターデリファレンスCVE-2023-0458

    * カーネルqdisc_graft の競合状態による use-after-freeCVE-2023-0590

    * kernel: x86/mm: cpu ごとのエントリ領域をランダム化します (CVE-2023-0597)

    * カーネルHIDhid_validate_values の空の report_list をチェックCVE-2023-1073

    * カーネルsctp特定のスコープに対してバインドアドレスを使用できない場合に失敗しますCVE-2023-1074

    * カーネルhidasus_remove での use-after-freeCVE-2023-1079

    * カーネルdrivers/media/rc/ene_ir.c の use-after-freeCVE-2023-1118

    * カーネルIPv6 接続検索テーブルでのハッシュ衝突CVE-2023-1206

    * kernel: ovl: struct ovl_aio_req のメモリ解放後使用 (Use After Free) を修正します (CVE-2023-1252)

    * カーネルtipc_conn_close のサービス拒否CVE-2023-1382

    * kernel: 競合状態による btsdio_remove でのメモリ解放誤使用 (Use After Free) (CVE-2023-1989)

    * kernel: Spectre v2 SMT 緩和策の問題 (CVE-2023-1998)

    * カーネルext4ext4_xattr_set_entry の use-after-freeCVE-2023-2513

    * カーネルfbconfbcon_set_font の shift-out-of-boundsCVE-2023-3161

    * カーネルrelay_file_read の領域外アクセスCVE-2023-3268

    * カーネルxfrmxfrm_update_ae_params の NULL ポインターデリファレンスCVE-2023-3772

    * カーネルsmsusbdo_submit_urb により引き起こされる use-after-freeCVE-2023-4132

    * カーネルページを移行するタスクと exit_mmap を呼び出す別のタスクの間の競合CVE-2023-4732

    * カーネル型の取り違えType Confusionによる atm_tc_enqueue のサービス拒否CVE-2023-23455

    * kernel: mpls: sysctl 割り当てエラーでの二重解放 (CVE-2023-26545)

    * カーネルaz6027 ドライバーでのサービス拒否の問題CVE-2023-28328

    * カーネルlib/seq_buf.c には seq_buf_putmem_hex バッファオーバーフローがありますCVE-2023-28772

    * カーネルdvb_frontend_get_event と wait_event_interruptible の操作のブロックCVE-2023-31084

    * カーネルnetqcom/emacmac_remove に use-after-free を引き起こす競合状態CVE-2023-33203

    * カーネルsaa7134saa7134_finidev で use-after-free を引き起こす競合状態CVE-2023-35823

    * カーネルdm1105dm1105_remove.c に use-after-free を引き起こす競合状態CVE-2023-35824

    * カーネルr592r592_remove で use-after-free を引き起こす競合状態CVE-2023-35825

    * kernel: net/tls: tls_is_tx_ready() が list_entry をチェックしました (CVE-2023-1075)

    * kernel: 関数削除 xgene_hwmon_remove のメモリ解放後使用 (Use After Free) のバグ (CVE-2023-1855)

    * kernel: r592_remove におけるメモリ解放後使用 (Use After Free) バグ (CVE-2023-3141)

    * カーネルgfs2gfs2_evict_inode の NULL ポインターデリファレンスCVE-2023-3212

    影響、CVSS スコア、謝辞、その他の関連情報を含むセキュリティ問題の詳細については、「参照」セクションに記載されている CVE のページを参照してください。

    追加の変更:

    このリリースの変更に関する詳細については、「参照」セクションからリンクされている Red Hat Enterprise Linux 8.9 リリースノートを参照してください。

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

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

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

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

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

    - CVE-2022-49110: netfilter: conntrack: gc 自動調整を再検討します (bsc#1237981)。
    - CVE-2022-49139: Bluetooth: hci_sync_conn_complete_evt の NULL ポインターデリファレンスを修正します (bsc#1238032)。
    - CVE-2022-49767: 9p/trans_fd: 常に O_NONBLOCK 読み取り/書き込みを使用します (bsc#1242493)。
    - CVE-2022-49775: tcp: cdg: tcp_cdg_release() を複数回呼び出すことを許可します (bsc#1242245)。
    - CVE-2022-49858: octeontx2-pf: SQE しきい値チェックを修正します (bsc#1242589)。
    - CVE-2023-53058: net/mlx5: E-Switch、エラー処理コードの Oops を修正します (bsc#1242237)。
    - CVE-2023-53060: igb: デッドロックを引き起こす rtnl_lock() を元に戻します (bsc#1242241)。
    - CVE-2023-53064: iavf: ice による再起動のハングアップを修正します (bsc#1242222)。
    - CVE-2023-53066: qed/qed_sriov: qed_iov_get_vf_info からの NULL デリファレンスに対する保護 (bsc#1242227)。
    - CVE-2023-53079: net/mlx5: ステアリングルールのクリーンアップを修正します (bsc#1242765)。
    - CVE-2023-53114: i40e: アダプターがリカバリモードの場合の再起動中のカーネルクラッシュを修正します (bsc#1242398)。
    - CVE-2023-53134: bnxt_en: TPA データ用の order-5 のメモリ割り当てを回避 (bsc#1242380)
    - CVE-2024-53168: net: sock_inuse_add() を利用可能にします (bsc#1234887)。
    - CVE-2024-56558: nfsd: svc_export_show の前に exp がアクティブであることを確認します (bsc#1235100)。
    - CVE-2025-21888: RDMA/mlx5: DM タイプに対する dereg_mr 中の WARN を修正します (bsc#1240177)。
    - CVE-2025-21999: proc: proc_get_inode() の UAF を修正します (bsc#1240802)。
    - CVE-2025-22056: netfilter: nft_tunnel: geneve_opt の型の混同に関する修正を追加 (bsc#1241525)。
    - CVE-2025-22060: net: mvpp2: パーサー TCAM メモリ破損を防ぎます (bsc#1241526)。
    - CVE-2025-23138: watch_queue: パイプアカウントの不一致を修正します (bsc#1241648)。
    - CVE-2025-23145: mptcp: can_accept_new_subflow の NULL ポインターを修正します (bsc#1242596)。
    - CVE-2025-37785: ext4: dotdot dir をチェックする際の OOB 読み取りを修正します (bsc#1241640)。
    - CVE-2025-37789: net: openvswitch: set() アクションのネストされたキーの長さの検証を修正します (bsc#1242762)。


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

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

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

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


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

    - CVE-2022-49775: tcp: cdg: tcp_cdg_release() を複数回呼び出すことを許可します (bsc#1242245)。
    - CVE-2024-53168: net: sock_inuse_add() を利用可能にします (bsc#1234887)。
    - CVE-2024-56558: nfsd: svc_export_show の前に exp がアクティブであることを確認します (bsc#1235100)。
    - CVE-2025-21999: proc: proc_get_inode() の UAF を修正します (bsc#1240802)。
    - CVE-2025-22056: netfilter: nft_tunnel: geneve_opt の型の混同に関する修正を追加 (bsc#1241525)。
    - CVE-2025-23145: mptcp: can_accept_new_subflow の NULL ポインターを修正します (bsc#1242596)。
    - CVE-2025-37789: net: openvswitch: set() アクションのネストされたキーの長さの検証を修正します (bsc#1242762)。
    - CVE-2024-28956:x86/its:ITS-safe indirect thunk のサポートを追加します(bsc#1242006)。
    - CVE-2025-37785: ext4: dotdot dir をチェックする際の OOB 読み取りを修正します (bsc#1241640)。


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

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
360928	CentOS Linux 8.5 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-core/kernel-cross-headers/etcの複数の脆弱性(CENTOS8.5:CLSA-2026:1771077729)	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
361173	CentOS Linux 8.4 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-core/kernel-cross-headers/etcの複数の脆弱性(CENTOS8.4:CLSA-2026:1771078945)	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
194262	RHEL 9 : kernel (RHSA-2023:6583)	Nessus	Red Hat Local Security Checks	2024/4/28	2025/10/28	high
249933	Linux Distros のパッチ未適用の脆弱性: CVE-2023-53077	Nessus	Misc.	2025/8/15	2026/9/30	high
352030	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-abi-stablelists/kernel-core/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2025:1765463110)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	high
185679	RHEL 8：kernel（RHSA-2023:7077）	Nessus	Red Hat Local Security Checks	2023/11/14	2025/9/10	high
241966	SUSE SLES15 :Linux カーネルのセキュリティ更新(SUSE-SU-2025:02262-1)	Nessus	SuSE Local Security Checks	2025/7/11	2026/6/25	high
241036	SUSE SLES15: Linux カーネルのセキュリティ更新 (SUSE-SU-2025:02173-1)	Nessus	SuSE Local Security Checks	2025/7/1	2026/9/29	medium

検出

プラグインの検索

high

high

high

high

high

high

high

medium