Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

4 participants
6271 discussions

[PATCH v8 0/7] Rust bindings for gem shmem + iosys_map

by Lyude Paul

This is the next version of the shmem backed GEM objects series originally from Asahi, previously posted by Daniel Almeida. One of the major changes in this patch series is a much better interface around vmaps, which we achieve by introducing a new set of rust bindings for iosys_map. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/156093/ This patch series may be applied on top of the driver-core/driver-core-testing branch: https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git… Changelogs are per-patch Asahi Lina (2): rust: helpers: Add bindings/wrappers for dma_resv_lock rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul (5): rust: drm: Add gem::impl_aref_for_gem_obj! rust: drm: gem: Add raw_dma_resv() function rust: gem: Introduce DriverObject::Args rust: drm: gem: Introduce shmem::SGTable rust: drm/gem: Add vmap functions to shmem bindings drivers/gpu/drm/nova/gem.rs | 5 +- drivers/gpu/drm/tyr/gem.rs | 3 +- rust/bindings/bindings_helper.h | 3 + rust/helpers/dma-resv.c | 13 + rust/helpers/drm.c | 56 +++- rust/helpers/helpers.c | 1 + rust/kernel/drm/gem/mod.rs | 79 +++-- rust/kernel/drm/gem/shmem.rs | 529 ++++++++++++++++++++++++++++++++ 8 files changed, 667 insertions(+), 22 deletions(-) create mode 100644 rust/helpers/dma-resv.c create mode 100644 rust/kernel/drm/gem/shmem.rs -- 2.53.0

1 month, 2 weeks

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

Hey everyone! I'm thrilled to announce that I have fully rec0vered my l0cked BTC from an inve stment platf0rm even after 3 months it happened. Here's a quick story. Early this year, I came across an inve stment platf0rm that gave me my profit after the first inve stment , I did the second it was successful and I tried the 3rd this time with a bigger amount of $120,000, when it was time for withdr awal I couldn't, the option was l0cked, After weeks of trying I l0st hope, fast-forward to last week I saw a post about rec0 vering l0cked or st0len fuñ ds, tho I was skeptical but I gave it a try what more could I lose?? In 2 4hrs ghosttrackhackers@gmail . com h€lped me r€trieve my full fuπds (of $120,000) including profit ($40,000). It's back safe in my w@ll€t. I know many have fallen v!ct!m too you can re@ch out to th€m for h€lp they're l€git and €asy to talk to. Goodluck. ✉️: ghosttrackhackers @ gmail . com

1 month, 3 weeks

Re: [PATCH] lib/scatterlist: fix sg_page_count and sg_dma_page_count

by Julian Orth

