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.

This is where the BBC News style of article titles shines.

Take this article for example: NSA contractor Reality Winner admits leak. Its title not having capitals all over the place makes it immediately apparent that Reality Winner is someone's name without requiring any punctuation.

Precious few Slashdot articles don't have title case, but for this one it would have been great.

Full translation:

"15:46 (Eastern time): The alleged hostage situation at Ubisoft, which launched a major police operation in Montreal, turns out to have been a hoax, our sources say.

The investigation team is currently working on finding the one(s) responsible for the call. Many employees locked down in the building, for the most part hidden in conference rooms, did not know it was a false alarm."

Source: TVA Nouvelles (fr)

People who had SARS in 2002-2003 still have T cells that are cross-reactive to SARS-CoV-2 to this day (17 years later). SARS-CoV-2 antibodies are cross-reactive back to SARS as well, and it is expected that they may last as long. John Campbell explains, via Nature: SARS-CoV-2-specific T cell immunity in cases of COVID-19 and SARS, and uninfected controls.

The mutation rate of SARS-CoV-2 is very low compared to that of rhinoviruses, which cause the common cold, and influenza viruses. One major mutation has been observed: at position 614, RNA that used to encode aspartate now encodes glycine. It's not on the part of the spike that binds to the ACE2 receptor. Video for that one, with references in the description.

There was an article last year that pointed to possible viral origins of neurodegenerative diseases in general: Can the Flu and Other Viruses Cause Neurodegeneration?

A neurobiologist saw a duck acting strangely in a video, as if it had Parkinson's disease. In an experiment he then ran, he infected ducks with H5N1 and found that the virus had induced degeneration in the ducks' brains: inflammation and cell death.

It's hypothesised that influenza viruses can cause the same thing in humans. A literature review revealed a secondary outbreak of Parkinson's disease happening in 1940-1950, following the 1918-1919 H1N1 influenza pandemic.

As for the current pandemic, SARS-CoV-2, the virus that causes COVID-19, can infect the central nervous system, breach the blood-brain barrier and enter the brain. It can cause symptoms like failure to breathe spontaneously, as well as the anosmia (lack of sense of taste or smell) that has been seen in the absence of blocked sinuses.

So, COVID-19 could cause similar neurodegeneration in some time.

WhatsApp, owned by Facebook, is looking at a lending feature in India

Relatedly, China had been sanitizing cash to try to control the outbreak, even though a lot of payments in China are done over WeChat.

I can imagine someone sending SMS in bulk to get people to open Web pages containing WebKit exploits. At least make it a "Would you like to authenticate to example.com?" rather than adding to all those text-rendering-based crafted message attacks.

That is puzzling. I could not find any mention of this sort of 'surgery' in Google, even when typing the words "surgery appointment" in quotes or adding "uk".

I did, however, see that a surgery is simply a doctor's office in the UK. Ah, the English language...

Thanks!