Linux Kernal Vulnerability Let Attackers Bypass CPU & Write on Memory

Researchers uncovered a vulnerability in the Linux kernel’s dmam_free_coherent() function, which stems from a race condition caused by the improper order of operations when freeing DMA (Direct Memory Access) allocations and managing associated resources.

This vulnerability can lead to system instabilities and malfunctions, as DMA is crucial for allowing hardware devices to transfer data directly to and from system memory without CPU involvement.

Please read the topic here which I just read a few minutes ago: Linux Kernal Vulnerability Let Attackers Write on Memory

As I am a newbie and don’t understand the technical jargons like this, it will be very helpful if someone can explain what could be the results of this vulnerability, what precautions should we take and what is Fedora’s take on this issue.

1 Like

Question1:

Answer1:

A bug in this process could result in incorrect memory access, leading to data corruption, unexpected behavior, or crashes.

Question2:

Answer2:

The answer is in the last paragraph of your posted topic:

As the Linux kernel continues to evolve and power a vast array of devices, patches like this one demonstrate the ongoing efforts of the developer community to identify and rectify potential bugs, ensuring a more stable and reliable operating system for users worldwide.

Keep your system updated!

1 Like

Ilikelinux already put forward the major answer:

As a normal user, this is the major thing to do.

If you want to limit your actions to this, it is suggested to also stick with a supported system, which means to not add third party software or repos, as these can sometimes introduce vulnerabilities but also keep them (e.g., if some third party software is not updated when necessary, it might enforce old packages to remain on your system).

As far as it concerns vulnerabilities in the kernel: such issues in software engineering are normal and occur regularly. The advantage in Linux is that is contains the biggest competition towards improvements (not necessarily competition among people) and widespread contribution and reviews and testing globally among kernels.

This means, it is unlikely that anyone else uncovers a vulnerability before the Linux community does, and it is also unlikely that anyone can exploit it before the community can fix it. In other systems, these likihoods are less advantageous. This leads back to ilikelinux comment:

:classic_smiley:


It might be added two further things:

  1. even if a vulnerability cannot be fixed immediately: if necessary, it gets mitigated immediately, such as affected functions are disabled until the fix is available or so (such a mitigation will be introduced on your system by your normal updates: usually this is released as a new kernel. This is very seldom, but it already occurred before that a new kernel was released that just removed an existing function so that the vulnerability could be published and the competition towards the best solution begin)

  2. kernel vulnerabilities seldomly can be exploited on average user systems. If at all, they are more relevant on servers and systems that provide some services to other systems (even then, most kernel issues are hard to exploit if at all).

2 Likes

Users should not need to manually update. Nobody does that on phones, if updates are not automatic, nobody does it.

I am happy that automatic updates are established at least on the Atomic variants, where they always work.

1 Like

Automatic updates are configured for Workstation, Silverblue, KDE, and Kionite through gnome-software or discover.

AFAIK, it is not configured/enabled on other spins, labs, etc without it being configured by the user/admin.

2 Likes

I do, I want to see if there is an update where could cause problems for my system. That is why I avoid also the -y option with dnf (just to use for scripts). Trust is good but control is better especially if I want to take responsibility myself :slight_smile:

This shows that we do have the freedom to choose. And this is about Open Source Software where not just two eyes and one mind makes decisions for all.

1 Like

Afaik, that’s correct. These are the Fedora variants the community supports reliably and officially (theoretically, KDE is not a formal edition, but that has an organizational background: for the scope of this topic, it can be said to be supported the same way Workstation is)

I do not know if and which of the formally-unsupported variants/spins have automatic updates, but other spins/variants (other than the mentioned above) are indeed not necessarily intended for users who want to rely on the system being pre-configured appropriately with security considerations. They ain’t editions and so the community cannot guarantee for them. Given that they are usually maintained by single or just a few individuals, not deeply intertwined with the other teams, the other spins/variants lack sufficient security considerations. This can start with firewalls without pre-configuration (itself not a vulnerability though), but might end up in the need for manual updates. Some have also a maintenance issue (obsoleted packages that no one updates). Effectively, we give only a guarantee for those mentioned by Joe .

That is indeed a problem on phone: they usually have support for updates only a short time. Some vendors provide support only for 2 years, some give no guarantee for anything. This means that even if people do updates and think they are up to date, their system is obsoleted at the worst for years. So I agree that updates should be automatic by default, but I disagree that the problem is solved on phones :wink: Also, I am not convinced that they are always automatic by default: vendors have too much possibilities to adjust the OS they ship (e.g., android), so I think you have to verify this argument with each single vendor. Except Android has standardized this as prerequirement that all vendors have to implement? I know something like that from disk encryption, which has to be enabled if the SoC has sufficient performance.

1 Like

I always update the system whenever it shows. Generally the update comes in 2-3 times a week and that ensures how much the developers and the community cares for Fedora Project. I did the right choice. But, I have installed a softwate named ‘KITSCENARIST’, which is a scriptwriting software and was open source and free, which the developer recently announced as ‘abandoned’ but it is still available for download on their website. I downloaded this free one and saw that the package was built for FC38. Hesitently I installed it manually (they made it very easy to install) and it installed perfectly without any problem except the standard warning. What do you think, should I remove it or continue to use it. I just opened it once.

but in the end you still have to reboot on atomic variants to update make any difference, right ?
Is there a more automatic way in atomic variants ? i usually update once a month or longer because the reboot thing is kinda setback

Not at all what I said but fine XD

Random Android vendors yes. Apple, as much as they [lock people in their ecosystem and be a proprietary blackbox collecting data permanently] , has offered 6+ years of updates a long time.

Pixels have 8 years now too, GrapheneOS even offers some for EOL devices.

The firmware and software updates are tied together and stop together, which sucks but that is due to how firmware on Android needs to be signed by the vendor.

An autoupdate config page like this makes them complely unproblematic.

Combined with the fact that these are immutable, very stable and well tested.

Btw I dont care about vendor Android, otherwise I would use Windows 11 which came on 2 Laptops I bought :wink:

This is not a big issue on Fedora Atomic Desktops. And not many people use their devices like that.

Fedora needs to be an OS for everyone, not just tech enthusiasts.

And tbh, I also like experimenting with other stuff than trying to not break my system.

I would agree that on dnf Fedora autoupdates shouldnt be done. But Idk, I wouldnt recommend anyone that OS, as it just breaks too often.

If Debian gets Plasma 6, I would always use that when Fedora Kinoite is not possible (Windows dualboot). I have had dozens of issues with dnf in a very short time of usage, none with rpm-ostree (apart from speed and layering packages removed in the OCI image building process).

Absolutely, afaik, they are the longest. Samsung offers some devices with 5, which is the second longest I know. Apple indeed have a reputation of providing support very long, but afaik they have never given any guarantee at all, but maybe that changed in the meantime. But the point is:


However, we leave the realms of the topic, and maybe we should thus refocus again. Also, please stop using affronting formulations, especially when you refer to others, including companies you do not like. If you have a problem with apple, focus on facts about it (when it is on-topic), not on affronts. That’s usually more powerful anyway :classic_smiley:

1 Like