Last year we announced a partnership with Epic Games to bring Unity to Fortnite - and today, we want to show you where we are.

This is Fantasy Kingdom: a Unity game rendering natively inside @UnrealEngine. Physics, lighting, input: all synchronized between engines🎮👇

🔗 Want to try it out for yourself? Fill out our interest form to be considered for early access: https://on.unity.com/Fortnite_InterestForm

Introducing Happy Oyster, the groundbreaking real-time world model from @HappyOysterAI, live today on Reactor!

Explore any world you can imagine, or take the director's chair and shape the story as it happens.

Available via API.

Try it now: http://reactor.inc/happy-oyster

Use after free in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted video file. (Chromium security severity: Medium)

Use after free in Canvas in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium)

  cacheData := cacheMap.Get(key)
  if cacheData == nil {
    cacheData = &BinanceDepthCachedData{
      Coin:       key,
      LastUsedAt: time.Now(),
    }
    cacheMap.Add(key, cacheData)
  }

Goroutine A: Get → nil
Goroutine B: Get → nil
Goroutine A: Add(objectA)
Goroutine B: Add(objectB)

  mut := hlInfoReqMutexes.GetOrCreateDefault(mutKey)
  mut.Lock()
  defer mut.Unlock()

v := cache.Get(key)
if v == nil {
    v = parseConfig(key)
    cache.Add(key, v)
}

A creates objectA and continues using it
B creates objectB and stores it
A stores objectA—or B remains the winner

lock := locks.Get(accountID)
if lock == nil {
    lock = &sync.Mutex{}
    locks.Add(accountID, lock)
}

lock.Lock()
defer lock.Unlock()
processWithdrawal(accountID)

is a cryptographic hash function that is:
- Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2.
- Secure, unlike MD5 and SHA-1. And secure against length extension, unlike SHA-2.
- Highly parallelizable across any number of threads and SIMD lanes, because it's a Merkle tree on the inside.
- Capable of verified streaming and incremental updates, again because it's a Merkle tree.
- A PRF, MAC, KDF, and XOF, as well as a regular hash.
- One algorithm with no variants, which is fast on x86-64 and also on smaller architectures.

Since December 2025, Rust compiler workloads improved by ~5.6% overall ( ~2.9% excluding rustdoc).

Improvements:
- rustdoc: ~38% mean speedup
- Clippy: 10–30% faster by skipping useless lint calls
- New trait solver benchmark: 27s → under 1s
- Smaller AST nodes and fewer memory copies improved cache use
- Incremental compilation received many smaller optimizations

TL;DR: the Linux kernel briefly forgot a memory write. Not really a ripgrep bug, and probably not a musl bug.

During a massive, highly parallel directory search, one thread allocated a page and wrote musl allocator metadata to it. At the same moment another thread was unmapping memory. A Linux 7.0 kernel race between a fresh page fault and the munmap TLB shootdown replaced that page’s backing. Roughly ten CPU instructions later, the first thread reread its own value and got zero instead. Musl correctly noticed impossible/corrupt allocator metadata and crashed. [1]

The investigator reproduced it with about 1.8 million files / 20 GiB, instrumented musl, matched the disappearing write to the core dump, and found it tracks kernel 7.0.12, not the CPU or ripgrep itself. A Linux 7.0 page-table-reclaim change is the prime suspect, though the precise offending commit isn’t proven yet—and the race was reportedly still present in mainline during the analysis. [1]

So, in technical terms: absolutely cursed kernel VM race, exposed by ripgrep doing allocator violence at scale.

Citations
[1] GitHub - dfoxfranke/ripgrep-3494-analysis: Analysis of one crazy segfault in ripgrep · GitHub