Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
6318 discussions

Cross-Chain Bridge Exploits: Following the Money After DeFi Hacks

by luisannete22＠gmail.com

DeFi bridges are frequent hack targets, with billions stolen historically—funds often traceable despite complexity. 1. The Exploit Hackers exploit vulnerabilities in bridge contracts. Drain liquidity pools or mint unauthorized tokens. 2. Immediate Movement Stolen assets bridged back or swapped. Split across wallets. Laundered via mixers/DEXs. 3. Laundering Path Funds hop chains, convert to stablecoins, then to exchanges. 4. Cash-Out Attempts Many hit centralized platforms eventually. Where Tracing Can Intervene Bridges leave detailed trails. Multi-Chain Analysis: Track across ecosystems. Taint Tracking: Flag tainted funds at exchanges. Community/DAO Freezes: Some protocols freeze. Cryptera Chain Signals (CCS) provides expert multi-chain forensics for hack victims and projects, identifying paths and aiding freezes/recoveries. For DeFi hack or exploit recovery support, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. Use audited bridges, diversify, and stay informed on security alerts.

1 month, 1 week

Title: Lost Wallet Access: Recovering Funds Without the Seed Phrase

by rogerstewer＠gmail.com

Not all losses are scams—many stem from forgotten passwords, damaged hardware, or partial seed phrases. 1. Common Scenarios Forgotten wallet PIN/password. Partial seed phrase remembered. Corrupted wallet files from old devices. 2. The Challenge Without full access, funds appear locked forever. Brute-forcing full seeds is impractical. 3. Recovery Methods Experts use: Targeted analysis on wallet files. Derivation path testing. Advanced password cracking (ethical, non-brute-force). 4. Secure Migration Once accessed, migrate to new secure setups (multisig, hardware). Where Tracing Can Intervene This isn't tracing stolen funds it's forensic wallet recovery. Firms like Cryptera Chain Signals (CCS) offer specialized lost wallet recovery using secure, non-custodial methods no seed required upfront. They've assisted in numerous 2026 cases with high success when partial info exists. Visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com for wallet recovery consultations. Always back up seeds securely and test restores periodically.

1 month, 1 week

Fake Investment Platforms: Anatomy of a Rug Pull Scam

by rogerstewer＠gmail.com

Scammers launch bogus trading/investment sites promising guaranteed returns, then vanish with deposits. 1. Luring Victims Ads on social media or Telegram promote "AI trading bots" or "exclusive funds." Victims sign up and deposit crypto via provided wallets. 2. Controlled Environment Fake interfaces show rising balances to encourage more investment. Withdrawals blocked with excuses ("taxes," "verification"). 3. The Exit Scam When enough funds accumulate: Site goes offline. Funds transferred out rapidly. 4. Obfuscation & Cash-Out Similar to other scams: splitting, mixing, chain-hopping, then exchange fiat off-ramps. Where Tracing Can Intervene Many platforms use traceable patterns (e.g., repeated deposit addresses). Early Alerts: Monitor for sudden outflows. Clustering: Group related wallets to reveal operators. Legal Leverage: Evidence supports civil or criminal action. Cryptera Chain Signals (CCS) analyzes these platforms' transaction histories, traces to exchanges, and supports recovery efforts with detailed reports and partnerships. For help with fake investment scams, head to https://www.crypterachainsignals.com/ or contact info(a)crypterachainsignals.com. Research platforms thoroughly check audits, team transparency, and community feedback.

1 month, 1 week

Phishing Attacks on Wallets: How Hackers Drain Your Crypto in Minutes

by luisannete22＠gmail.com

Phishing remains one of the most common ways scammers steal crypto—often through fake websites, malicious emails, or compromised links. 1. The Bait Victims receive urgent messages: "Your wallet is at risk—verify here" or fake airdrop/claim links from trusted projects. Clicking leads to spoofed sites mimicking MetaMask, Ledger, or exchanges. Users enter seed phrases, private keys, or approve malicious transactions. 2. Instant Drainage Once credentials or approvals are obtained: Scammers sweep funds to their address. Drainers auto-transfer everything (tokens, NFTs). 3. Rapid Laundering Funds move fast: Split and peeled into smaller amounts. Bridged to other chains. Mixed or swapped to break links. 4. Cash-Out Deposited to exchanges, often KYC-bypassed via layered accounts. Where Tracing Can Intervene Phishing thefts leave clear on-chain trails if reported quickly. Real-Time Monitoring: Track outgoing sweeps and downstream hops. Pattern Recognition: Identify common drainer signatures or exchange deposit clusters. Freeze Potential: Exchanges can halt if illicit origin proven early. Firms like Cryptera Chain Signals (CCS) excel at rapid phishing investigations, using AI-powered tracing to follow funds across chains and facilitate exchange freezes. In 2026, they've helped recover significant portions in time-sensitive cases. Visit https://www.crypterachainsignals.com/ for crypto scam recovery support, or email info(a)crypterachainsignals.com to get started. Protect yourself with hardware wallets and bookmark verification never enter seeds online.

