Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1.

The CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2024:1725876080 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure     trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection     would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted     from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460     ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80     trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ?     pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ?     trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ?     trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ?     trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ?     pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ?     trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a     single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and     then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {     queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer)     ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /*     DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure     the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply     use it, as two events happening on two different CPUs that calls this at the same time, really doesn't     matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails,     simply try again the next time. If it failed to be taken, that means something else is already updating     it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a race between     writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap()     and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development     kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race     as done in other userfaultfd operations. (CVE-2021-47461)

  - In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length     underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic,     when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are     seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free     in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue     state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this     check is not reliable the error recovery work must flush async_event_work before continuing to destroy the     admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and     the error recovery handler itself changing the ctrl state. (CVE-2022-48788)

  - In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free     in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue     state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this     check is not reliable the error recovery work must flush async_event_work before continuing to destroy the     admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and     the error recovery handler itself changing the ctrl state. (CVE-2022-48789)

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

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2024:1725872696 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure     trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection     would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted     from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460     ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80     trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ?     pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ?     trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ?     trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ?     trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ?     pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ?     trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a     single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and     then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {     queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer)     ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /*     DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure     the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply     use it, as two events happening on two different CPUs that calls this at the same time, really doesn't     matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails,     simply try again the next time. If it failed to be taken, that means something else is already updating     it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length     underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic,     when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are     seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free     in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue     state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this     check is not reliable the error recovery work must flush async_event_work before continuing to destroy the     admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and     the error recovery handler itself changing the ctrl state. (CVE-2022-48788)

  - In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free     in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue     state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this     check is not reliable the error recovery work must flush async_event_work before continuing to destroy the     admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and     the error recovery handler itself changing the ctrl state. (CVE-2022-48789)

  - In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in     controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl     readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. ->     nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in     turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed,     submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In     order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER     submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So     after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting     the AER. (CVE-2022-48790)

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

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1778276927 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: fix shift-out-of-bounds     in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot     be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]     dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241     [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654     vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned     long, we should define these macros with same type too. (CVE-2022-50497)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer     overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid     req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: loop: Fix use-after-free issues     do_req_filebacked() calls blk_mq_complete_request() synchronously or asynchronously when using     asynchronous I/O unless memory allocation fails. Hence, modify loop_handle_cmd() such that it does not     dereference 'cmd' nor 'rq' after do_req_filebacked() finished unless we are sure that the request has not     yet been completed. This patch fixes the following kernel crash: Unable to handle kernel NULL pointer     dereference at virtual address 0000000000000054 Call trace: css_put.42938+0x1c/0x1ac     loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558     worker_thread+0x400/0x8fc kthread+0x16c/0x1e0 ret_from_fork+0x10/0x20 (CVE-2023-53111)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset +     VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the     allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]     BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds     in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-     executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat     KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description     mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433     kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic     lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472     drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol     drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812     ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e     drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP:
    0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
    ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40     RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000     R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38     kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline]
    ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525     kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc     include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]     create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]     ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603     drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965     ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl     fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856     do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which     belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte     region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page:
    page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36     head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags:
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300     dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated--- (CVE-2023-53265)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle     pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as     pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is     that the driver core ignores the error value and continues removing the device. This results in a resource     leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the     register mapping is already gone which probably results in a crash. (CVE-2023-53308)

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

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1778276927 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: fix shift-out-of-bounds     in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot     be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]     dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241     [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654     vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned     long, we should define these macros with same type too. (CVE-2022-50497)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer     overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid     req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: loop: Fix use-after-free issues     do_req_filebacked() calls blk_mq_complete_request() synchronously or asynchronously when using     asynchronous I/O unless memory allocation fails. Hence, modify loop_handle_cmd() such that it does not     dereference 'cmd' nor 'rq' after do_req_filebacked() finished unless we are sure that the request has not     yet been completed. This patch fixes the following kernel crash: Unable to handle kernel NULL pointer     dereference at virtual address 0000000000000054 Call trace: css_put.42938+0x1c/0x1ac     loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558     worker_thread+0x400/0x8fc kthread+0x16c/0x1e0 ret_from_fork+0x10/0x20 (CVE-2023-53111)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset +     VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the     allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]     BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds     in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-     executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat     KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description     mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433     kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic     lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472     drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol     drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812     ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e     drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP:
    0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
    ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40     RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000     R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38     kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline]
    ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525     kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc     include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]     create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]     ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603     drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965     ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl     fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856     do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which     belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte     region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page:
    page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36     head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags:
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300     dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated--- (CVE-2023-53265)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle     pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as     pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is     that the driver core ignores the error value and continues removing the device. This results in a resource     leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the     register mapping is already gone which probably results in a crash. (CVE-2023-53308)

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows     Local Execution of Code. This vulnerability is associated with program files     https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects     Linux kernel: from v2.6.12-rc2 before v6.8-rc1. (CVE-2024-21803)

Note that Nessus relies on the presence of the package as reported by the vendor.

The version of kernel installed on the remote Azure Linux 3.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2024-21803 advisory.

  - Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows     Local Execution of Code. This vulnerability is associated with program files     https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects     Linux kernel: from v2.6.12-rc2 before v6.8-rc1. (CVE-2024-21803)

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

The version of kernel installed on the remote CBL Mariner 2.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2024-21803 advisory.

  - Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows     Local Execution of Code. This vulnerability is associated with program files     https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects     Linux kernel: from v2.6.12-rc2 before v6.8-rc1. (CVE-2024-21803)

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

ID	Name	Product	Family	Type	Severity
366947	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2024:1725876080)	Nessus	CentOS Local Security Checks	Local	high
366937	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2024:1725872696)	Nessus	CentOS Local Security Checks	Local	high
352841	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778276927)	Nessus	Alma Linux Local Security Checks	Local	high
352446	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778276927)	Nessus	Rocky Linux Local Security Checks	Local	high
251872	Linux Distros Unpatched Vulnerability : CVE-2024-21803	Nessus	Misc.	Local	high
215471	Azure Linux 3.0 Security Update: kernel (CVE-2024-21803)	Nessus	Azure Linux Local Security Checks	Local	high
205681	CBL Mariner 2.0 Security Update: kernel (CVE-2024-21803)	Nessus	MarinerOS Local Security Checks	Local	high

Detections

Analytics

CVE-2024-21803

high

Tenable Plugins

high

high

high

high

high

high

high