« first day (4254 days earlier)      last day (107 days later) » 

1:49 AM
@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).
 
 
2 hours later…
3:43 AM
@forest You can also set your own strings for the prompt and response when you're wrong (as an env variable somewhere)
user image
2
 
 
4 hours later…
7:18 AM
"lmao fail"
My sides.
 
 
1 hour later…
8:32 AM
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
 
9:04 AM
@JourneymanGeek Now you know how I feel!
 
@forest well lack of sleep isn't fun
 
No it is not.
> 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
 
 
7 hours later…
4:21 PM
security.stackexchange.com/questions/150540/… is catching up w/ the question that it "dupes"
 
5:16 PM
@forest yeah, only the elected officials of your country should have the right and capability to invade the privacy of their citizens...
 
5:40 PM
My elected officials cant even figure out how to keep their email secure ... im not sure they know what VPNs are
 
5:54 PM
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..."
 
6:37 PM
@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
 
6:51 PM
@nobody who was nobody first you or Jaqen H'ghar?
 
 
1 hour later…
8:05 PM
@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)...
 
 
1 hour later…
9:12 PM
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.
 
9:31 PM
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.
 
9:57 PM
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)
 
10:34 PM
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
 

« first day (4254 days earlier)      last day (107 days later) »