1 month, 1 week

Romance Scams in Crypto: The Slow-Burn Theft Exposed Cryptera Chain Signals

by luisannete22＠gmail.com

The rise of cryptocurrency has amplified romance scams, where fraudsters build emotional trust over weeks or months before requesting funds. These "pig butchering" operations are particularly devastating because victims often send large sums willingly. 1. Building False Trust Scammers create fake profiles on dating apps or social media, posing as successful investors or entrepreneurs. They share "proof" of crypto gains to lure victims into trading platforms they control. Conversations escalate to "exclusive opportunities" like private presales or high-yield pools. Victims are guided to deposit crypto into wallets or fake exchanges. 2. The Extraction Phase Once trust is established, scammers pressure victims to invest more, promising quick returns. Funds go to scammer-controlled addresses. Fake dashboards show fabricated profits to encourage further deposits. 3. Obfuscation Tactics After extraction, funds are quickly moved: Split across dozens of wallets. Hopped through bridges to privacy-focused chains. Mixed via services or converted to privacy coins like Monero. 4. Final Laundering Cleaned funds hit centralized exchanges for fiat withdrawal, often via mule accounts. Recovery window closes fast once converted. Where Tracing Can Intervene Quick action is essential in romance scams due to the emotional manipulation factor. Immediate Reporting: Preserve all chat logs, transaction IDs, and screenshots. Blockchain Analysis: Trace patterns like repeated small deposits or specific bridge usage. Exchange Cooperation: Provide evidence to freeze incoming deposits. Blockchain investigation firms like Cryptera Chain Signals (CCS) specialize in tracing romance scam funds through complex paths, identifying endpoints, and assisting with freeze requests. With advanced forensics and a track record of hundreds of recoveries (including 2026 cases), they help victims map flows and pursue actionable steps before full laundering. For professional help with romance scam or crypto fraud recovery, visit the Cryptera Chain Signals website at https://www.crypterachainsignals.com/. Contact them directly via email at info(a)crypterachainsignals.com or through their secure inquiry form. Emotional scams hurt deeply, but blockchain transparency offers hope—act swiftly and seek expert help.

1 month, 1 week

