Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

56 participants
6630 discussions

TRUSTED EXPERTS ONLINE RECOVERY SOLUTIONS//ALMIGHTY RECOVERY COIN

by Jeremy Thorgan

Almighty Cryptocurrency Recovery is a private investigation, asset recovery, and financial regulator. We specialize in instances involving recovery scams, cryptocurrency, fake investment schemes, and ethical hacking. We examine the factors influencing your score and are also experts in credit repair. removing criminal records, school grades, and jobs involving phone and social media hacking. Every piece of software required to carry out recoveries from beginning to end is available. The writers and offenders band together to establish a syndicate, so be wary of false reviews and testimonials on the internet.To get started, send an email to our support team at the address below as soon as you can. almightyrecoverycoin(a)mail.com and whatsapp +53 51 55 6969 Visit website; almightyrecoveryco.wixsite.com/almighty-recovery-co Stay Safe!

2 months, 3 weeks

5
4
10 0

Are your l0st bitc0ins gone forever? Here’s how you might be able to rec0ver them

by Ambrose MacQuoid

Many of us have f@ll€n for inves tment, pon zi, love, dating, even cryp to sc@m, it's really sad, few months ago I was a vict im of an invest ment sc@m , but today I got my fuπds back to my wall et , unbelievable right? I'll tell you h0w: Firstly, Believe in ghosttrackha ckers these guys are geπuine and geπius, I stumbled upon series of reviews from th€m, after months of l00sing my $20k worth of bitc0iπ thinking they were gone forever I sent them a m@il, €xplaining what happened and if there was any possibility, they said "nothing w€ can't haπdle" I sat back and in 48hrs they ask€d for my addr€ss and they r€c0v€r€d the full funds. I couldn't believe my eyes, I told them I'll go spr€ad the words to many others who have fall€n vi¢t|m. Goodluck ghosttrackhackers@ gmail . com

2 months, 4 weeks

[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

2 months, 4 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

3 months

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) >

3 months

I HAVE RETRIEVED MY LOCKED BTC 🥳

by Ambrose MacQuoid

3 months

[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>

3 months

[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

3 months

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.

3 months

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.

3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig