WEBVTT

1
00:00:03.200 --> 00:00:05.680
Good morning, and welcome to Decrypted.

2
00:00:05.680 --> 00:00:12.160
I'm Belinder. It's Sunday, the first of November, twenty twenty-six, and this is the morning edition.

3
00:00:12.160 --> 00:00:17.120
A Linux kernel flaw an AI model turned into remote root.

4
00:00:17.120 --> 00:00:24.520
Many UK organisations run Linux kernels with a bug that Anthropic's researchers have shown can be turned i

5
00:00:24.520 --> 00:00:28.880
nto remote control of a server, with no password and no click.

6
00:00:28.880 --> 00:00:35.280
The flaw is C V E twenty twenty-six, nine eight four three two, the public reference number for this vulnerab

7
00:00:35.280 --> 00:00:41.360
ility, and when the vendors last updated on Friday the main distributions were still shipping fixes.

8
00:00:41.360 --> 00:00:47.893
There is no confirmed exploitation in the wild, and Sisa, America's national cyber security agency, had not l

9
00:00:47.893 --> 00:00:50.560
isted it. That gap is the useful part.

10
00:00:50.560 --> 00:00:54.000
So, how does the bug actually work?

11
00:00:54.000 --> 00:00:58.520
It sits in the kernel's code for the opening exchange of a network connection.

12
00:00:58.520 --> 00:01:03.680
While a connection is being set up, the kernel keeps a small note of the options the caller sent.

13
00:01:03.680 --> 00:01:10.200
The error is a handover. Ownership of that note passes to the finished connection, while another processor co

14
00:01:10.200 --> 00:01:11.720
re may still be reading it.

15
00:01:11.720 --> 00:01:17.840
Picture a hotel porter handing your luggage ticket to a guest while the concierge is still reading it aloud.

16
00:01:17.840 --> 00:01:21.760
Shred the ticket mid-sentence and the concierge reads rubbish.

17
00:01:21.760 --> 00:01:24.880
In kernel terms, that's a use-after-free.

18
00:01:24.880 --> 00:01:27.200
Memory is released, then used anyway.

19
00:01:27.200 --> 00:01:34.800
What did Anthropic show? Anthropic's Frontier Red Team said an AI model wrote the exploit.

20
00:01:34.800 --> 00:01:41.600
Against a server listening for M P T C P, a variant of T C P that spreads one connection over several routes,

21
00:01:41.600 --> 00:01:45.040
it gave an attacker a root shell with no credentials.

22
00:01:45.040 --> 00:01:51.560
It worked in two stages. First it leaked a kernel address, to defeat the randomisation that hides where the k

23
00:01:51.560 --> 00:01:55.680
ernel lives. Then it overwrote a pointer to run a command.

24
00:01:55.680 --> 00:02:02.000
A lost race only fails the handshake rather than crashing the machine, so an attacker can simply retry.

25
00:02:02.000 --> 00:02:07.320
In the proof of concept, the leak took 48 minutes and the command another five.

26
00:02:07.320 --> 00:02:12.000
Slow, but patient machines do not mind waiting.

27
00:02:12.000 --> 00:02:14.800
So what can defenders do right now?

28
00:02:14.800 --> 00:02:18.700
Patching was uneven. Ubuntu rates the flaw High with a 9.

29
00:02:18.700 --> 00:02:22.352
8 score, and listed 22.04, 24.

30
00:02:22.352 --> 00:02:27.440
04 and 26.04 as vulnerable with work in progress.

31
00:02:27.440 --> 00:02:33.320
C I Q, which supports Rocky Linux, said it had no patched kernel yet for its enterprise builds.

32
00:02:33.320 --> 00:02:40.160
Its interim advice is an nftables rule dropping IPv4 T C P packets that carry I P options.

33
00:02:40.160 --> 00:02:44.040
It's not a complete fix, and it can block legitimate traffic.

34
00:02:44.040 --> 00:02:50.640
Switching off M P T C P alone isn't enough either, because plain T C P stayed reachable in its testing.

35
00:02:50.640 --> 00:02:53.560
A defender will probably see very little.

36
00:02:53.560 --> 00:02:55.640
So start with an inventory.

37
00:02:55.640 --> 00:03:02.480
Which internet-facing Linux machines, including cloud images, run an affected kernel, and who owns each one?

38
00:03:02.480 --> 00:03:06.587
Then ask your distributor daily until the kernel update lands.

39
00:03:06.587 --> 00:03:10.400
And what's the Secure by Design lesson here?

40
00:03:10.400 --> 00:03:14.560
Memory-safety bugs are among the oldest stories in systems code.

41
00:03:14.560 --> 00:03:16.320
The upstream fix is small.

42
00:03:16.320 --> 00:03:20.080
C I Q says it frees the memory only after a grace period.

43
00:03:20.080 --> 00:03:23.280
The cheaper lesson for a director is about exposure.

44
00:03:23.280 --> 00:03:28.280
If nobody can say why a server listens for an exotic protocol, it shouldn't.

45
00:03:28.280 --> 00:03:34.080
Switching off unused services costs an afternoon, and it shrinks what an attacker with a patient machine can

46
00:03:34.080 --> 00:03:40.560
reach. With models now writing exploits, plan patch windows in days, not weeks.

47
00:03:40.560 --> 00:03:44.800
As always, this is opinion, not advice.

48
00:03:44.800 --> 00:03:48.880
That was Decrypted, with me, Belinder.

49
00:03:48.880 --> 00:03:52.720
The written version and every source are linked in the show notes.

50
00:03:52.720 --> 00:03:56.240
Thanks for listening. Stay patched, and stay sceptical.