| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2025022628-CVE-2022-49697-db0b@gregkh> Date: Wed, 26 Feb 2025 03:24:20 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: CVE-2022-49697: bpf: Fix request_sock leak in sk lookup helpers Description =========== In the Linux kernel, the following vulnerability has been resolved: bpf: Fix request_sock leak in sk lookup helpers A customer reported a request_socket leak in a Calico cloud environment. We found that a BPF program was doing a socket lookup with takes a refcnt on the socket and that it was finding the request_socket but returning the parent LISTEN socket via sk_to_full_sk() without decrementing the child request socket 1st, resulting in request_sock slab object leak. This patch retains the existing behaviour of returning full socks to the caller but it also decrements the child request_socket if one is present before doing so to prevent the leak. Thanks to Curtis Taylor for all the help in diagnosing and testing this. And thanks to Antoine Tenart for the reproducer and patch input. v2 of this patch contains, refactor as per Daniel Borkmann's suggestions to validate RCU flags on the listen socket so that it balances with bpf_sk_release() and update comments as per Martin KaFai Lau's suggestion. One small change to Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra instruction. The Linux kernel CVE team has assigned CVE-2022-49697 to this issue. Affected and fixed versions =========================== Issue introduced in 5.2 with commit edbf8c01de5a104a71ed6df2bf6421ceb2836a8e and fixed in 5.4.202 with commit 8ffe2e50e9678c8373027492035f094b130437f1 Issue introduced in 5.2 with commit edbf8c01de5a104a71ed6df2bf6421ceb2836a8e and fixed in 5.10.127 with commit 516760f1d2979903eaad5b437256913c5cd98416 Issue introduced in 5.2 with commit edbf8c01de5a104a71ed6df2bf6421ceb2836a8e and fixed in 5.15.51 with commit b03607437ea81b850599f705096b05b85e7a4a71 Issue introduced in 5.2 with commit edbf8c01de5a104a71ed6df2bf6421ceb2836a8e and fixed in 5.18.8 with commit 5a62b5ba4c0ce8315b6382cd4ace81b48cd121cd Issue introduced in 5.2 with commit edbf8c01de5a104a71ed6df2bf6421ceb2836a8e and fixed in 5.19 with commit 3046a827316c0e55fc563b4fb78c93b9ca5c7c37 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2022-49697 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: net/core/filter.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/8ffe2e50e9678c8373027492035f094b130437f1 https://git.kernel.org/stable/c/516760f1d2979903eaad5b437256913c5cd98416 https://git.kernel.org/stable/c/b03607437ea81b850599f705096b05b85e7a4a71 https://git.kernel.org/stable/c/5a62b5ba4c0ce8315b6382cd4ace81b48cd121cd https://git.kernel.org/stable/c/3046a827316c0e55fc563b4fb78c93b9ca5c7c37
Powered by blists - more mailing lists