In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active.

The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6743-3 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on     PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not     checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()     R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,     smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =     1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))     R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)     ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and     finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]     Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run     include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]     bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350     net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359     bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by     rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7     pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in     bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp     program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with     target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL     (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was     loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which     one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?     page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?     asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10     bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30     do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
    (CVE-2024-26591)

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

The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6742-2 advisory.

  - Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core     Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and     might lead to discovery of the encryption key and live injection, aka BLUFFS. (CVE-2023-24023)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

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

The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6743-2 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on     PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not     checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()     R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,     smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =     1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))     R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)     ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and     finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]     Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run     include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]     bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350     net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359     bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by     rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7     pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in     bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp     program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with     target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL     (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was     loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which     one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?     page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?     asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10     bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30     do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
    (CVE-2024-26591)

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

The remote Ubuntu 18.04 LTS / 20.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6741-1 advisory.

  - Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core     Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and     might lead to discovery of the encryption key and live injection, aka BLUFFS. (CVE-2023-24023)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on     PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not     checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()     R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,     smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =     1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))     R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)     ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and     finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]     Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run     include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]     bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350     net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359     bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by     rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7     pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

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

The remote Ubuntu 20.04 LTS / 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6742-1 advisory.

  - Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core     Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and     might lead to discovery of the encryption key and live injection, aka BLUFFS. (CVE-2023-24023)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

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

The remote Ubuntu 22.04 LTS / 23.10 host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6743-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 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:0x7fcdc0113fd9 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:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on     PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not     checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()     R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,     smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =     1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))     R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)     ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and     finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]     Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run     include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]     bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350     net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359     bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by     rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7     pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in     bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp     program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with     target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL     (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was     loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which     one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?     page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?     asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10     bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30     do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
    (CVE-2024-26591)

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

The version of kernel installed on the remote host is prior to 5.4.269-183.369. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.4-2024-062 advisory.

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in     alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct     dm_ioctl.target_count. (CVE-2023-52429)

  - In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in     skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a     forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
    mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final     result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1]     general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP     KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-     executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30     net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48     b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84     24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
    ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578     R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
    ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
    0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109     ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline]     validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338     dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276     packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto     net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3     e8 d1 19 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:00007fff8d685418 EFLAGS: 00000246     ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
    0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540     R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
    0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace     0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed     ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea     03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
    ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

  - A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function     improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing     between the free on the struct and the access through the `skbtxq` global queue. This could lead to a     denial of service condition or potential code execution. (CVE-2023-6270)

  - A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not     properly initialize memory in messages passed between virtual guests and the host operating system in the     vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel     memory contents when reading from the /dev/vhost-net device file. (CVE-2024-0340)

  - A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a     recursive operation of code push recursively calls into the code block. The OVS module does not validate     the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a     crash or other related issues. (CVE-2024-1151)

  - A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting     speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit     this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative     executable code paths. (CVE-2024-2193)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential     UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit     racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the     problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the     lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned     vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)

  - In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability     to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall     slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the     ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)

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

The version of kernel installed on the remote host is prior to 5.10.210-201.852. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.10-2024-053 advisory.

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in     alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct     dm_ioctl.target_count. (CVE-2023-52429)

  - In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in     skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a     forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
    mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final     result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1]     general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP     KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-     executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30     net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48     b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84     24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
    ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578     R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
    ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
    0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109     ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline]     validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338     dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276     packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto     net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3     e8 d1 19 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:00007fff8d685418 EFLAGS: 00000246     ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
    0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540     R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
    0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace     0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed     ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea     03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
    ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

  - A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function     improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing     between the free on the struct and the access through the `skbtxq` global queue. This could lead to a     denial of service condition or potential code execution. (CVE-2023-6270)

  - A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not     properly initialize memory in messages passed between virtual guests and the host operating system in the     vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel     memory contents when reading from the /dev/vhost-net device file. (CVE-2024-0340)

  - A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a     recursive operation of code push recursively calls into the code block. The OVS module does not validate     the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a     crash or other related issues. (CVE-2024-1151)

  - A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting     speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit     this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative     executable code paths. (CVE-2024-2193)

  - In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion     failure and crash because a subvolume can be read out too soon after its root item is inserted upon     subvolume creation. (CVE-2024-23850)

  - copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than     INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to     ctl_ioctl. (CVE-2024-23851)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability     to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall     slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the     ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)

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

