CWE
125
Advisory Published
CVE Published
CVE Published
Updated

CVE-2023-3773: Kernel: xfrm: out-of-bounds read of xfrma_mtimer_thresh nlattr

First published: Fri Jun 30 2023(Updated: )

========== 2. OOB read of XFRMA_MTIMER_THRESH nlattr ========== [require privilege]: CAP_NET_ADMIN [effects]: information leak [crash stack]: Interesting enough as this OOB read will not be detected by KASan (perhaps why this bug is not detected by the fuzzer), see the details below. [buggy commit]: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space") [root cause]: The mentioned commit above added one additional attribute named XFRMA_MTIMER_THRESH and described its type at compat_policy (net/xfrm/xfrm_compat.c). However, the author forgot to also describe it at xfrma_policy (net/xfrm/xfrm_user.c). Hence, this suppose NLA_U32 (4 bytes) value can be faked as empty (0 bytes) by a malicious user, which lead to 4 bytes overflow read when parsing nlattrs. The overall buffer skb is created at netlink_sendmsg(...). According to the code, it will add another 0x140 skb_shared_info data behind the skb data so this OOB will not be detected by KASan. To exploit this (see PoC part), one malicious user can spray the SLUB objects and then leverage this 4 bytes OOB read to leak the heap data into x->mapping_maxage (see xfrm_update_ae_params(...)), and leak it to userspace via copy_to_user_state_extra(...). [PoC code]: see attachment poc2.c. I have tested it in latest Linux with QEMU. (no effects in ubuntu thanks to CONFIG_INIT_ON_ALLOC_DEFAULT_ON) [suggest fix]: Just add the type description like below @@ -3035,6 +3035,7 @@ const struct nla_policy xfrma_policy[XFRMA_MAX+1] = { [XFRMA_SET_MARK] = { .type = NLA_U32 }, [XFRMA_SET_MARK_MASK] = { .type = NLA_U32 }, [XFRMA_IF_ID] = { .type = NLA_U32 }, + [XFRMA_MTIMER_THRESH] = { .type = NLA_U32 }, };

Credit: secalert@redhat.com secalert@redhat.com secalert@redhat.com

Affected SoftwareAffected VersionHow to fix
Redhat Enterprise Linux=8.0
Redhat Enterprise Linux=9.0
Fedoraproject Fedora
Linux Linux kernel
Debian Debian Linux=10.0
Debian Debian Linux=12.0
debian/linux
5.10.223-1
5.10.226-1
6.1.115-1
6.1.112-1
6.11.7-1
6.11.9-1

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Frequently Asked Questions

  • What is the severity of CVE-2023-3773?

    The severity of CVE-2023-3773 is medium.

  • What software is affected by CVE-2023-3773?

    Redhat Enterprise Linux 8.0 and 9.0, Fedoraproject Fedora, Linux Linux Kernel, and Debian Linux are affected by CVE-2023-3773.

  • How can a malicious user exploit CVE-2023-3773?

    A malicious user with CAP_NET_ADMIN privileges can exploit CVE-2023-3773 by causing an out-of-bounds read of XFRMA_MTIMER_THRESH, potentially leading to sensitive information leakage.

  • Is there a fix available for CVE-2023-3773?

    Yes, there are fixes available for CVE-2023-3773. Apply the relevant security updates provided by Redhat, Fedoraproject, Linux Kernel, or Debian.

  • Where can I find more information about CVE-2023-3773?

    You can find more information about CVE-2023-3773 at the following references: [Link 1](https://access.redhat.com/security/cve/CVE-2023-3773), [Link 2](https://bugzilla.redhat.com/show_bug.cgi?id=2218944), [Link 3](https://lore.kernel.org/all/20230723074110.3705047-1-linma@zju.edu.cn/T/#u).

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2024 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203