# When a Jetson Update Breaks CUDA: L4T Security Patch Fallout (And How to Fix It)

## Метаданные

- **Канал:** JetsonHacks
- **YouTube:** https://www.youtube.com/watch?v=uhIlrVpDQN8
- **Источник:** https://ekstraktznaniy.ru/video/39289

## Транскрипт

### Segment 1 (00:00 - 05:00) []

In breaking news, Nvidia just released a key vulnerabilities fixed release for L4 T36. 4. This addresses CVE-2024-0126, a high severity vulnerability in the NVIDIA GPU display driver for Linux kernel mode layer. This fixes the issue where an unprivileged user could cause an outofbounds right. This is a serious flaw because it can be exploited to gain escalated privileges, execute arbitrary code, or crash the system exhibiting denial of service. Update your system now. — That sounds pretty scary. I'd better upgrade. — One hour later. — Well, let's see what we have. What version are we running now? It looks like we're running 36. 4. 7. 4. 7. Here's another way to look at it. This method gives us the build number. While we are here, let's take a look at the version of Jetack that is installed. Jetack 6. 2. 1. That sounds good. Let's take it for a spin. You can see that the camera appears to freeze and we start getting error messages in the transcript. — What? What the [ __ ] — We can see that there are memory allocation errors. After testing a little further, I found that it affected several different applications. I also noticed that it was triggered when large amounts of GPU memory were requested, like when using ALLM. So, it's off to the Jetson forums to see if other folks are having this issue. This looks like a good description of the issue. I'll leave these links below. We're in mid-occtober 2025 here. Apparently, this was a difficult issue to resolve because it took until December to come up with a fix. The fix was posted on another thread. This is the professional fix. It involves recompiling the kernel. This entry includes the kernel patches you need to apply to get 36. 4. 7 to run correctly. If you are contemplating this path, then you don't need my help as you have to fit it into your preferred workflow. If you're not comfortable with compiling your own kernel, there is another path. An alternative is to simply downgrade L4T, which should be fine if you do not expose the Jets into a hostile network. We can go to the Jetack archive and go grab a SD card image of Jetpack 6. 2. 1. 2. 1. This should be L4T 36. 4. 4. I recommend running your system from a SD card until you fully upgrade the system when 36. 5. 0 arrives. Flash the SD card and go through the setup process. As soon as we go through the initial setup, we mark the L14T packages to hold so that the upgrade process does not change the version. Let's check on the version to make sure we're on the correct baseline. Okay, those look correct. One more time. Let's make sure that we haven't installed Jetpack. Great. Now, let's put a hold on the packages. Let's take a look at all the L4T packages. Now we're ready to put a hold on them. I'll leave the command in the description. It looks like everything took. Looking good. Let's reboot. Though a power cycle may be more reliable. Now we'll go through a apt update and upgrade to make sure the L4T packages do not get updated. The packages are marked hold. Let's upgrade. It's time to install Jetack so we can have all of our CUDA friends with us. Let's look at the CUDA compiler. Oh, the paths aren't set correctly. We'll run it directly. It looks like that works too. Now you can continue with the rest of your

### Segment 2 (05:00 - 05:00) [5:00]

setup. At this point, the machine should be running L4T 36. 4. 4 and ignore any upgrade requests to L4T. I would show you the version at this point, but I don't want to insult your intelligence or I forgot to film that bit. In either case, thanks for watching.