On Sun, Mar 8, 2026 at 7:08 PM Jason Gunthorpe <jgg(a)ziepe.ca> wrote: > > On Sun, Mar 08, 2026 at 02:55:27PM +0100, Julian Orth wrote: > > A user reported memory corruption in the Jay wayland compositor [1]. The > > corruption started when archlinux enabled > > CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE in kernel 6.19.5. > > > > The compositor uses udmabuf to upload memory from memfds to the GPU. > > When running an affected kernel, the following warnings are logged: > > > > a - addrs >= max_entries > > WARNING: drivers/gpu/drm/drm_prime.c:1089 at drm_prime_sg_to_dma_addr_array+0x86/0xc0, CPU#31: jay/1864 > > [...] > > Call Trace: > > <TASK> > > amdgpu_bo_move+0x188/0x800 [amdgpu 3b451640234948027c09e9b39e6520bc7e5471cf] > > > > Disabling the use of huge pages at runtime via > > /sys/kernel/mm/transparent_hugepage/shmem_enabled fixes the issue. > > > > udmabuf allocates a scatterlist with buffer_size/PAGE_SIZE entries. Each > > entry has a length of PAGE_SIZE. With huge pages disabled, it appears > > that sg->offset is always 0. With huge pages enabled, sg->offset is > > incremented by PAGE_SIZE until the end of the huge page. > > This was broken by 0c8b91ef5100 ("udmabuf: add back support for > mapping hugetlb pages") which switched from a working > sg_alloc_table_from_pages() to a messed up sg_set_pages loop: > > + for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) > + sg_set_page(sgl, ubuf->pages[i], PAGE_SIZE, ubuf->offsets[i]); > [..] > + ubuf->offsets[*pgbuf] = subpgoff << PAGE_SHIFT; > > Which is just the wrong way to use the scatterlist API. > > This was later changed to sg_set_folio() which I'm also suspecting has > a bug, it should be setting page_link to the proper tail page because > as you observe page_offset must fall within 0 to PAGE_SIZE-1 to make > the iterator work. > > I think the whole design here in udmabuf makes very little sense. It > starts out with an actual list of folios then expands them to a per-4K > double array of folio/offset. This is nonsensical, if it wants to > build a way to direct index the mapping for mmap it should just build > itself a page * array like the code used to do and continue to use > sg_alloc_table_from_pages() which builds properly formed scatterlists. > > This would save memory, use the APIs properly and build a correct and > optimized scatterlist to boot. It uses vmf_insert_pfn() and > vm_map_ram() anyhow so it doesn't even use a folio :\ > > Here, a few mins of AI shows what I think udmabuf should look like. If > you wish to persue this please add my signed-off-by and handle testing > it and getting it merged. I reviewed it enough to see it was showing > what I wanted. I don't know enough about folios or udmabuf to efficiently work on this. If offset is supposed to be in [0, PAGE_SIZE-1], then my patch is incorrect and it's probably better if some of the udmabuf maintainers take a look at this. I've added them to CC. > > Jason > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index 94b8ecb892bb17..5d687860445137 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -26,10 +26,10 @@ MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is > > struct udmabuf { > pgoff_t pagecount; > - struct folio **folios; > + struct page **pages; > > /** > - * Unlike folios, pinned_folios is only used for unpin. > + * Unlike pages, pinned_folios is only used for unpin. > * So, nr_pinned is not the same to pagecount, the pinned_folios > * only set each folio which already pinned when udmabuf_create. > * Note that, since a folio may be pinned multiple times, each folio > @@ -41,7 +41,6 @@ struct udmabuf { > > struct sg_table *sg; > struct miscdevice *device; > - pgoff_t *offsets; > }; > > static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) > @@ -55,8 +54,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) > if (pgoff >= ubuf->pagecount) > return VM_FAULT_SIGBUS; > > - pfn = folio_pfn(ubuf->folios[pgoff]); > - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; > + pfn = page_to_pfn(ubuf->pages[pgoff]); > > ret = vmf_insert_pfn(vma, vmf->address, pfn); > if (ret & VM_FAULT_ERROR) > @@ -73,8 +71,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) > if (WARN_ON(pgoff >= ubuf->pagecount)) > break; > > - pfn = folio_pfn(ubuf->folios[pgoff]); > - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; > + pfn = page_to_pfn(ubuf->pages[pgoff]); > > /** > * If the below vmf_insert_pfn() fails, we do not return an > @@ -109,22 +106,11 @@ static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) > static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > { > struct udmabuf *ubuf = buf->priv; > - struct page **pages; > void *vaddr; > - pgoff_t pg; > > dma_resv_assert_held(buf->resv); > > - pages = kvmalloc_objs(*pages, ubuf->pagecount); > - if (!pages) > - return -ENOMEM; > - > - for (pg = 0; pg < ubuf->pagecount; pg++) > - pages[pg] = folio_page(ubuf->folios[pg], > - ubuf->offsets[pg] >> PAGE_SHIFT); > - > - vaddr = vm_map_ram(pages, ubuf->pagecount, -1); > - kvfree(pages); > + vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); > if (!vaddr) > return -EINVAL; > > @@ -146,22 +132,18 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > { > struct udmabuf *ubuf = buf->priv; > struct sg_table *sg; > - struct scatterlist *sgl; > - unsigned int i = 0; > int ret; > > sg = kzalloc_obj(*sg); > if (!sg) > return ERR_PTR(-ENOMEM); > > - ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL); > + ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, 0, > + ubuf->pagecount << PAGE_SHIFT, > + GFP_KERNEL); > if (ret < 0) > goto err_alloc; > > - for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) > - sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, > - ubuf->offsets[i]); > - > ret = dma_map_sgtable(dev, sg, direction, 0); > if (ret < 0) > goto err_map; > @@ -207,12 +189,8 @@ static void unpin_all_folios(struct udmabuf *ubuf) > > static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) > { > - ubuf->folios = kvmalloc_objs(*ubuf->folios, pgcnt); > - if (!ubuf->folios) > - return -ENOMEM; > - > - ubuf->offsets = kvzalloc_objs(*ubuf->offsets, pgcnt); > - if (!ubuf->offsets) > + ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt); > + if (!ubuf->pages) > return -ENOMEM; > > ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt); > @@ -225,8 +203,7 @@ static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) > static __always_inline void deinit_udmabuf(struct udmabuf *ubuf) > { > unpin_all_folios(ubuf); > - kvfree(ubuf->offsets); > - kvfree(ubuf->folios); > + kvfree(ubuf->pages); > } > > static void release_udmabuf(struct dma_buf *buf) > @@ -344,8 +321,8 @@ static long udmabuf_pin_folios(struct udmabuf *ubuf, struct file *memfd, > ubuf->pinned_folios[nr_pinned++] = folios[cur_folio]; > > for (; subpgoff < fsize; subpgoff += PAGE_SIZE) { > - ubuf->folios[upgcnt] = folios[cur_folio]; > - ubuf->offsets[upgcnt] = subpgoff; > + ubuf->pages[upgcnt] = folio_page(folios[cur_folio], > + subpgoff >> PAGE_SHIFT); > ++upgcnt; > > if (++cur_pgcnt >= pgcnt) >

1 month, 3 weeks

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

1 month, 3 weeks

[PATCH v2 0/2] dma-buf: heaps: Use page clearing helpers

by Linus Walleij

Use clear_pages() and clear_highpage() properly in the DMA heap allocator. Signed-off-by: Linus Walleij <linusw(a)kernel.org> --- Changes in v2: - Added a second patch to use the clear_highpage() helper. - Link to v1: https://lore.kernel.org/r/20260304-cma-heap-clear-pages-v1-1-6ff59da716d3@k… --- Linus Walleij (2): dma-buf: heaps: Clear CMA pages with clear_pages() dma-buf: heaps: Clear CMA highages using helper drivers/dma-buf/heaps/cma_heap.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260303-cma-heap-clear-pages-540f3ac9f734 Best regards, -- Linus Walleij <linusw(a)kernel.org>

1 month, 3 weeks

[syzbot] [media?] [dri?] KASAN: slab-use-after-free Read in dma_buf_fd

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 5ee8dbf54602 Merge tag 'fsverity-for-linus' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=143e4a02580000 kernel config: https://syzkaller.appspot.com/x/.config?x=2a019678b1a3a692 dashboard link: https://syzkaller.appspot.com/bug?extid=7f4987d0afb97dd090cb compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/8f3ca4731c70/disk-5ee8dbf5.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/9e6d67fcdf59/vmlinux-5ee8dbf5.… kernel image: https://storage.googleapis.com/syzbot-assets/dd6699ad586c/bzImage-5ee8dbf5.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7f4987d0afb97dd090cb(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff888034d9c068 by task syz.6.794/10028 CPU: 1 UID: 0 PID: 10028 Comm: syz.6.794 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:574 kasan_check_byte include/linux/kasan.h:402 [inline] lock_acquire+0x79/0x2e0 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline] _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:162 rt_mutex_slowunlock+0xbf/0x8b0 kernel/locking/rtmutex.c:1417 spin_unlock include/linux/spinlock_rt.h:109 [inline] class_spinlock_destructor include/linux/spinlock.h:586 [inline] dma_buf_fd+0x189/0x370 drivers/dma-buf/dma-buf.c:796 vb2_core_expbuf+0x37e/0x620 drivers/media/common/videobuf2/videobuf2-core.c:2471 __video_do_ioctl+0x88c/0xc50 drivers/media/v4l2-core/v4l2-ioctl.c:3132 video_usercopy+0x876/0x14b0 drivers/media/v4l2-core/v4l2-ioctl.c:3474 v4l2_ioctl+0x190/0x1e0 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xff/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa4633cc799 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa46161e028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fa463645fa0 RCX: 00007fa4633cc799 RDX: 0000200000000040 RSI: 00000000c0405610 RDI: 0000000000000004 RBP: 00007fa463462bd9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa463646038 R14: 00007fa463645fa0 R15: 00007ffe4429d3d8 </TASK> Allocated by task 10028: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5238 [inline] __kmalloc_noprof+0x3e7/0x7b0 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] dma_buf_export+0x3ba/0xb10 drivers/dma-buf/dma-buf.c:739 vb2_vmalloc_get_dmabuf+0x10e/0x210 drivers/media/common/videobuf2/videobuf2-vmalloc.c:352 vb2_core_expbuf+0x314/0x620 drivers/media/common/videobuf2/videobuf2-core.c:2461 __video_do_ioctl+0x88c/0xc50 drivers/media/v4l2-core/v4l2-ioctl.c:3132 video_usercopy+0x876/0x14b0 drivers/media/v4l2-core/v4l2-ioctl.c:3474 v4l2_ioctl+0x190/0x1e0 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xff/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 10031: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2692 [inline] slab_free mm/slub.c:6143 [inline] kfree+0x1c1/0x6c0 mm/slub.c:6461 __dentry_kill+0x211/0x5e0 fs/dcache.c:675 finish_dput+0xc9/0x480 fs/dcache.c:879 __fput+0x6a3/0xa90 fs/file_table.c:477 task_work_run+0x1d9/0x270 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:67 [inline] exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline] do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888034d9c000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 104 bytes inside of freed 1024-byte region [ffff888034d9c000, ffff888034d9c400) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x34d98 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff88813fe1cdc0 dead000000000100 dead000000000122 raw: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000 head: 0080000000000040 ffff88813fe1cdc0 dead000000000100 dead000000000122 head: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000d36601 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 6221, tgid 6216 (syz.3.71), ts 173025510293, free_ts 172769017733 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889 prep_new_page mm/page_alloc.c:1897 [inline] get_page_from_freelist+0x28bb/0x2950 mm/page_alloc.c:3962 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250 alloc_slab_page mm/slub.c:3269 [inline] allocate_slab+0x77/0x660 mm/slub.c:3458 new_slab mm/slub.c:3516 [inline] refill_objects+0x334/0x3c0 mm/slub.c:7153 refill_sheaf mm/slub.c:2818 [inline] __pcs_replace_empty_main+0x328/0x5f0 mm/slub.c:4592 alloc_from_pcs mm/slub.c:4695 [inline] slab_alloc_node mm/slub.c:4829 [inline] __kmalloc_cache_noprof+0x44e/0x690 mm/slub.c:5353 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] snd_seq_oss_open+0x125/0xfc0 sound/core/seq/oss/seq_oss_init.c:171 odev_open+0x67/0xd0 sound/core/seq/oss/seq_oss.c:128 chrdev_open+0x4d0/0x5f0 fs/char_dev.c:411 do_dentry_open+0x83d/0x13e0 fs/open.c:949 vfs_open+0x3b/0x350 fs/open.c:1081 do_open fs/namei.c:4671 [inline] path_openat+0x2e43/0x38a0 fs/namei.c:4830 do_file_open+0x23e/0x4a0 fs/namei.c:4859 do_sys_openat2+0x113/0x200 fs/open.c:1366 do_sys_open fs/open.c:1372 [inline] __do_sys_openat fs/open.c:1388 [inline] __se_sys_openat fs/open.c:1383 [inline] __x64_sys_openat+0x138/0x170 fs/open.c:1383 page last free pid 6219 tgid 6219 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] __free_pages_prepare mm/page_alloc.c:1433 [inline] __free_frozen_pages+0xfe3/0x1170 mm/page_alloc.c:2978 __slab_free+0x24f/0x2a0 mm/slub.c:5551 qlink_free mm/kasan/quarantine.c:163 [inline] qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179 kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286 __kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4515 [inline] slab_alloc_node mm/slub.c:4844 [inline] kmem_cache_alloc_noprof+0x33b/0x680 mm/slub.c:4851 vm_area_dup+0x2b/0x670 mm/vma_init.c:123 __split_vma+0x1e4/0xa30 mm/vma.c:513 split_vma mm/vma.c:596 [inline] vma_modify+0x94b/0x1f00 mm/vma.c:1672 vma_modify_flags+0x24b/0x330 mm/vma.c:1700 mprotect_fixup+0x47a/0xa80 mm/mprotect.c:756 do_mprotect_pkey+0x8ab/0xcd0 mm/mprotect.c:930 __do_sys_mprotect mm/mprotect.c:951 [inline] __se_sys_mprotect mm/mprotect.c:948 [inline] __x64_sys_mprotect+0x80/0x90 mm/mprotect.c:948 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Memory state around the buggy address: ffff888034d9bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888034d9bf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888034d9c000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888034d9c080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888034d9c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

