Bugzilla – Bug 1226855
VUL-0: CVE-2024-38612: kernel: ipv6: sr: fix invalid unregister error path
Last modified: 2024-07-02 11:28:12 UTC
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-38612 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-38612.mbox https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7 https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4 https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01 https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925 https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66 https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4 https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45 https://www.cve.org/CVERecord?id=CVE-2024-38612 https://bugzilla.redhat.com/show_bug.cgi?id=2293351
The formulation This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. in the commit message is rather confusing so I checked both commits and also the SLE15-SP6 code (which lacks commit 5559cea2d5aa) and it seems that the issue was in fact introduced by 5559cea2d5aa (in 6.8-rc6) rather than by 46738b1317e1 (in 4.10-rc1). I'm going to recheck again tomorrow to be sure.