@forest Its Toph tho

so its possible she could

@JourneymanGeek Oh I was pointing out the "WikiProject Disability" thing.

But I don't think she could beat the Fire Lord. After all, he can fly.

@forest Only with the comet.

IIRC

also, its Toph

Yeah but she's helpless if someone isn't on the ground.

And he could always fly, presumably (at least, Azula could even without the comet).

@forest You can also set your own strings for the prompt and response when you're wrong (as an env variable somewhere)

"lmao fail"

My sides.

Nice. I remember none of that conversation, nor why I was arguing over Toph being unstoppable. Even if she is

I really need to not get into arguements half asleep

+ I need to find time to wat ATLA and LOK again:D

@JourneymanGeek Now you know how I feel!

@forest well lack of sleep isn't fun

No it is not.

nitter.net/TadeuszGiczan/status/1556236025940385793

> One of the most bizarre things I've seen in a while. A new ad in the Moscow underground warning Russians against using VPNs. The caption reads: "Attention! Forewarned is forearmed!"

(hotlink from Nitter)

Now now

Stealing people's data is the duty of state apparatus

we can't let just any private organisation snoop on our data on false pretenses of security

@forest yeah, only the elected officials of your country should have the right and capability to invade the privacy of their citizens...

My elected officials cant even figure out how to keep their email secure ... im not sure they know what VPNs are

my elected officials post in-progress investigation data on facebook

they know who is going to be raided and say "I have a feeling that X home may be raided any time..."

@CaffeineAddiction Well, they probably do know who to contact to get access to your email though

@nobody no, im refering to the various elected officials who keep having their emails leaked

@nobody who was nobody first you or Jaqen H'ghar?

@ThoriumBR that's not suspicious at all...

I'm not sure Hanlon's razor applies

even less if the raided would be an ex minister and the leaker was the president...

who happens to have top level intelligence data from the secret service

They need to learn how to leak properly

got the full story: the president called the guy, told him he had a "feeling," and the guy told his daughter over the phone (that was tapped)...

seclists.org/oss-sec/2022/q3/116

CVE-2022-2585 - Linux kernel POSIX CPU timer UAF

It was discovered that when exec'ing from a non-leader thread, armed POSIX
CPU timers would be left on a list but freed, leading to a use-after-free.

An independent security researcher working with SSD Secure Disclosure
discovered that this vulnerability could be exploited for Local Privilege
Escalation.

This bug was introduced by commit 55e8c8eb2c7b ("posix-cpu-timers: Store a
reference to a pid not a task"), which is present since v5.7-rc1.

Simple, quick and dirty mitigation (as a kernel livepatch) if anyone cares:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/livepatch.h>

static int disable_posix_cpu_timer_create(void)
{
	dump_stack();
	return -ENOSYS;
}

static struct klp_func funcs[] = {
	{
		.old_name = "posix_cpu_timer_create",
		.new_func = disable_posix_cpu_timer_create,
	}, { }
};

static struct klp_object objs[] = {
	{
		.funcs = funcs,
	}, { }
};

static struct klp_patch patch = {
	.mod = THIS_MODULE,
	.objs = objs,
};

static int livepatch_init(void)
{
	return klp_enable_patch(&patch);

It just disables the creation of new POSIX timers. You can see if your system is using any with cat /proc/[0-9]*/timers.

Actually, you can probably get away with mitigating this without a kernel patch via RLIMIT_SIGPENDING, but stuff would break.

At least according to timer_create(2)

This is the fix to upstream:

diff --git a/fs/exec.c b/fs/exec.c
index 778123259e42..1c6b477dad69 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1301,6 +1301,9 @@ int begin_new_exec(struct linux_binprm * bprm)
 	bprm->mm = NULL;

 #ifdef CONFIG_POSIX_TIMERS
+	spin_lock_irq(&me->sighand->siglock);
+	posix_cpu_timers_exit(me);
+	spin_unlock_irq(&me->sighand->siglock);
 	exit_itimers(me);
 	flush_itimer_signals();
 #endif