GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-1668 (CVE-2024-57896)

Vulnerability from osv_openeuler – Published: 2025-06-27 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount

During the unmount path, at close_ctree(), we first stop the cleaner kthread, using kthread_stop() which frees the associated task_struct, and then stop and destroy all the work queues. However after we stopped the cleaner we may still have a worker from the delalloc_workers queue running inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(), which in turn tries to wake up the cleaner kthread - which was already destroyed before, resulting in a use-after-free on the task_struct.

Syzbot reported this with the following stack traces:

BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52

CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943

---truncated---(CVE-2024-57896)

In the Linux kernel, the following vulnerability has been resolved:

ext4: ignore xattrs past end

Once inside 'ext4_xattr_inode_dec_ref_all' we should ignore xattrs entries past the 'end' entry.

This fixes the following KASAN reported issue:

================================================================== BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 Read of size 4 at addr ffff888012c120c4 by task repro/2065

CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 </TASK>

The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360 The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168)

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x40(head|node=0|zone=0) page_type: f5(slab) raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc ---truncated---(CVE-2025-37738)

In the Linux kernel, the following vulnerability has been resolved:

objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()

If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.

Fixes the following warning with an UBSAN kernel:

drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)


{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-269.0.0.172.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-269.0.0.172.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-269.0.0.172.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-269.0.0.172.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: flush delalloc workers queue before stopping cleaner kthread during unmount\n\nDuring the unmount path, at close_ctree(), we first stop the cleaner\nkthread, using kthread_stop() which frees the associated task_struct, and\nthen stop and destroy all the work queues. However after we stopped the\ncleaner we may still have a worker from the delalloc_workers queue running\ninode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),\nwhich in turn tries to wake up the cleaner kthread - which was already\ndestroyed before, resulting in a use-after-free on the task_struct.\n\nSyzbot reported this with the following stack traces:\n\n  BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n  Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52\n\n  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  Workqueue: btrfs-delalloc btrfs_work_helper\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __dump_stack lib/dump_stack.c:94 [inline]\n   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n   print_address_description mm/kasan/report.c:378 [inline]\n   print_report+0x169/0x550 mm/kasan/report.c:489\n   kasan_report+0x143/0x180 mm/kasan/report.c:602\n   __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162\n   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]\n   try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205\n   submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615\n   run_ordered_work fs/btrfs/async-thread.c:288 [inline]\n   btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324\n   process_one_work kernel/workqueue.c:3229 [inline]\n   process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310\n   worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n   kthread+0x2f0/0x390 kernel/kthread.c:389\n   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 2:\n   kasan_save_stack mm/kasan/common.c:47 [inline]\n   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n   unpoison_slab_object mm/kasan/common.c:319 [inline]\n   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345\n   kasan_slab_alloc include/linux/kasan.h:250 [inline]\n   slab_post_alloc_hook mm/slub.c:4104 [inline]\n   slab_alloc_node mm/slub.c:4153 [inline]\n   kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205\n   alloc_task_struct_node kernel/fork.c:180 [inline]\n   dup_task_struct+0x57/0x8c0 kernel/fork.c:1113\n   copy_process+0x5d1/0x3d50 kernel/fork.c:2225\n   kernel_clone+0x223/0x870 kernel/fork.c:2807\n   kernel_thread+0x1bc/0x240 kernel/fork.c:2869\n   create_kthread kernel/kthread.c:412 [inline]\n   kthreadd+0x60d/0x810 kernel/kthread.c:767\n   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n  Freed by task 24:\n   kasan_save_stack mm/kasan/common.c:47 [inline]\n   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582\n   poison_slab_object mm/kasan/common.c:247 [inline]\n   __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264\n   kasan_slab_free include/linux/kasan.h:233 [inline]\n   slab_free_hook mm/slub.c:2338 [inline]\n   slab_free mm/slub.c:4598 [inline]\n   kmem_cache_free+0x195/0x410 mm/slub.c:4700\n   put_task_struct include/linux/sched/task.h:144 [inline]\n   delayed_put_task_struct+0x125/0x300 kernel/exit.c:227\n   rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n   rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n   handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554\n   run_ksoftirqd+0xca/0x130 kernel/softirq.c:943\n  \n---truncated---(CVE-2024-57896)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: ignore xattrs past end\n\nOnce inside \u0026apos;ext4_xattr_inode_dec_ref_all\u0026apos; we should\nignore xattrs entries past the \u0026apos;end\u0026apos; entry.\n\nThis fixes the following KASAN reported issue:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\nRead of size 4 at addr ffff888012c120c4 by task repro/2065\n\nCPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x1fd/0x300\n ? tcp_gro_dev_warn+0x260/0x260\n ? _printk+0xc0/0x100\n ? read_lock_is_recursive+0x10/0x10\n ? irq_work_queue+0x72/0xf0\n ? __virt_addr_valid+0x17b/0x4b0\n print_address_description+0x78/0x390\n print_report+0x107/0x1f0\n ? __virt_addr_valid+0x17b/0x4b0\n ? __virt_addr_valid+0x3ff/0x4b0\n ? __phys_addr+0xb5/0x160\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n kasan_report+0xcc/0x100\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ? ext4_xattr_delete_inode+0xd30/0xd30\n ? __ext4_journal_ensure_credits+0x5f0/0x5f0\n ? __ext4_journal_ensure_credits+0x2b/0x5f0\n ? inode_update_timestamps+0x410/0x410\n ext4_xattr_delete_inode+0xb64/0xd30\n ? ext4_truncate+0xb70/0xdc0\n ? ext4_expand_extra_isize_ea+0x1d20/0x1d20\n ? __ext4_mark_inode_dirty+0x670/0x670\n ? ext4_journal_check_start+0x16f/0x240\n ? ext4_inode_is_fast_symlink+0x2f2/0x3a0\n ext4_evict_inode+0xc8c/0xff0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n ? do_raw_spin_unlock+0x53/0x8a0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n evict+0x4ac/0x950\n ? proc_nr_inodes+0x310/0x310\n ? trace_ext4_drop_inode+0xa2/0x220\n ? _raw_spin_unlock+0x1a/0x30\n ? iput+0x4cb/0x7e0\n do_unlinkat+0x495/0x7c0\n ? try_break_deleg+0x120/0x120\n ? 0xffffffff81000000\n ? __check_object_size+0x15a/0x210\n ? strncpy_from_user+0x13e/0x250\n ? getname_flags+0x1dc/0x530\n __x64_sys_unlinkat+0xc8/0xf0\n do_syscall_64+0x65/0x110\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x434ffd\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8\nRSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107\nRAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd\nRDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005\nRBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;\n\nThe buggy address belongs to the object at ffff888012c12000\n which belongs to the cache filp of size 360\nThe buggy address is located 196 bytes inside of\n freed 360-byte region [ffff888012c12000, ffff888012c12168)\n\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12\nhead: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\nflags: 0x40(head|node=0|zone=0)\npage_type: f5(slab)\nraw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nraw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nhead: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000\nhead: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n\u0026gt; ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                           ^\n ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc\n ffff888012c12180: fc fc fc fc fc fc fc fc fc\n---truncated---(CVE-2025-37738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()\u0026apos;s call to dib8000_read32() returns zero, the result\nis a divide-by-zero.  Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)",
  "id": "OESA-2025-1668",
  "modified": "2026-08-06T11:08:45Z",
  "published": "2025-06-27T11:08:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37937"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-57896",
    "CVE-2025-37738",
    "CVE-2025-37937"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…