The version of kernel installed on the remote host is prior to 5.15.149-99.161. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.15-2024-039 advisory.

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in     alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct     dm_ioctl.target_count. (CVE-2023-52429)

  - In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in     skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a     forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
    mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final     result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1]     general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP     KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-     executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30     net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48     b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84     24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
    ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578     R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
    ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
    0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109     ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline]     validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338     dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276     packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto     net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3     e8 d1 19 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:00007fff8d685418 EFLAGS: 00000246     ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
    0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540     R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
    0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace     0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed     ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea     03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
    ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

  - A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a     recursive operation of code push recursively calls into the code block. The OVS module does not validate     the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a     crash or other related issues. (CVE-2024-1151)

  - A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting     speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit     this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative     executable code paths. (CVE-2024-2193)

  - In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion     failure and crash because a subvolume can be read out too soon after its root item is inserted upon     subvolume creation. (CVE-2024-23850)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability     to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall     slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the     ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2024-549 advisory.

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in     alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct     dm_ioctl.target_count. (CVE-2023-52429)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOBs in     smb2_parse_contexts() Validate offsets and lengths before dereferencing create contexts in     smb2_parse_contexts(). This fixes following oops when accessing invalid create contexts from server: BUG:
    unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF:
    error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),     BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0     [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41     29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP:
    0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90     RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08:
    ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000     R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000)     GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ?
    __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ?     srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ?     smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260     [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs]     cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs]     vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ?
    _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0     entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e (CVE-2023-52434)

  - In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in     skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a     forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
    mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final     result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1]     general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP     KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-     executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30     net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48     b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84     24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
    ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578     R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
    ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
    0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109     ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline]     validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338     dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276     packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto     net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3     e8 d1 19 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:00007fff8d685418 EFLAGS: 00000246     ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
    0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540     R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
    0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace     0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed     ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea     03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
    ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

  - A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not     properly initialize memory in messages passed between virtual guests and the host operating system in the     vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel     memory contents when reading from the /dev/vhost-net device file. (CVE-2024-0340)

  - A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a     recursive operation of code push recursively calls into the code block. The OVS module does not validate     the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a     crash or other related issues. (CVE-2024-1151)

  - A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting     speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit     this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative     executable code paths. (CVE-2024-2193)

  - In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion     failure and crash because a subvolume can be read out too soon after its root item is inserted upon     subvolume creation. (CVE-2024-23850)

  - copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than     INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to     ctl_ioctl. (CVE-2024-23851)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end     interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just     added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with     partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so     the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when     we try to read from the partially-read skb. (CVE-2024-26582)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and     socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto     handler calls complete() so any code past that point risks touching already freed data. Try to avoid the     locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend     solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we     are now tightly controlling when completion fires. (CVE-2024-26583)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block     freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd (ext4: remove redundant     mb_regenerate_buddy()) and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast     commit replay can end up marking as free blocks that are already marked as such. This causes corruption of     the buddy bitmap so we need to regenerate it in that case. (CVE-2024-26601)

  - In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability     to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall     slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the     ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)

  - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for     info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken     from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a     sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in     fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer     required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area     which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the     still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead,     fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak     subject / changelog ] (CVE-2024-26603)

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

ID	Name	Product	Family	Severity
195025	Debian dsa-5681 : affs-modules-5.10.0-29-4kc-malta-di - security update	Nessus	Debian Local Security Checks	high
193851	Ubuntu 22.04 LTS : Linux kernel (Azure) vulnerabilities (USN-6743-3)	Nessus	Ubuntu Local Security Checks	high
193791	Ubuntu 22.04 LTS : Linux kernel vulnerabilities (USN-6742-2)	Nessus	Ubuntu Local Security Checks	high
193714	Ubuntu 22.04 LTS : Linux kernel (Low Latency) vulnerabilities (USN-6743-2)	Nessus	Ubuntu Local Security Checks	high
193596	Ubuntu 18.04 LTS / 20.04 LTS : Linux kernel vulnerabilities (USN-6741-1)	Nessus	Ubuntu Local Security Checks	high
193595	Ubuntu 20.04 LTS / 22.04 LTS : Linux kernel vulnerabilities (USN-6742-1)	Nessus	Ubuntu Local Security Checks	high
193592	Ubuntu 22.04 LTS / 23.10 : Linux kernel vulnerabilities (USN-6743-1)	Nessus	Ubuntu Local Security Checks	high
193309	Debian dsa-5658 : affs-modules-6.1.0-11-4kc-malta-di - security update	Nessus	Debian Local Security Checks	high
192742	Amazon Linux 2 : kernel (ALASKERNEL-5.4-2024-062)	Nessus	Amazon Linux Local Security Checks	high
192738	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2024-053)	Nessus	Amazon Linux Local Security Checks	high
191796	Ubuntu 22.04 LTS : Linux kernel (OEM) vulnerabilities (USN-6688-1)	Nessus	Ubuntu Local Security Checks	high
191612	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2024-039)	Nessus	Amazon Linux Local Security Checks	high
191609	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2024-549)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2024-26581

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high