The remote NewStart CGSL host, running version MAIN 7.02, has kernel packages installed that are affected by multiple vulnerabilities:

  - In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue from session     lookup and expire Increment the session reference count within the lock for lookup to avoid racy issue     with session expire. (CVE-2024-58087)

  - In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition     around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see     something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD     8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID:
    53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS     PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]     Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b     47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP:
    0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001     RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08:
    ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c     R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000)     GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000     DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ?     gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20     [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ?
    __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ?
    __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ?
    __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]     nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I     hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This     ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to     nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread     B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since     refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and     it's write followed by a read. v2: use paired smp_rmb/smp_wmb. (CVE-2024-26984)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs     caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing,     timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be     deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs     will happen. The root cause is shown below: Cleanup Thread | Worker Thread sco_sock_release |     sco_sock_close | __sco_sock_close | sco_sock_set_timer | schedule_delayed_work | sco_sock_kill | (wait a     time) sock_put(sk) //FREE | sco_sock_timeout | sock_hold(sk) //USE The KASAN report triggered by POC is     shown below: [ 95.890016] ================================================================== [ 95.890496]     BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr     ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events sco_sock_timeout [ 95.890755]     Call Trace: [ 95.890755] <TASK> [ 95.890755] dump_stack_lvl+0x45/0x110 [ 95.890755]     print_address_description+0x78/0x390 [ 95.890755] print_report+0x11b/0x250 [ 95.890755] ?
    __virt_addr_valid+0xbe/0xf0 [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0 [ 95.890755]     kasan_report+0x139/0x170 [ 95.890755] ? update_load_avg+0xe5/0x9f0 [ 95.890755] ?     sco_sock_timeout+0x5e/0x1c0 [ 95.890755] kasan_check_range+0x2c3/0x2e0 [ 95.890755]     sco_sock_timeout+0x5e/0x1c0 [ 95.890755] process_one_work+0x561/0xc50 [ 95.890755]     worker_thread+0xab2/0x13c0 [ 95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] kthread+0x279/0x300 [     95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755]     ret_from_fork+0x34/0x60 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755] ret_from_fork_asm+0x11/0x20 [     95.890755] </TASK> [ 95.890755] [ 95.890755] Allocated by task 506: [ 95.890755]     kasan_save_track+0x3f/0x70 [ 95.890755] __kasan_kmalloc+0x86/0x90 [ 95.890755] __kmalloc+0x17f/0x360 [     95.890755] sk_prot_alloc+0xe1/0x1a0 [ 95.890755] sk_alloc+0x31/0x4e0 [ 95.890755] bt_sock_alloc+0x2b/0x2a0     [ 95.890755] sco_sock_create+0xad/0x320 [ 95.890755] bt_sock_create+0x145/0x320 [ 95.890755]
    __sock_create+0x2e1/0x650 [ 95.890755] __sys_socket+0xd0/0x280 [ 95.890755] __x64_sys_socket+0x75/0x80 [     95.890755] do_syscall_64+0xc4/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [     95.890755] Freed by task 506: [ 95.890755] kasan_save_track+0x3f/0x70 [ 95.890755]     kasan_save_free_info+0x40/0x50 [ 95.890755] poison_slab_object+0x118/0x180 [ 95.890755]
    __kasan_slab_free+0x12/0x30 [ 95.890755] kfree+0xb2/0x240 [ 95.890755] __sk_destruct+0x317/0x410 [     95.890755] sco_sock_release+0x232/0x280 [ 95.890755] sock_close+0xb2/0x210 [ 95.890755] __fput+0x37f/0x770     [ 95.890755] task_work_run+0x1ae/0x210 [ 95.890755] get_signal+0xe17/0xf70 [ 95.890755]     arch_do_signal_or_restart+0x3f/0x520 [ 95.890755] syscall_exit_to_user_mode+0x55/0x120 [ 95.890755]     do_syscall_64+0xd1/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [ 95.890755]     The buggy address belongs to the object at ffff88800c388000 [ 95.890755] which belongs to the cache     kmalloc-1k of size 1024 [ 95.890755] The buggy address is located 128 bytes inside of [ 95.890755] freed     1024-byte region [ffff88800c388000, ffff88800c388400) [ 95.890755] [ 95.890755] The buggy address belongs     to the physical page: [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000     index:0xffff88800c38a800 pfn:0xc388 [ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0     pincount:0 [ 95.890755] ano ---truncated--- (CVE-2024-27398)

  - In the Linux kernel, the following vulnerability has been resolved: firewire: nosy: ensure user_length is     taken into account when fetching packet contents Ensure that packet_buffer_get respects the user_length     provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to     signify to the user that no data were read and a larger buffer size is required. Helps prevent user space     overflows. (CVE-2024-27401)

  - In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage     childregs represents the registers which are active for the new thread in user context. For a kernel     thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode     helper, the gp value can be observed in user space after execve or possibly by other means. [From the     email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for     user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern     is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they     exec. childregs is the *user* context during syscall execution and it is observable from userspace in at     least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register     state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel
    __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in     its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this     patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs,     but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3.
    /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec     completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally     prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are     also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to     write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not     attempted to determine which forms of tracing allow access to user registers without already allowing     access to kernel registers. (CVE-2024-35871)

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

検出

プラグインの検索

high