<a href="https://nvd.nist.gov/vuln/detail/CVE-2022-1015" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2022-1015</a><p><a href="https://nvd.nist.gov/vuln/detail/CVE-2022-1016" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2022-1016</a><p><a href="https://access.redhat.com/security/cve/CVE-2022-1015" rel="nofollow">https://access.redhat.com/security/cve/CVE-2022-1015</a><p><a href="https://access.redhat.com/security/cve/CVE-2022-1016" rel="nofollow">https://access.redhat.com/security/cve/CVE-2022-1016</a><p><a href="https://ubuntu.com/security/CVE-2022-1015" rel="nofollow">https://ubuntu.com/security/CVE-2022-1015</a><p><a href="https://ubuntu.com/security/CVE-2022-1016" rel="nofollow">https://ubuntu.com/security/CVE-2022-1016</a><p><a href="https://security-tracker.debian.org/tracker/CVE-2022-1015" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2022-1015</a><p><a href="https://security-tracker.debian.org/tracker/CVE-2022-1016" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2022-1016</a><p>I just spent the whole weekend patching whatever the last kernel vuln was and had to plan around like 20 people's schedules. I thought Meltdown/Spectre was bad, this year is already feeling like that year in repeat.<p>15 years as a sysadmin, anyone have suggestions for my next career move? Thanks.
Its yet another int overflow bug too. Something like a kernel should probably be built with saturating arithmetic rather than the stupid C overflow behavior.
There are over 1.412 nodes in the nftables syntax tree (as of 2019).<p>I know. I wrote a Vim syntax hilighter for nftables.<p>And it is still failing.<p>Just imagine how much untested surface area is that for the `nft` CLI.<p>My work: <a href="https://egbert.net/blog/tags/vim.html" rel="nofollow">https://egbert.net/blog/tags/vim.html</a>
I don't understand, does this lead to privilege escalation by parsing a crafted netfilter rule? I am under the impression that I need NET_CAP_ADMIN or root privs to do this on my machines to load said rule anyway, right? So this affects deployments where regular users are able to do send netfilter rules to the kernel, right?
Out of bounds access, uninitialized stack data with an extremely weak language that doesn’t check any of that and happily compiles that hidden footgun gives you an escalation of privileges vulnerability.<p>Perhaps Rust would have prevented this in the first place. But the entirety of Linux and the ancient UNIX philosophy is a giant labyrinth full of cobwebs riddled with hidden traps, landmines and trip-wires beyond exploring.<p>Must be the worlds largest and endless minesweeper game discovering all those C style vulnerabilities in the Linux kernel.
As an early career developer I feel helpless with the vast world of cyber security looming all around me, and not that many people thinking very much about it.<p>It feels kind of like COVID in 2022. Obviously everywhere. Probably not going to hurt me? Could end my career.
This is what I gathered from looking around:<p>1016 comes from an uninitialized value. 1015 is an int8 overflow and out-of-bounds access. Both are C footguns (though not exclusive to C). The latter arguably might not have happened under a stable/specified ABI.<p>1015:<p><pre><code> Introduced in 5.12
Fixed in 6e1acfa387b9, 2022-03-17
In LTS, fixed in 5.10.109 and 5.15.32
Also, in 5.16.18 and 5.17.1
</code></pre>
1016:<p><pre><code> Introduced in v3.13-rc1
Fixed in 4c905f6740a3, 2022-03-17
Fixed in same point releases as above, plus 5.10.109
Doesn't look fixed in older LTSes yet</code></pre>