Patch Me If You Can
May 3, 2026
We dig into the Copy Fail vulnerability and test a proof-of-concept against our own box. Plus, Jon Seager, VP of Engineering at Canonical joins us, and we kick off the BSD Challenge!
Sponsored By:
- Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!
- Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.
Links:
- 💥 Gets Sats Quick and Easy with Strike
- 📻 LINUX Unplugged on Fountain.FM
- Copy Fail — CVE-2026-31431 — "An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root." — Theori
- Copy Fail: 732 Bytes to Root - Xint — "A single 732-byte Python script can edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017." — Xint
- Linux Kernel Bug Explained - Jorijn — "CopyFail is more portable. One script, every distro, no offsets. Dirty Pipe needed kernel ≥ 5.8; Copy Fail covers 2017–2026." — Jorijn"Kubernetes Pod Security Standards (Restricted) and default seccomp do NOT block the syscall used." — Jorijn
- Ars: Most Severe Linux Threat in Years — "The most severe Linux threat to surface in years catches the world flat-footed." — Ars Technica
- Sysdig: CVE-2026-31431 Analysis — "The flaw was introduced in 2017 via commit 72548b093ee3, which switched AEAD operations to in-place processing." — Sysdig
- CERT-EU Advisory
- Ubuntu Security Tracker
- The Register: Crypto Flaw
- Kernel Patch (reverts 2017 optimization) — "This mostly reverts commit 72548b093ee3 except for the copying of the associated data." — Kernel Commit
- Buggy Commit: 72548b093ee3 (2017)
- DeepWiki: AF_ALG Internals
- oss-security Disclosure
- PSA + GRUB Mitigation - Jan Wildeboer
- Ubuntu 26.04 LTS (Resolute Raccoon) Released — "Ubuntu 26.04 LTS sets the example for providing best-in-class resilience while simultaneously embracing innovation and the advancement of open source." — Jon Seager, VP Ubuntu Engineering
- The Future of AI in Ubuntu - Jon Seager — "Throughout 2026 we'll be working on enabling access to frontier AI for Ubuntu users in a way that is deliberate, secure, and aligned with our open source values." — Jon Seager
- Ubuntu 26.04 Release Notes
- Ubuntu AI Features Throughout 2026 - Phoronix — "Canonical's approach to AI is refreshingly thoughtful — Microsoft should take note." — ZDNet
- Canonical DDoS Attack Update — "Canonical's web infrastructure is under a sustained, cross-border attack and we are working to address it." — arcticp, Canonical
- Ubuntu Weekly Newsletter #942
- Canonical AI Approach - ZDNet
- 9to5Linux: Opt-In LLM Tools
- uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils
- LINUX Unplugged 636: Engineering the Future
- LiveCD fails to start X session on QEMU · Issue #354 · ghostbsd/issues
- Monty's “rescue” drive NixOS config
- Magnolia Mayhem's BSD Challenge Report
- Pick: NASty — NASty is a NAS operating system built on NixOS and bcachefs. It turns commodity hardware into a storage appliance serving NFS, SMB, iSCSI, and NVMe-oF — managed from a single web UI, updated atomically, and rolled back when things go sideways.
- Pick: Defuse — Defuse is a GTK4 application for removing image backgrounds locally.
- Defuse on Flathub
Transcript
WEBVTT
00:00:11.309 --> 00:00:15.909
Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris.
00:00:16.089 --> 00:00:16.689
My name is Wes.
00:00:16.849 --> 00:00:17.529
And my name is Brent.
00:00:17.709 --> 00:00:21.929
Hello, gentlemen. Coming up on the show today, we'll cover the copy-fail vulnerability,
00:00:22.149 --> 00:00:26.069
tearing through Linux distributions out there, plus Ubuntu 2604,
00:00:26.289 --> 00:00:30.949
the Resolute Raccoon, is here, and John Seeger will dig into the details with us.
00:00:31.089 --> 00:00:34.249
And then we'll round out the show with some great boosts and picks and a heck
00:00:34.249 --> 00:00:38.089
of a lot more. So before we get into that, this is like three big shows in one.
00:00:38.329 --> 00:00:41.609
We've got to bring in our virtual lug. time-appropriate greetings, Mumble Room.
00:00:42.149 --> 00:00:44.029
Hello, Chris. Hello, Brent.
00:00:44.589 --> 00:00:44.889
Hello.
00:00:44.929 --> 00:00:45.529
Hello, hello.
00:00:45.949 --> 00:00:48.649
And shout out to everybody up there in the quiet listening and everybody on
00:00:48.649 --> 00:00:50.529
the live stream. Pershing H.
00:00:50.609 --> 00:00:52.229
We see you. You hear us.
00:00:53.529 --> 00:00:56.349
Something like that. A version of that somewhere in there.
00:00:56.589 --> 00:00:57.549
You boost? I don't know.
00:00:57.629 --> 00:01:01.569
I don't know. Also, good morning to our friends over at Defined Networking.
00:01:01.609 --> 00:01:03.709
Go check out Manage Nebula from Defined Networking.
00:01:03.849 --> 00:01:09.969
It gives you a decentralized VPN built on the open-source Nebula platform that we just love.
00:01:10.129 --> 00:01:14.929
And what I really like is the flexibility. You can build the network you want
00:01:14.929 --> 00:01:19.829
and the way you actually want it, from maybe your home lab to a full enterprise setup.
00:01:20.009 --> 00:01:23.609
And you have the option to run your own lighthouse nodes so you own the stack
00:01:23.609 --> 00:01:26.289
end-to-end. But you don't have to start the hard way.
00:01:26.809 --> 00:01:30.629
Define gives you a full managed experience, so that way you can get up and running
00:01:30.629 --> 00:01:34.709
fast with speed, security, and resilience baked in from day one.
00:01:35.129 --> 00:01:39.809
No big tech login required. Try it for free, 100 hosts, no credit card,
00:01:39.949 --> 00:01:42.889
at defined.net slash unplugged.
00:01:42.949 --> 00:01:46.169
That is defined.net slash unplugged. You go over there, you support the Unplugged
00:01:46.169 --> 00:01:49.969
program, defined.net slash unplugged. And a big thank you to the defined folks
00:01:49.969 --> 00:01:54.609
over there and the fine, fine folks at Defined for sponsoring this here program.
00:01:56.287 --> 00:02:00.507
Let's get right into it. Gentlemen, we have ourselves quite the vulnerability this week.
00:02:00.687 --> 00:02:04.407
Copy fail, which is an unprivileged local attack that allows,
00:02:04.527 --> 00:02:09.687
say, even just a generic Brent user with no admin rights to pop your box.
00:02:09.847 --> 00:02:10.607
Yeah, that's not great.
00:02:10.787 --> 00:02:16.867
No. And it turns out it's been baked into most Linux distros since 2017-ish. Is that right?
00:02:17.047 --> 00:02:17.187
Yeah.
00:02:17.407 --> 00:02:19.887
So that's a while and just about everything that's shipping right now.
00:02:20.267 --> 00:02:24.067
And some distros are still working very hard to get it patched.
00:02:24.567 --> 00:02:28.747
ours writes it's the quote most severe linux threat to the to surface in years
00:02:28.747 --> 00:02:33.507
and it is catch it has caught the world flat-footed and my tongue what do you
00:02:33.507 --> 00:02:36.707
think there wes pano what i want to get your take on this first because you've
00:02:36.707 --> 00:02:38.147
actually been playing around with the exploit.
00:02:38.147 --> 00:02:40.867
Yeah um it is worth noting right you do need some sort
00:02:40.867 --> 00:02:43.747
of access right so you need you if you don't have a user account on
00:02:43.747 --> 00:02:46.567
the box you need some other chain some other vulnerability maybe it's a
00:02:46.567 --> 00:02:49.427
you know some kind of injection in a web app whatever
00:02:49.427 --> 00:02:52.667
it is um but once you have that user access then
00:02:52.667 --> 00:02:56.087
yeah pretty much any system because it's a kernel logic issue the
00:02:56.087 --> 00:02:59.047
particular like the first poc that was released was
00:02:59.047 --> 00:03:03.687
like a python 3 thing and sort of made some assumptions about like particular
00:03:03.687 --> 00:03:09.507
set uid binaries like su uh but those are all particular implementation details
00:03:09.507 --> 00:03:12.647
so it's important to realize that like the core thing is this is this kernel
00:03:12.647 --> 00:03:16.607
flaw uh which we could get into because it's it's kind of fascinating because it,
00:03:17.554 --> 00:03:21.674
As often is the case. Well, one, I guess we should note, it was an AI-assisted
00:03:21.674 --> 00:03:25.614
finding, but began with insight from human researchers at Theore,
00:03:26.494 --> 00:03:30.754
Taiyang Li, who's studying how the Linux crypto subsystem interacts with page
00:03:30.754 --> 00:03:32.834
cache-backed data, and we'll get into that.
00:03:33.334 --> 00:03:37.274
So there's a few layers. The first is the VFS layer. There's this call called
00:03:37.274 --> 00:03:41.634
Splice that kind of lets you combine pipes and file descriptors.
00:03:41.714 --> 00:03:45.934
So you can open a file for reading and then combine that with a pipe and then
00:03:45.934 --> 00:03:50.194
pipe it into other things that you're using when you're calling kernel APIs.
00:03:51.434 --> 00:03:57.794
And in particular, there's this AFALG API and it lets user space programs take
00:03:57.794 --> 00:04:00.494
advantage of all the cryptographic stuff or a lot of the cryptographic stuff
00:04:00.494 --> 00:04:03.434
that exists in the kernel, which is good, both because like you don't have to
00:04:03.434 --> 00:04:05.634
reimplement it, but also the kernel has access to hardware stuff.
00:04:05.754 --> 00:04:08.314
Like there's various reasons the kernel might be able to do it faster or more
00:04:08.314 --> 00:04:12.534
securely or better than the random user space program that needs to handle encrypted data.
00:04:13.034 --> 00:04:18.814
The problem is that in 2017, there was an in-place optimization made.
00:04:19.014 --> 00:04:24.034
So basically to avoid allocating duplicate memory during decryption processes,
00:04:24.034 --> 00:04:26.074
you have some encrypted data, you're calling the kernel to say,
00:04:26.154 --> 00:04:27.594
hey, please decrypt this for me.
00:04:27.994 --> 00:04:30.114
The kernel tries this in-place operation.
00:04:30.814 --> 00:04:34.854
Basically, you need to pass the data into the kernel for what you want to decrypt.
00:04:34.894 --> 00:04:35.634
And there's various parts.
00:04:35.794 --> 00:04:38.934
There's like some of the cryptographic primitives, which is the actual encrypted
00:04:38.934 --> 00:04:41.654
data, and there's the authentication tag.
00:04:41.654 --> 00:04:46.074
and it builds this buffer that it's going to pass into the kernel and it copies
00:04:46.074 --> 00:04:50.854
some of the first parts in there but it doesn't actually copy the tag instead
00:04:50.854 --> 00:04:55.874
it basically passes a reference to the tag's memory at the end there instead
00:04:55.874 --> 00:04:58.614
of like allocating new memory and putting the tag in there.
00:04:59.408 --> 00:05:03.568
And unfortunately, later on in the cryptographic algorithms,
00:05:03.868 --> 00:05:09.628
this spot, the RxSGL, the destination, is inherently treated as writable.
00:05:10.288 --> 00:05:13.808
So in this stage, like kind of when you have the splice side of it,
00:05:13.948 --> 00:05:18.048
it's all fine. It's like read-only. You're just kind of like splicing on this read-only reference.
00:05:18.528 --> 00:05:22.608
And we'll get more into that. But it's really the problem where we did this
00:05:22.608 --> 00:05:27.468
optimization in the mechanism that lets user space programs call into the kernel.
00:05:27.468 --> 00:05:33.508
And then you need another piece, which is there's a particular encryption mechanism
00:05:33.508 --> 00:05:38.708
for IPsec, auth and ESN for extended sequence numbers.
00:05:38.908 --> 00:05:40.448
And basically it's these 64-bit
00:05:40.448 --> 00:05:43.668
numbers that they need to do stuff and rearrange some of the bits for.
00:05:44.168 --> 00:05:49.268
And it kind of cheats. It uses the caller's destination buffer,
00:05:49.428 --> 00:05:52.808
which is the thing we were just talking about, as a temporary scratch space.
00:05:52.888 --> 00:05:53.408
That's okay, though.
00:05:54.488 --> 00:05:58.888
And specifically, it uses scatter, walk, map, and copy to write four bytes past
00:05:58.888 --> 00:06:02.368
the end of the legitimate plain text data precisely at an offset.
00:06:02.748 --> 00:06:05.788
So you kind of put this all together, and this is what the actual,
00:06:05.788 --> 00:06:08.308
like, exploit does is...
00:06:09.894 --> 00:06:13.854
The attacker, so you basically, you need some sort of file that you have read
00:06:13.854 --> 00:06:16.914
access to. That's important. So you open that file for reading.
00:06:17.034 --> 00:06:20.234
Which should just, I mean, that should be pretty easy. As long as you can get on the box.
00:06:20.354 --> 00:06:23.694
Yeah, yeah. So there's some file that the user can read. We'll get into that.
00:06:23.874 --> 00:06:27.354
But could that even be like a web server process? I mean, this is,
00:06:27.474 --> 00:06:28.894
that's pretty generic. Okay.
00:06:29.134 --> 00:06:31.654
Yeah, it doesn't need special permissions or anything.
00:06:31.794 --> 00:06:32.034
Yeah, yeah.
00:06:32.254 --> 00:06:36.074
So it basically opens that file, which loads it into the page cache,
00:06:36.154 --> 00:06:39.314
right? which was the memory cache that sort of like you put things in so that
00:06:39.314 --> 00:06:41.014
you don't have to go fetch them from disk all the time in the kernel.
00:06:41.234 --> 00:06:43.214
And this ends up being system-wide, by the way.
00:06:43.454 --> 00:06:46.634
And so it has that available, and then it makes this splice call to sort of
00:06:46.634 --> 00:06:50.574
set up this pipe that gives it basically a memory reference to that data.
00:06:50.934 --> 00:06:55.974
So the attacker aligns the splice offset so that what it is thinking is this
00:06:55.974 --> 00:06:59.034
tag reference, right? It's trying to pass a tag into the crypto API.
00:06:59.394 --> 00:07:03.454
That actually points exactly over where it's trying to write in whatever the
00:07:03.454 --> 00:07:07.074
target is. So it opens, say, the SU binary, right, with this.
00:07:07.254 --> 00:07:08.674
It opens it just for reading.
00:07:08.854 --> 00:07:08.974
Yeah.
00:07:09.314 --> 00:07:13.574
And then it kind of aligns things then so it passes a memory reference to wherever
00:07:13.574 --> 00:07:14.594
it's trying to overwrite.
00:07:15.183 --> 00:07:19.223
and then it calls into the crypto API, and then it just blindly changed that
00:07:19.223 --> 00:07:22.643
page cache reference because the actual reference it gets is the page cache.
00:07:22.763 --> 00:07:25.243
It's the page cache for the binary.
00:07:25.663 --> 00:07:28.183
That's a key part of it, right? So it's like when it opens it for reading,
00:07:28.283 --> 00:07:31.943
the kernel happily goes and reads it and then gives it a reference to the memory
00:07:31.943 --> 00:07:34.383
that corresponds to the actual page cache entry.
00:07:35.023 --> 00:07:39.523
So then when the crypto stuff happens, it just changes that tag thing,
00:07:39.643 --> 00:07:44.903
which ends up being the page cache reference, onto the actual final buffer that it's going to be using.
00:07:45.183 --> 00:07:50.903
And then the particular IPsec encryption algorithm does its byte shuffling stuff
00:07:50.903 --> 00:07:54.923
and writes those four bytes, which are now attacker controlled,
00:07:55.163 --> 00:07:57.803
past the normal sort of plain text stuff it's supposed to be using.
00:07:58.183 --> 00:08:02.043
And then that, because it was aligned from our first thing with the splice,
00:08:02.263 --> 00:08:06.863
then writes not to the file on disk, but it writes four bytes to whatever you
00:08:06.863 --> 00:08:09.463
like in the page cache version of the file.
00:08:09.763 --> 00:08:13.143
They have a very clever little payload. it's
00:08:13.143 --> 00:08:16.123
like 158 bytes and people have been golfing this further but
00:08:16.123 --> 00:08:19.743
it's basically a super clever tiny little minimal elf thing
00:08:19.743 --> 00:08:22.963
that like all it really does is look so
00:08:22.963 --> 00:08:26.183
instead of having to figure out like target a particular binary
00:08:26.183 --> 00:08:28.843
to patch in a particular way they just override it from the
00:08:28.843 --> 00:08:32.243
start with a super minimal little tiny custom binary it's clever
00:08:32.243 --> 00:08:34.943
to be like as position independent as can be and like work is in
00:08:34.943 --> 00:08:39.003
many places but it basically just it calls set uid zero to like really sort
00:08:39.003 --> 00:08:42.603
of sink in and like make sure it has full root permissions it's already running
00:08:42.603 --> 00:08:45.883
here in like a context of a set uid binary but like it makes sure that's synced
00:08:45.883 --> 00:08:49.763
to all the kernels places and then it just has like a nice clever way to call
00:08:49.763 --> 00:08:52.743
slash bin slash sh but it could do anything here that you wanted this was just
00:08:52.743 --> 00:08:54.823
a quick way to spawn a root shell.
00:08:55.432 --> 00:08:58.972
Now, what's interesting is, like, if you just do it on, say,
00:08:59.032 --> 00:09:00.972
like, an affected Ubuntu instance, it'll just work.
00:09:01.052 --> 00:09:05.092
But the script that was first sort of put out there, hard-coded user bin SU.
00:09:05.372 --> 00:09:07.732
So, like, on a NixOS app, when I was trying to play with it,
00:09:07.892 --> 00:09:10.572
at first that didn't work just for the reason that that's not the right path
00:09:10.572 --> 00:09:12.472
for where SU lives on a Nix system.
00:09:12.772 --> 00:09:17.392
But then also, it turns out that on NixOS, a lot of SUID binaries,
00:09:17.572 --> 00:09:20.752
or the wrappers for them, are configured as execute only.
00:09:20.992 --> 00:09:24.112
So you don't actually have read permissions. So that's another way it could
00:09:24.112 --> 00:09:26.372
fail. And you could think that you're not actually impacted,
00:09:26.372 --> 00:09:29.892
but those are all just implementation details because you could also,
00:09:30.192 --> 00:09:32.712
like, there are a bunch of stuff that you kind of have to be able to read,
00:09:32.872 --> 00:09:35.772
like shared libraries, libc, pamunix.
00:09:36.292 --> 00:09:39.252
You could also target something like etsypassword, say, right?
00:09:39.292 --> 00:09:42.452
There's like a lot of stuff that you could overwrite that you have to have read
00:09:42.452 --> 00:09:43.792
access to to be able to do.
00:09:43.972 --> 00:09:48.912
And then what's so tricky about this, right, is then it's poisoned the page cache.
00:09:48.912 --> 00:09:53.012
but the kernel in all of this stuff that's happening it never there's like an
00:09:53.012 --> 00:09:56.692
error but it never sort of undoes anything and it never then marks that as dirty
00:09:56.692 --> 00:10:00.832
so it doesn't know that it needs to be re-read like anything's wrong and so,
00:10:01.946 --> 00:10:06.566
If you go try to hash it, the hash will go check the, like the hash thing command
00:10:06.566 --> 00:10:08.606
will actually go get the bytes on disk and it'll be fine.
00:10:08.826 --> 00:10:14.566
But if you make an exec call, like the exeve call in the system call,
00:10:14.766 --> 00:10:16.766
the kernel is just going to use the page cache.
00:10:16.866 --> 00:10:17.026
Yeah.
00:10:17.206 --> 00:10:18.386
That's the whole thing. That's the point.
00:10:18.586 --> 00:10:19.046
Oh, man.
00:10:19.206 --> 00:10:23.066
And you're not checking that. Right. And so you have to be much more clever
00:10:23.066 --> 00:10:25.966
around how to detect it because you can't just like do the hash.
00:10:26.106 --> 00:10:28.506
Now, it does mean it's not persistent because if you reboot,
00:10:28.626 --> 00:10:31.486
then the page cache is gone. So that's a small blessing here.
00:10:31.586 --> 00:10:31.746
Yeah.
00:10:31.946 --> 00:10:38.026
But it's, yeah, it's widespread, kind of nasty. It does need some chaining in a lot of cases, but...
00:10:38.026 --> 00:10:40.746
Containerization doesn't solve it because it's still using these same primitives.
00:10:40.866 --> 00:10:42.006
It does seem like systems that
00:10:42.006 --> 00:10:45.766
have strict SE Linux and perhaps AppArmor profiles might be better off.
00:10:45.946 --> 00:10:50.006
Or like you said, if you have it where execute is only and read isn't an option.
00:10:50.986 --> 00:10:55.046
So key takeaways are this is a bad one. And it's been on machines for a while.
00:10:55.386 --> 00:10:57.926
And we're going to have a lot of patching to do.
00:10:58.406 --> 00:11:02.386
and the bug was found by an AI-assisted coding analysis tool in roughly an hour.
00:11:03.186 --> 00:11:06.566
So expect the cadence of deep kernel disclosures to pick up.
00:11:06.806 --> 00:11:11.806
Yeah, I guess folks at the xint.io and they've got some various setups and harnesses
00:11:11.806 --> 00:11:12.866
to kind of go poke around.
00:11:12.986 --> 00:11:16.566
So they had some hypotheses, partly from human researchers, exploring various
00:11:16.566 --> 00:11:21.606
places that might have bugs and then I guess they threw some AI at it.
00:11:21.666 --> 00:11:25.686
It turned up a bunch of stuff and this is what it rated as the highest severity issue.
00:11:25.926 --> 00:11:29.266
Mm-hmm. Mm-hmm. So 2604, not currently affected?
00:11:29.526 --> 00:11:30.586
No, I believe not.
00:11:30.766 --> 00:11:34.446
That's good. And, of course, the Debian security channel has a patch.
00:11:34.726 --> 00:11:36.306
Alma Linux has it patched.
00:11:36.806 --> 00:11:40.026
So the patch is getting out there. NixOS has something, even though,
00:11:40.166 --> 00:11:43.246
like you said, your box wasn't. But all the big distros are going to get it
00:11:43.246 --> 00:11:44.766
affected. There is a way people can tell, right?
00:11:45.507 --> 00:11:47.927
If they just look at their kernel version, if they have, well,
00:11:48.007 --> 00:11:49.647
basically anything since 2017.
00:11:50.027 --> 00:11:54.507
And you can also, like, there are very safe, like, little test exploits you can run.
00:11:54.687 --> 00:11:54.827
Yeah.
00:11:54.827 --> 00:11:57.767
You can also check, like, you do need some of these modules.
00:11:58.067 --> 00:11:59.607
Like, some kernels have them built in.
00:11:59.747 --> 00:12:01.127
Some are as, like, loadable modules.
00:12:01.127 --> 00:12:03.927
So you could sort of remove them and prevent them from being loaded.
00:12:04.067 --> 00:12:07.887
So there's various mitigations per distro, sort of, depending on how your kernel is set up.
00:12:08.287 --> 00:12:12.627
I think we're going to have to, as a community, look at this as an opportunity,
00:12:12.627 --> 00:12:15.827
not as a burden, even though it is absolutely going to be a massive workload.
00:12:16.327 --> 00:12:22.207
But as a community, we have always championed the idea that more eyes means shallower bugs.
00:12:22.407 --> 00:12:26.907
And now we are getting dramatically more eyes. We are getting exponentially more eyes.
00:12:27.007 --> 00:12:29.607
More AIs means less shallow bugs.
00:12:29.687 --> 00:12:36.087
More AIs means, yeah, exactly. And the upshot is our software will get more secure.
00:12:36.367 --> 00:12:40.007
Yeah, so when they fixed this, they didn't actually fix the IPsec part where
00:12:40.007 --> 00:12:44.487
it was kind of cheating and using that little scratch part. They fixed the in-place
00:12:44.487 --> 00:12:49.087
optimization from 2017 so that it never passes this reference anymore.
00:12:49.187 --> 00:12:52.467
So there's no longer some sort of coupling between the input and output and
00:12:52.467 --> 00:12:53.587
reusing some of those stuff.
00:12:53.727 --> 00:12:57.687
And the part that's so funny is in the commit message, they note there's actually
00:12:57.687 --> 00:13:01.147
no benefit in operating in-place in this way since the source and destination
00:13:01.147 --> 00:13:02.207
come from different mappings.
00:13:02.407 --> 00:13:04.587
So we didn't even really need to be doing this.
00:13:05.367 --> 00:13:08.367
I have a question for you, Wes. It's more of maybe your opinion.
00:13:08.367 --> 00:13:13.607
Given this has come out now and is somewhat obscure for the kernel,
00:13:14.167 --> 00:13:18.807
any thoughts on, given the kernel's complexity, like how many of these little
00:13:18.807 --> 00:13:20.167
things are just hiding in there?
00:13:20.287 --> 00:13:21.027
That's a good question.
00:13:21.207 --> 00:13:21.467
Yeah.
00:13:21.847 --> 00:13:22.627
It's hard to estimate.
00:13:22.787 --> 00:13:23.847
And think about every library...
00:13:24.987 --> 00:13:28.027
every service, every service on the internet that listens remotely.
00:13:28.367 --> 00:13:31.067
But we probably have been needing to do this for a long time.
00:13:31.067 --> 00:13:33.527
We probably should have had a lot more humans focused on this,
00:13:33.587 --> 00:13:34.647
but we just weren't doing it.
00:13:34.747 --> 00:13:35.287
It's a hard problem.
00:13:35.487 --> 00:13:38.747
It is also right, like that where, you know, and maybe using the assistance
00:13:38.747 --> 00:13:42.567
where you can, whatever, to try and up your posture and do things more by default.
00:13:42.567 --> 00:13:47.027
Because like, if you do things like, you know, okay, fewer permissions on set
00:13:47.027 --> 00:13:50.767
UID binaries, or you try to take as much advantage of all the hardening that
00:13:50.767 --> 00:13:54.567
systemd services offers by default. so that it sees less of the system and has
00:13:54.567 --> 00:13:56.547
less access to things, even read-only.
00:13:56.767 --> 00:13:59.847
There are tools we have, and we need to grow better ones.
00:14:00.107 --> 00:14:03.047
But I think it just means defense in depth will become even more important.
00:14:03.267 --> 00:14:06.627
I do think when we see these, a lot of times, folks that have taken the time
00:14:06.627 --> 00:14:11.187