Remember in C, sizeof(int) = sizeof(long) = sizeof(long long)

Not necessarily true; it should really be sizeof(int) <= sizeof(long) <= sizeof(long long). All that's required by the C standard is that short and int can represent at least 16-bit, long can represent at least 32-bit and long long can represent at least 64-bit. Since short has been the universally accepted 16-bit quantity for a while, int doesn't need to be 16-bit anymore, but it doesn't need to match long either.

On 64-bit Unix/Linux, the most common way to size int, long and long long on 64-bit is called LP64 (long and pointers 64-bit), as that sizing has int as 32-bit, but long, long long and pointers as 64-bit. 64-bit Windows uses LLP64 (long long and pointers 64-bit), so it has int as 32-bit, long as 32-bit, but long long and pointers as 64-bit.

Thanks for adding this. I didn't actually know what 64-bit kernels did to get their own mappings in kernel mode after being entered through a syscall from a 32-bit application. It makes sense that a syscall would return the CPU to 64-bit mode right away and the virtual address space of a process could go all the way to FFFF_FFFF, if supported. Maybe 7FFF_FFFF if not.

On many compilers, you can always declare a uint64_t or the equivalent type name in some language, and the basic operations work as intended even on 32-bit systems using multiword arithmetic: subtraction on halves with borrow, addition on halves with carry, long multiplication, long division (often with a subroutine), split bitwise operations, propagated shifts and so on. It's not always implemented, though, especially on 16-bit microcontrollers for which 32-bit is already a lot.

Yeah, and then a separate system call for "time64" would have to return the proper 64-bit value, in the same style as lseek64.

To anyone wondering what this ABI is about, let's use 3 examples: the system call behind the time function, the one behind lseek64, and the one behind mmap.

On a pure 32-bit system, it's simple: time_t is 32-bit, so you can only get time from -2147483648 to 2147483647, which is from 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC (that's the 32-bit timepocalypse that's coming up); lseek64 is on the stack as two 32-bit halves; and mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory. Anything that would make a process go over that limit returns an error.

On a pure 64-bit system, it's also simple: time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; and mmap returns 64-bit addresses, currently from 0000_0000_0000 to FFFF_FFFF_FFFF with sign extension.

This x32 system is a 64-bit system with a 32-bit virtual address space. Like in 64-bit, your time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; but mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory, just like on 32-bit.

This necessitates a new kernel system call interface to get the parameters from 64-bit registers properly and enforce the 32-bit limit for addresses only. And in return, you can keep your virtual pointers shorter and use less memory to store those. Depending on how much data and pointers a process holds, that can save anywhere from practically nothing to about 20% RAM.

Few people are using this x32 ABI (though at least one user on Phoronix reports they're using x32 right now on an old laptop with 4 GB of RAM) because most processes are using either the pure 32-bit ABI (with 32-bit time_t, lseek64 on the stack and mmap) or the pure 64-bit ABI (with 64-bit time_t, lseek64 in a register and mmap). Multilib, Wine/Proton, etc. would switch between those two rather than x32 and will stay compatible even if this ABI is removed.

It seems not every distribution ships with the vulnerable module, built-in or loadable, either. That could be another factor, too.

On my Ubuntu 26.04 host, all patched up to yesterday, lsmod as root shows only algif_hash and algif_skcipher, not algif_aead.

Immutable distributions, in Linux parlance, run on a read-only root filesystem that is swapped for the next boot if there are any updates. Usually, you can use one or more snapshots to roll back to the (or a) previous version if an update fails.

What this attack is doing is not helped by immutability under that definition: it's entirely in memory and works only as long as the target executable is in memory. It first reads the target executable into the disk cache and asks a specific kernel module to encrypt it with a splice() system call to avoid copying the disk cache page elsewhere. Except that specific kernel module overwrites 4 bytes past the end of its buffer, so if you ask for a 32-byte buffer starting at /usr/bin/su byte 696, you can write bytes 728-731, directly in the system's disk cache. And then you can just keep looping to write any arbitrary string of multiples of 4 bytes into what the kernel considers to be a current copy of the latest data on disk for that file, up to that file's size. It's also not marked as dirty, so it never gets written to disk and only gets evicted with normal disk cache operations.

Now, while the attack only works as long as the targetted executable is in the disk cache, that's not much of a problem in practice, because the disk cache often survives the few microseconds needed to set up the required system calls. And once you finally execute the binary as setuid root, Linux consults the disk cache, finds it has a version already and runs it. But you now have a root shell, all without a single disk write, and can now begin to remount filesystems read-write to establish persistence.

Answering a sibling comment, write-xor-execute (W^X) memory doesn't give any protection here either, because a kernel module is performing the write. Write protection on executable pages is provided by the CPU operating in user mode.

Disney is already licensing their content to OpenAI.

https://www.wsj.com/business/m...

This isn't an AI vs Art showdown. This is just a licensing deal shakedown.

For someone who doesn't develop apps for Apple devices, can someone explain how Apple can revoke an app from a third party store? Is this a revoking of developer license keys or something?

Apex Legends uses the Source engine, which has had several RCE exploits over the years.

A nice writeup here: https://www.reddit.com/r/Compe...

Pineapple:

https://github.com/pineappleEA...

Is a fork of Yuzu's patreon-locked dev branches.

Considering so many captchas are being used to feed ML datasets, it's very not surprising AI trained on those datasets can now solve them effortlessly...

Directly to far cheaper VR platforms which already have spatial movie viewing capabilities.

I bet it'll show up in a VRChat movie world within a week of release.

So if someone passes away their YouTube videos will eventually disappear. More digital history being erased.

BLE tags use a compatible phone to report their location back to a central service, but unless you had an Apple Airtag [or AirTag compatible], your tags would only be picked up by other phones with the Tile app installed. This is of course fine if you're just keeping track of your keys and other household items, but Apple Airtags are really popular to slip into luggage, packages, and other valuables as a cheaper [and far smaller] alternative to SMS/GPS trackers.

These new tags use a component in Google Play Services [installed on every Android phone with the Google Play store], instead of the Tile app, making them, at least on paper, as good or better than Airtags, and far more reliable than Tile tags for remote tracking.

Instead of waiting for a phone with the Tile app installed to come by, now any android phone can pick up and report these tags back.

There's the whole problem of privacy, security, etc involving any BLE tag, but that's a whole different can of worms..