1 month, 3 weeks

Professional Digital Assets Recovery and Investigation Services

by Cryptera Chain Signals (CCS)

The digital asset space in March 2026 continues to grow rapidly, but so do the risks. Phishing attacks, fake investment platforms, pig-butchering schemes, wallet exploits, rug pulls, and address-poisoning fraud result in billions in losses annually. Once cryptocurrency leaves a victim's control—whether through deception, malware, or access issues—blockchain's irreversible and pseudonymous design offers no central authority for reversal or reset. Recovery becomes a matter of investigation, forensic tracing, evidence gathering, and coordinated action rather than simple reversal. Professional digital assets recovery and investigation services focus on two primary areas: (1) restoring access to legitimately owned but locked wallets (forgotten passwords, damaged hardware, corrupted files), and (2) tracing stolen funds to map movement, identify laundering patterns, and locate potential intervention points such as regulated centralized exchanges for asset freezes or law enforcement seizures. These services rely on public blockchain data—transaction hashes (TXIDs), addresses, amounts, timestamps—and advanced analytics to reconstruct flows that basic explorers cannot follow. Legitimate providers never guarantee full recovery; blockchain immutability prevents that. Success is partial at best and depends on early detection, evidence quality, laundering complexity, and cooperation from exchanges or authorities. The industry is unregulated, creating a high risk of secondary scams: fraudsters contact victims unsolicited, demand large upfront cryptocurrency payments, promise guaranteed results, and disappear. Official warnings from the FBI, FTC, and blockchain analytics firms consistently identify these as advance-fee fraud. Trusted services share common traits: Transparent methodology explained on professional websites Free or low-cost initial consultations to review evidence (TXIDs, addresses, communications) No requests for private keys, seed phrases, or wallet access upfront Honest feasibility assessments without absolute guarantees Focus on forensic reports for exchange compliance submissions, regulatory filings, or law enforcement coordination (FBI IC3, local cyber units) Emphasis on prevention education (hardware wallets, address verification, secure backups, monitoring) Cryptera Chain Signals (CCS) is a firm that aligns with these standards of professional digital assets recovery and investigation. With 28 years of experience in digital forensics—long before cryptocurrencies became mainstream—CCS specializes in multi-layer blockchain attribution. Their process reconstructs transaction paths through complex obfuscation methods (mixers, cross-chain bridges, DEX swaps, privacy protocols, flash-loan laundering), clusters addresses using behavioral heuristics (co-spending patterns, change address reuse, timing/amount correlations), identifies high-confidence endpoints on KYC/AML-compliant exchanges, and produces detailed forensic reports suitable for freeze requests or official submissions. They prioritize secure intake, transparency—no large upfront fees without case evaluation—and realistic guidance, helping victims understand fund movements and viable next steps. Other established names in the space include institutional analytics providers like Chainalysis, TRM Labs, Elliptic, and CipherTrace, which primarily serve exchanges, regulators, and law enforcement for large-scale tracing and seizures. Consumer-facing firms such as KeychainX (often for password/seed recovery), Wallet Recovery Services, Crypto Asset Recovery, and Puran Crypto Recovery appear in forums and testimonials for access restoration or scam tracing. Many mentions, however, originate from self-published articles or sponsored content, so independent verification is essential. To identify legitimate services: Transparency — Clear website with methodology details, verifiable contact information. No red flags — Avoid upfront crypto demands, guarantees, unsolicited outreach, pressure tactics. Evidence focus — Emphasis on forensic reports for freezes, official submissions, or legal use. Independent checks — Verify domain age (whois), search scam warnings, cross-reference neutral reviews. First action — Report to authorities (FBI IC3, FTC, local police) before engaging any service—official reports create records and may aid broader actions. Cryptera Chain Signals (CCS) incorporates these qualities: confidential consultations, advanced multi-layer tracing, detailed forensic reporting, honest assessments, and a focus on client education and protection. Their experience supports victims in gaining clarity on access issues or stolen-fund movements and pursuing realistic options when leads exist. While no service guarantees recovery—due to strong encryption, complete seed loss, heavy laundering, dispersal, or jurisdictional limits—professional digital assets investigation offers the clearest path to evidence and intervention. Early action (secure remaining assets, document evidence, report officially) and choosing vetted providers remain essential. For more information on professional blockchain forensics, transaction tracing methods, and realistic guidance for digital asset recovery, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In 2026, trusted digital assets recovery and investigation require caution, technical depth, and integrity. Firms like Cryptera Chain Signals (CCS) represent the kind of professional, evidence-based approach that prioritizes transparency and realistic outcomes in a high-risk and often exploitative field.