[PATCH v2 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch introduces a new heap driver to expose DT non‑reusable "shared-dma-pool" coherent regions as dma-buf heaps, so userspace can allocate buffers from each reserved, named region. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma-buf: heaps: Add Coherent heap to dmabuf heaps dma: coherent: register to coherent heap dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 429 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 27 ++- include/linux/dma-heap.h | 16 ++ include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 642 insertions(+), 27 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 month, 1 week

Re: [PATCH v2 3/6] of_reserved_mem: add a helper for rmem device_init op

by Albert Esteve

On Tue, Mar 3, 2026 at 2:13 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > On Tue, Mar 03, 2026 at 01:33:46PM +0100, Albert Esteve wrote: > > Add a helper function wrapping internal reserved memory > > device_init call and expose it externally. > > > > Use the new helper function within of_reserved_mem_device_init_by_idx(). > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/of/of_reserved_mem.c | 27 +++++++++++++++++++++++---- > > include/linux/of_reserved_mem.h | 8 ++++++++ > > 2 files changed, 31 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > > index 1fd28f8056108..3a350bef8f11e 100644 > > --- a/drivers/of/of_reserved_mem.c > > +++ b/drivers/of/of_reserved_mem.c > > @@ -605,6 +605,28 @@ struct rmem_assigned_device { > > static LIST_HEAD(of_rmem_assigned_device_list); > > static DEFINE_MUTEX(of_rmem_assigned_device_mutex); > > > > +/** > > + * of_reserved_mem_device_init_with_mem() - assign reserved memory region to > > + * given device > > + * @dev: Pointer to the device to configure > > + * @rmem: Reserved memory region to assign > > + * > > + * This function assigns respective DMA-mapping operations based on the > > + * reserved memory region already provided in @rmem to the @dev device, > > + * without walking DT nodes. > > + * > > + * Returns error code or zero on success. > > + */ > > +int of_reserved_mem_device_init_with_mem(struct device *dev, > > + struct reserved_mem *rmem) > > +{ > > + if (!dev || !rmem || !rmem->ops || !rmem->ops->device_init) > > + return -EINVAL; > > + > > + return rmem->ops->device_init(rmem, dev); > > +} > > +EXPORT_SYMBOL_GPL(of_reserved_mem_device_init_with_mem); > > + > > /** > > * of_reserved_mem_device_init_by_idx() - assign reserved memory region to > > * given device > > @@ -643,14 +665,11 @@ int of_reserved_mem_device_init_by_idx(struct device *dev, > > rmem = of_reserved_mem_lookup(target); > > of_node_put(target); > > > > - if (!rmem || !rmem->ops || !rmem->ops->device_init) > > - return -EINVAL; > > - > > rd = kmalloc_obj(struct rmem_assigned_device); > > if (!rd) > > return -ENOMEM; > > > > - ret = rmem->ops->device_init(rmem, dev); > > + ret = of_reserved_mem_device_init_with_mem(dev, rmem); > > if (ret == 0) { > > rd->dev = dev; > > rd->rmem = rmem; > > I think you need to take the allocation of rd, and everything below. > Otherwise, your device, despite being attechd, wouldn't be listed > anywhere. True, I did not pay enough attention to that part. I will fix it in the next version. > > Maxime

1 month, 1 week

Primatz Guard Recovery: Addressing Romance Scams Linked to Digital Assets

by phillipsmathew895＠gmail.com

Romance scams begin with emotional trust-building, often through social media or messaging apps. Scammers later introduce supposed crypto or digital asset investment opportunities and persuade victims to transfer funds. Once payments are made, communication fades and funds become difficult to retrieve. Primatz Guard Recovery supports victims by reviewing financial trails, identifying scam tactics, and providing guidance on recovery steps with no consultation charges. Staying cautious with online relationships and avoiding financial commitments based on emotional pressure remains essential. Homepage: Primatz Guard Recovery

1 month, 1 week

How To Recover Lost Funds From Online Investment Scam - Reach Out To Betafort Recovery

by glennkael8＠gmail.com

With professionalism and integrity, Betafort Recovery assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

1 month, 1 week

Re: [PATCH v2 4/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Albert Esteve

On Tue, Mar 3, 2026 at 2:20 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi, > > On Tue, Mar 03, 2026 at 01:33:47PM +0100, Albert Esteve wrote: > > Add a dma-buf heap for DT coherent reserved-memory > > (i.e., 'shared-dma-pool' without 'reusable' property), > > exposing one heap per region for userspace buffers. > > > > The heap binds the heap device to each memory region so > > coherent allocations use the correct dev->dma_mem, and > > it defers registration until module_init when normal > > allocators are available. > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/dma-buf/dma-heap.c | 4 +- > > drivers/dma-buf/heaps/Kconfig | 9 + > > drivers/dma-buf/heaps/Makefile | 1 + > > drivers/dma-buf/heaps/coherent_heap.c | 426 ++++++++++++++++++++++++++++++++++ > > include/linux/dma-heap.h | 11 + > > include/linux/dma-map-ops.h | 7 + > > 6 files changed, 456 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > index 88189d4e48561..ba87e5ac16ae2 100644 > > --- a/drivers/dma-buf/dma-heap.c > > +++ b/drivers/dma-buf/dma-heap.c > > @@ -390,8 +390,8 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > heap = dma_heap_create(exp_info); > > if (IS_ERR(heap)) { > > - pr_err("dma_heap: failed to create heap (%d)\n", PTR_ERR(heap)); > > - return PTR_ERR(heap); > > + pr_err("dma_heap: failed to create heap (%ld)\n", PTR_ERR(heap)); > > + return ERR_CAST(heap); > > This looks unrelated and should possibly be squashed into the previous > patch that introduces dma_heap_create()? > > > +static int coherent_heap_init_dma_mask(struct device *dev) > > +{ > > + int ret; > > + > > + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); > > + if (!ret) > > + return 0; > > + > > + /* Fallback to 32-bit DMA mask */ > > + return dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > > +} > > Why do you need to mess with the DMA mask? I'd expect that device to be > able to access everything. When I tested I was getting: "reserved memory is beyond device's set DMA address range", so I tested if it was fixed with dma_coerce_mask_and_coherent() and/or dma_set_mask_coherent(). I did not debug the value of coherent_dma_mask, but given the error I assume it was not set properly? Ultimately, using the 64 bit mask fixed it, and I added a 32-bit fallback to ensure support for 32-bit systems. > > > +static int __coherent_heap_register(struct reserved_mem *rmem) > > +{ > > + struct dma_heap_export_info exp_info; > > + struct coherent_heap *coh_heap; > > + struct device *heap_dev; > > + int ret; > > + > > + if (!rmem || !rmem->name) > > + return -EINVAL; > > + > > + coh_heap = kzalloc_obj(*coh_heap); > > + if (!coh_heap) > > + return -ENOMEM; > > + > > + coh_heap->rmem = rmem; > > + coh_heap->name = kstrdup(rmem->name, GFP_KERNEL); > > + if (!coh_heap->name) { > > + ret = -ENOMEM; > > + goto free_coherent_heap; > > + } > > + > > + exp_info.name = coh_heap->name; > > + exp_info.ops = &coherent_heap_ops; > > + exp_info.priv = coh_heap; > > + > > + coh_heap->heap = dma_heap_create(&exp_info); > > + if (IS_ERR(coh_heap->heap)) { > > + ret = PTR_ERR(coh_heap->heap); > > + goto free_name; > > + } > > + > > + heap_dev = dma_heap_get_dev(coh_heap->heap); > > + ret = coherent_heap_init_dma_mask(heap_dev); > > + if (ret) { > > + pr_err("coherent_heap: failed to set DMA mask (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = of_reserved_mem_device_init_with_mem(heap_dev, rmem); > > + if (ret) { > > + pr_err("coherent_heap: failed to initialize memory (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = dma_heap_register(coh_heap->heap); > > + if (ret) { > > + pr_err("coherent_heap: failed to register heap (%d)\n", ret); > > + goto destroy_heap; > > + } > > I guess it's more of a comment about your previous patch, but it's not > clear to me why you needed to split dma_heap_add into dma_heap_create / > _register. Can you expand a bit? So first I tried to just use dma_heap_add() and then use the heap_dev afterward to call of_reserved_mem_device_init_with_mem(), but if that call failed, the error path required some kind dma_heap_remove() function as the heap was already registered by then. In the CMA heap for example, dma_heap_add() is invoked at the end of the `init` function. Therefore, you do not have this issue, if it failed it means the heap was not added and you just need to clean everything else. However, performing a remove() does not sound like something that can be done safely. I've spent some time thinking on alternatives, but splitting felt the best pattern. This way I can: 1. Create the device 2. Call of_reserved_mem_device_init_with_mem 3. Register the heap This places registration at the end, making every error path and cleanup easy to handle. Also, the `dma_heap_add()` code already seemed to handle these two parts/phases implicitly with device_create(), so splitting felt architecturally sound. > > > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > > index 1b0ea43ba66c3..77e6cb66ffce1 100644 > > --- a/include/linux/dma-heap.h > > +++ b/include/linux/dma-heap.h > > @@ -9,10 +9,12 @@ > > #ifndef _DMA_HEAPS_H > > #define _DMA_HEAPS_H > > > > +#include <linux/errno.h> > > #include <linux/types.h> > > > > struct dma_heap; > > struct device; > > +struct reserved_mem; > > > > /** > > * struct dma_heap_ops - ops to operate on a given heap > > @@ -53,4 +55,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info); > > > > extern bool mem_accounting; > > > > +#if IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT) > > +int dma_heap_coherent_register(struct reserved_mem *rmem); > > +#else > > +static inline int dma_heap_coherent_register(struct reserved_mem *rmem) > > +{ > > + return -EOPNOTSUPP; > > +} > > +#endif > > + > > #endif /* _DMA_HEAPS_H */ > > Do you still need that now that you switched to an iterator-like > function? > > > diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h > > index 60b63756df821..c87e5e44e5383 100644 > > --- a/include/linux/dma-map-ops.h > > +++ b/include/linux/dma-map-ops.h > > @@ -12,6 +12,7 @@ > > > > struct cma; > > struct iommu_ops; > > +struct reserved_mem; > > > > struct dma_map_ops { > > void *(*alloc)(struct device *dev, size_t size, > > @@ -161,6 +162,7 @@ int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size, > > int dma_release_from_dev_coherent(struct device *dev, int order, void *vaddr); > > int dma_mmap_from_dev_coherent(struct device *dev, struct vm_area_struct *vma, > > void *cpu_addr, size_t size, int *ret); > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx); > > #else > > static inline int dma_declare_coherent_memory(struct device *dev, > > phys_addr_t phys_addr, dma_addr_t device_addr, size_t size) > > @@ -172,6 +174,11 @@ static inline int dma_declare_coherent_memory(struct device *dev, > > #define dma_release_from_dev_coherent(dev, order, vaddr) (0) > > #define dma_mmap_from_dev_coherent(dev, vma, vaddr, order, ret) (0) > > static inline void dma_release_coherent_memory(struct device *dev) { } > > +static inline > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx) > > +{ > > + return NULL; > > +} > > #endif /* CONFIG_DMA_DECLARE_COHERENT */ > > > > #ifdef CONFIG_DMA_GLOBAL_POOL > > To preserve bisectability, you shouldn't do it that way. Introduce this > function into a preliminary patch, and then use it in this one. > > Maxime

1 month, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig