from the we-are-not-talking-about-popcorn dept.
In this one, there's a heap overflow bug in the legacy_parse_param in the Linux kernel's fs/fs_context.c program. This parameter is used in Linux filesystems during superblock creation for mount and superblock reconfiguration for a remount. The superblock records all of a filesystem's characteristics such as file size, block size, empty and filled storage blocks. So, yeah, it's important.
The legacy_parse_param() "PAGE_SIZE - 2 - size" calculation was mistakenly made anunsigned type. This means a large value of "size" results in a high positive value instead of a negative value as expected. Whoops.
This, in turn, meant you copy data beyond the memory slab allocated for it. And, as all programmers know, writing beyond the memory your program is supposed to have access to is a terrible thing.
[...] So, how bad is it? By the Common Vulnerability Scoring System (CVSS) v3.1 scoring test, it's a solid 7.7. That's considered a high-security vulnerability.
A local attacker can use it to escalate their user privileges or crash the system. This can be done with a specially crafted program that triggers this integer overflow. That done, it's trivial to execute arbitrary code and give the attacker root privileges.
To exploit it requires the CAP_SYS_ADMIN privilege to be enabled. If that's the case, an unprivileged local user can open a filesystem that does not support the File System Context application programming interface (API). In this situation, it drops back to legacy handling, and from there, the flaw can escalate an attacker's system privileges.
[...] This security hole was introduced back on Feb 28, 2019, in the Linux 5.1-rc1 kernel. It's now present in all Linux kernels. Yes, all of them. Fortunately, the patch is in.
(Score: -1, Troll) by Anonymous Coward on Sunday January 23 2022, @07:24PM
Time for Schlomo and Chaim to put a new bug in its place!
(Score: -1, Troll) by Anonymous Coward on Sunday January 23 2022, @07:46PM
ass don't you.
(Score: 2, Touché) by Anonymous Coward on Sunday January 23 2022, @08:12PM (5 children)
This bug rated 7.7 on the same scale where systemd rated 8.9... that's pretty serious.
(Score: 3, Insightful) by Anonymous Coward on Sunday January 23 2022, @08:54PM (4 children)
Difference is they fixed this bug but systemd is still open.
(Score: 3, Funny) by Anonymous Coward on Sunday January 23 2022, @09:24PM (2 children)
Not a bug, Will not fix so fuck you.
-Poettering
(Score: 2, Touché) by Anonymous Coward on Sunday January 23 2022, @10:07PM (1 child)
Sounds like the KDE/Qt lot, now wanting to allow for ADS within applications in their framework. Or the Gnome devs who are desperate to copy Apple for no good reason (can't innovate, so copy the worst UI out there). Funny - Unity, Win8/10, Deepinn, Gnome 4 - all copying the Apple look.
Why is it that devs are like politicians? The people scream they don't want A but really like B, so the deviticians force A and disable B.
(Score: 1, Informative) by Anonymous Coward on Monday January 24 2022, @12:38AM
For the last time. the KDE project has *nothing* to do with adding an ad platform to Qt.
Qt is a commercial business. KDE is only one downstream consumer.
(Score: 2, Interesting) by Anonymous Coward on Monday January 24 2022, @07:43PM
You can get that bug fix here [devuan.org]
(Score: 5, Interesting) by gawdonblue on Sunday January 23 2022, @09:40PM (1 child)
Which is the buggier bug:
Using an unsigned int where a signed one was expected?
or
Using a signed int for how much memory you want?
(Score: 1, Interesting) by Anonymous Coward on Monday January 24 2022, @03:59AM
using signed avoids having to worry about underflow. Some folks recommend using signed to avoid underflow concerns unless a damn good reason not to.
(Score: 2) by Mykl on Sunday January 23 2022, @10:23PM (5 children)
Is there any indication, based on the change log and actor history, about whether this was a genuine accident, or an intentional vulnerability introduced into the kernel?
(Score: 2, Informative) by Anonymous Coward on Sunday January 23 2022, @11:35PM (4 children)
Looks to be a simple oversight...
(Score: 5, Insightful) by https on Monday January 24 2022, @07:00AM (1 child)
Maybe it's because FORTRAN was one of the first few languages I learned, (only one semester, thank $LC_DEITY), but the order of operations on variables where you have a rough idea of the value of has always been super important.
If you're adding a array of floats, helps to sort first. Gratuitous example, try in ipython:
It's first-year-shit since decades ago: know the limits of your data types. While it may be an oversight, if I was on kernel team I'd be looking at other code this committer has touched for similar oopsies.
Offended and laughing about it.
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 25 2022, @07:45AM
That is a fun one on another level. I tried that test in different Python interpreters and 0.4 + 0.2 + 0.3 + 0.1 == 0.1 + 0.2 + 0.3 + 0.4 was sometimes True and sometimes False.
(Score: 2) by DrkShadow on Monday January 24 2022, @05:11PM (1 child)
Simple oversight? How can this _change_ be justified? It looks benign, but why was this (intended-to-be) nothing-change made at all? It does nothing. It doesn't even increase clarity.
I don't think it was malicious, but what justification was there for making this change? (I really hope it was in the midst of a lot of other modified code, in which case it could be just part of testing/working with code, and never changed back.)
(Score: 2) by maxwell demon on Monday January 24 2022, @07:03PM
That change was not the introduction of the bug, but the fix.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday January 23 2022, @11:41PM
When do we get scorpions, or octopi, or lawn gnomes? How 'bout just a plain old cuttlefish?
(Score: 0) by Anonymous Coward on Monday January 24 2022, @12:13AM (4 children)
Huh?
(Score: 0) by Anonymous Coward on Monday January 24 2022, @01:38AM (3 children)
The attacker doesn't have to have CAP_SYS_ADMIN, the privilege just needs to be enabled in the system.
(Score: 4, Informative) by tekk on Monday January 24 2022, @02:53AM (2 children)
The program needs to be CAP_SYS_ADMIN, which can only be done by root.
This is the kind of bug Raymond Chen over at Microsoft refers to as "other side of the airlock"
(Score: 1, Insightful) by Anonymous Coward on Monday January 24 2022, @05:25AM
It's the "airtight hatchway." This bug isn't quite one of those because you could work your way around having to set CAP_SYS_ADMIN as root yourself, but it is pretty close to that level considering what executables you could count on having that capability and everything else that has to be set up just right for it to work.
(Score: 0) by Anonymous Coward on Wednesday January 26 2022, @02:27AM
This is not accurate. Linux has a feature called "user namespaces" which allows unprivileged users to create processes that have CAP_SYS_ADMIN within the namespace. This is what allows unprivileged users to exploit the bug.
Systems with the user namespaces feature disabled probably are not exploitable. In the past decade or so since user namespaces were introduced many reported exploits have used it, so I suggest turning it off on any system where it is not required.
(Score: 0, Flamebait) by Anonymous Coward on Monday January 24 2022, @10:41AM (1 child)
Just found out only g++ includes -Wsign-compare in -Wall; for gcc you have to pass -Wsign-compare explicitly to get:
Or just use Rust instead:
(Score: 2) by bart9h on Monday January 24 2022, @12:27PM
Where's the "+1 Flamebait" mod when I need it?