View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001441 | channel: kernel/el9 | kernel-lt | public | 2024-04-02 13:45 | 2024-04-02 15:00 |
Reporter | ludditus | Assigned To | toracat | ||
Priority | normal | Severity | tweak | Reproducibility | have not tried |
Status | closed | Resolution | no change required | ||
Summary | 0001441: CVE-2024-1086: could it be addressed independently of mainstream? | ||||
Description | CVE-2024-1086 kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function. Affected Versions: 3.15 <= Linux kernel <= 6.8-rc1 Notselwyn's Proof-of-Concept exploit for CVE-2024-1086 works on most Linux kernels between v5.14 and v6.6. As a user of kernel-lt for el9, I am concerned that ELRepo will not address this vulnerability, and the mainstream couldn't care less, even as the vulnerability has been reported back in January. FYI, Red Hat has only rated this as a moderate impact. RHEL7, CentOS 7, RHEL 8.6 EUS, 8.8 EUS, 9.2 EUS have received patched kernels. There are no released patches for RHEL 8.9 and 9.3. AlmaLinux has pushed kernel patches for 8.9 and 9.3 to the testing repo, and plans to push it to production on Wednesday, April 3rd. https://jonathanspw.com/posts/2024-03-31-dealing-with-cve-2024-1086/ This leaves people using kernel-lt more vulnerable than those using the official EL kernels. Should the official kernel.org refuse to address this issue, is there any way for you to manage to patch the LT kernel, even if you are not a kernel developer? | ||||
Tags | No tags attached. | ||||
|
While we can technically apply patches to the kernel, it is our policy to not modify the source code. Therefore the fix must come from our upstream, kernel.org. |
|
kernel-lt for el9 was actually fixed as of 6.1.76. |
|
It is not listed in the changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.76 Where did you find this information? There is no CVE-2024-* listed in *any* changelog for 6.1. |
|
Look for : commit 8e34430e33b8a80bc014f3efe29cac76bc30a4b4 in the changelog. Also you can check (line 10448 onward): https://elixir.bootlin.com/linux/v6.1.76/source/net/netfilter/nf_tables_api.c |
|
See also: https://bugzilla.redhat.com/show_bug.cgi?id=2262126#c0 A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660 https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660 |
|
OK, thx, I can see it was backported to v6.1.76~61. But this is ridiculous *not* to mention in the changelog that this fixes a CVE! So it can be closed, thanks again. |
|
Oh, it's mentioned w/o the CVE number: netfilter: nf_tables: reject QUEUE/DROP verdict parameters commit f342de4e2f33e0e39165d8639387aa6c19dff660 upstream. |
|
Now closing. |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-04-02 13:45 | ludditus | New Issue | |
2024-04-02 13:45 | ludditus | Status | new => assigned |
2024-04-02 13:45 | ludditus | Assigned To | => toracat |
2024-04-02 14:00 | toracat | Note Added: 0009641 | |
2024-04-02 14:39 | toracat | Note Added: 0009642 | |
2024-04-02 14:42 | ludditus | Note Added: 0009643 | |
2024-04-02 14:47 | toracat | Note Added: 0009644 | |
2024-04-02 14:50 | toracat | Note Added: 0009645 | |
2024-04-02 14:52 | ludditus | Note Added: 0009646 | |
2024-04-02 14:54 | ludditus | Note Added: 0009647 | |
2024-04-02 15:00 | toracat | Status | assigned => closed |
2024-04-02 15:00 | toracat | Resolution | open => no change required |
2024-04-02 15:00 | toracat | Note Added: 0009648 |