1 month, 3 weeks

Best Fraud Investigation Services for Cryptocurrency Scams

by Cryptera Chain Signals (CCS)

Cryptocurrency scams continue to evolve rapidly in March 2026, with losses estimated in the tens of billions annually according to reports from firms like Chainalysis and TRM Labs. Schemes such as phishing, fake investment platforms, pig-butchering operations, rug pulls, and AI-enhanced impersonation fraud exploit blockchain's pseudonymity and irreversibility, leaving victims searching for ways to trace stolen funds and pursue accountability. Fraud investigation services in this space focus on blockchain forensics—analyzing public ledger data to reconstruct transaction flows, cluster addresses under common control, identify laundering techniques, and locate potential intervention points like regulated exchanges for asset freezes or law enforcement seizures. The field blends technical expertise with investigative rigor, but it's largely unregulated, creating a high risk of secondary scams. Many "recovery" outfits contact victims unsolicited, demand large upfront cryptocurrency payments, and promise guaranteed results—classic advance-fee fraud. Legitimate services prioritize transparency, evidence-based analysis, realistic assessments, and no premature requests for private keys or seed phrases. Professional blockchain forensics firms use public transaction data (addresses, amounts, timestamps, TXIDs) and apply heuristics like co-spending patterns, change address reuse, timing/amount correlations, and behavioral fingerprints to cluster addresses and map complex paths. They track through obfuscation methods—mixers/tumblers, cross-chain bridges, decentralized exchanges, privacy protocols, flash-loan laundering—and produce detailed forensic reports for exchange compliance submissions, regulatory filings, or authorities (e.g., FBI IC3, local cybercrime units). Partial recoveries occur in cases where funds reach KYC/AML-compliant platforms quickly, or broader seizures disrupt scam networks. Cryptera Chain Signals (CCS) is a firm that aligns with the traits of credible fraud investigation services. With 28 years of digital investigation experience, CCS specializes in multi-layer blockchain attribution—reconstructing fund flows through sophisticated laundering paths that standard tools cannot follow. Their process includes secure intake (no keys required upfront), transaction graphing, address clustering, endpoint identification (especially regulated exchanges), and production of evidence-grade reports suitable for freeze requests or law enforcement coordination. They emphasize honest feasibility evaluations—no large upfront fees without case review, no unrealistic guarantees—and include prevention education to help victims avoid recurrence. Other names appear in 2026 discussions and reports. Institutional-grade providers like Chainalysis, TRM Labs, Elliptic, and CipherTrace offer advanced analytics primarily to exchanges, regulators, and law enforcement for large-scale investigations and seizures (e.g., recent actions against Southeast Asian scam networks or sanctions evasion). Firms like StoneTurn or Crystal Intelligence provide targeted crypto investigations for private clients and legal teams, focusing on asset tracing and recovery support. Consumer-facing services such as Puran Crypto Recovery, TechY Force Cyber Retrieval, or ChainX Hacker Solutions are mentioned in online lists and testimonials, often highlighting scam-specific tracing or compliance coordination. However, many such mentions come from self-published articles, sponsored content, or forums with limited independent verification—caution is advised, as promotional bias is common. To identify legitimate fraud investigation services: Transparency — Clear methodology on a professional website, verifiable contact details, no encrypted-chat-only operations. No red flags — Avoid upfront crypto demands, guarantees, unsolicited outreach, or pressure tactics. Evidence focus — Emphasis on forensic reports for freezes, official submissions, or legal use. Independent checks — Verify domain age (whois), search for scam warnings, cross-reference neutral reviews. First step — Report to authorities (FBI IC3, FTC, local cyber units) to create records and aid potential actions. Cryptera Chain Signals (CCS) incorporates these qualities: confidential consultations, advanced multi-layer tracing, detailed reporting, and a client-centered focus that avoids common pitfalls. Their experience helps victims gain clarity on scam mechanics and pursue realistic options when leads exist. While no service guarantees recovery—due to laundering complexity, privacy tools, dispersal, or jurisdictional limits—professional blockchain investigation offers the clearest path to evidence and intervention. Early reporting, strong documentation, and vetted forensics remain key to any progress. For more on blockchain fraud investigation, forensic tracing methods, and realistic guidance for scam victims, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In 2026, trusted fraud investigation for cryptocurrency scams requires caution, technical depth, and integrity. Services like Cryptera Chain Signals (CCS) represent the kind of professional, evidence-based approach that prioritizes transparency and realistic outcomes in a high-risk and often exploitative field.

1 month, 3 weeks

Professional Blockchain Transaction Tracing Services

by Cryptera Chain Signals (CCS)

Blockchain transaction tracing has become an essential service in the cryptocurrency ecosystem. As digital asset theft, scams, and fraud continue to cause billions in losses each year, the ability to follow funds across public ledgers offers victims, law enforcement, and institutions a path to clarity and potential intervention. While blockchain's immutable and pseudonymous design prevents direct reversals of transactions, professional tracing can reconstruct movement patterns, identify laundering techniques, cluster addresses under common control, and locate high-confidence endpoints—often centralized exchanges with KYC/AML compliance—where freeze requests or seizures become possible. Professional services in this field combine deep knowledge of blockchain protocols with advanced analytics tools. They analyze on-chain data (addresses, amounts, timestamps, transaction hashes) and apply behavioral heuristics to map complex flows that standard block explorers cannot follow. These services are particularly valuable in cases involving phishing, fake investment platforms, rug pulls, wallet compromises, or inheritance lockouts where access is lost but funds remain traceable. Cryptera Chain Signals (CCS) is a firm that exemplifies professional blockchain transaction tracing. With 28 years of experience in digital investigations—long before cryptocurrencies became mainstream—CCS focuses on forensic-grade analysis rather than speculative promises. Their work supports scam victims, legal teams, and organizations by delivering detailed, evidence-based insights into fund movements. Core Components of Professional Tracing Secure Case Intake and Evidence Gathering The process starts with a confidential consultation. Clients provide transaction hashes (TXIDs), wallet addresses, timestamps, scam communications, and supporting evidence without sharing private keys or seed phrases. This step ensures security and allows investigators to assess feasibility honestly from the outset. Initial Transaction Lookup and Graph Construction Using public blockchain nodes and APIs, experts retrieve the full transaction history linked to the provided TXIDs. They construct directed graphs showing inflows, outflows, splits, and consolidations. Visualization tools make it easier to see branching paths and consolidation points early on. Address Clustering and Entity Resolution Investigators apply behavioral heuristics to group addresses likely controlled by the same actor: Co-spending patterns (multiple addresses used as inputs in one transaction) Change address reuse (leftover funds consistently returning to the same family) Timing and amount correlations (transactions close in time with similar values) Interaction fingerprints (repeated use of mixers, bridges, or exchanges) Clustering transforms thousands of unrelated addresses into logical entities, revealing control even after funds are fragmented. Multi-Layer Attribution Through Obfuscation Criminals obscure trails using mixers/tumblers, cross-chain bridges, decentralized exchanges, privacy protocols, flash-loan laundering, or automated smart-contract tumbling. Professional tracing tracks through these layers by analyzing residual signatures: entry/exit timing, fee-adjusted amounts, bridge metadata, and behavioral continuity across chains. This multi-layer approach is what separates basic explorers from advanced forensics. Endpoint Identification and Risk Scoring Analysts cross-reference clustered addresses against known exchange deposit patterns, historical wallet data, and compliance databases. High-confidence endpoints—centralized platforms requiring KYC/AML—are prioritized because they enable freeze requests. Each cluster receives a confidence or risk score based on laundering complexity and endpoint type. Forensic Report Production Findings are compiled into a detailed, court-admissible report that includes: Visualized transaction flow diagrams Clustered addresses with confidence levels Identified laundering techniques Probable endpoints and recommended next steps (freeze requests, law enforcement filings) These reports serve as credible evidence for exchange compliance teams, regulators, or authorities such as the FBI’s Internet Crime Complaint Center (IC3). Coordination and Follow-Up Support In viable cases, rapid submission of evidence can lead to asset freezes within hours or days. Investigators assist with coordination where appropriate, helping bridge the gap between forensic findings and actionable outcomes. Cryptera Chain Signals (CCS) integrates these steps into a cohesive, client-focused workflow. They emphasize transparency—honest feasibility assessments, no large upfront fees without evaluation, no guarantees—and prioritize victim education on prevention (hardware wallets, address verification, secure backups, monitoring) to reduce future risks. While professional tracing cannot reverse transactions or assure recovery, it provides critical visibility and evidence in an otherwise opaque environment. Outcomes range from partial freezes on regulated platforms to contributions to broader law enforcement seizures. Early action, strong evidence, and realistic expectations remain the most important factors. For more information on professional blockchain transaction tracing, forensic methodologies, and realistic guidance, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In 2026, blockchain investigation turns the transparency of public ledgers into a powerful tool for tracking stolen or lost funds. Firms like Cryptera Chain Signals (CCS) exemplify how disciplined, ethical forensics can deliver clarity, support intervention when possible, and help victims navigate the complexities of cryptocurrency crime with integrity and precision.

1 month, 3 weeks

Step-by-Step Process Used by Blockchain Investigators to Trace Crypto

by rogerstewer＠gmail.com

Blockchain investigators play a critical role in the fight against cryptocurrency crime. When funds are stolen through phishing, fake investment platforms, or wallet exploits, the public and immutable nature of blockchains like Bitcoin and Ethereum allows skilled professionals to follow the money trail. While no process can reverse transactions, systematic tracing can reveal where funds moved, identify laundering techniques, and sometimes locate intervention points such as regulated exchanges for asset freezes or law enforcement action. Cryptera Chain Signals (CCS), a firm with 28 years of digital investigation experience specializing in blockchain forensics, applies a rigorous, evidence-based methodology to these cases. Their approach emphasizes transparency and realistic outcomes, helping victims and institutions understand the movement of stolen assets without overpromising results. Here is the typical step-by-step process blockchain investigators follow when tracing cryptocurrency: Step 1: Secure Evidence Collection and Case Intake The process begins with gathering all available evidence while protecting the victim’s remaining assets. Investigators request transaction hashes (TXIDs), sending and receiving wallet addresses, timestamps, amounts, scam communications (screenshots, emails, chat logs), and any other relevant details. Importantly, legitimate firms never ask for private keys or seed phrases at this stage. This intake phase includes a secure, confidential assessment to determine feasibility. Cryptera Chain Signals (CCS) conducts this step with strict data-protection protocols to prevent secondary exploitation. Step 2: Initial Transaction Lookup and Graph Construction Once evidence is verified, investigators query public blockchain nodes and explorers to retrieve the complete transaction history linked to the TXID. They build a directed transaction graph showing the flow of funds from the victim’s wallet onward. This visual map reveals immediate outflows, splits into multiple smaller transactions, and consolidation points. Tools allow zooming into each hop, noting fees, timestamps, and any interactions with known services such as exchanges or bridges. At this stage, basic visibility is established before deeper analysis begins. Step 3: Address Clustering Using Behavioral Heuristics A core technique is clustering addresses likely controlled by the same entity. Investigators apply well-established heuristics: Co-spending patterns: addresses used together as inputs in a single transaction Change address reuse: leftover funds consistently returning to the same address family Timing and amount correlations: transactions occurring close together with similar values Behavioral fingerprints: repeated interaction styles with mixers, bridges, or decentralized exchanges These clusters transform thousands of seemingly unrelated addresses into logical groups, revealing control even after funds are split or moved multiple times. Cryptera Chain Signals (CCS) refines this step with proprietary algorithms that improve accuracy across different blockchains. Step 4: Tracking Through Obfuscation Layers Criminals deliberately complicate trails using mixers (tumblers), cross-chain bridges, decentralized exchanges (DEXs), privacy protocols, or flash-loan laundering. Investigators follow residual patterns: entry/exit timing, fee-adjusted amount preservation, bridge-specific metadata, and continuity of behavior across chains. Multi-layer attribution—tracking funds through multiple obfuscation steps—is essential here. Basic explorers lose visibility quickly, but advanced forensics can reconstruct paths that appear broken. This step often reveals whether funds have been converted to privacy coins or moved to non-transparent endpoints. Step 5: Endpoint Identification and Risk Scoring Investigators cross-reference clustered addresses against known exchange deposit patterns, historical wallet data, and compliance databases. High-confidence endpoints—centralized platforms enforcing KYC/AML rules—are flagged because they allow freeze requests. Each cluster receives a risk or confidence score based on laundering complexity and endpoint type. This scoring helps prioritize actionable leads. Step 6: Forensic Report Generation All findings are compiled into a detailed, court-admissible report. It includes: Visualized transaction graphs Clustered addresses with confidence levels Identified laundering techniques Probable endpoints and recommended next steps (exchange freeze requests, law enforcement submissions) The report serves as professional evidence for exchange compliance teams, regulators, or authorities such as the FBI’s Internet Crime Complaint Center (IC3). Step 7: Coordination and Follow-Up Investigators assist victims in submitting evidence for freezes or official reports. In some cases, rapid action within hours or days leads to asset freezes before further dispersal. Coordination with law enforcement or international partners can extend the process but increase the chance of broader seizures or restitution. Cryptera Chain Signals (CCS) integrates these steps into a cohesive workflow, using multi-layer attribution to deliver clear, actionable intelligence while maintaining strict ethical standards and realistic expectations. While blockchain investigation cannot guarantee recovery, it provides victims with clarity, evidence, and viable pathways forward. The entire process—from intake to reporting—typically spans days to weeks depending on case complexity, but early action is always the most important factor. For more information on blockchain tracing methods and realistic guidance, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. In summary, the step-by-step methodology used by blockchain investigators transforms the public transparency of distributed ledgers into a powerful investigative tool. Firms like Cryptera Chain Signals (CCS) demonstrate how disciplined forensic analysis can bring structure and insight to otherwise chaotic situations, helping victims and authorities navigate the complexities of cryptocurrency crime in 2026.

1 month, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig