Bug 2218944 (CVE-2023-3773)
| Summary: | CVE-2023-3773 kernel: xfrm: out-of-bounds read of XFRMA_MTIMER_THRESH nlattr | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
| Component: | vulnerability | Assignee: | Nobody <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | acaringi, allarkin, bhu, chwhite, crwood, dbohanno, ddepaula, debarbos, dfreiber, dvlasenk, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jferlan, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, kernel-mgr, kyoshida, ldoskova, lgoncalv, lzampier, nmurray, ptalbert, qzhao, rogbas, rrobaina, rvrbovsk, rysulliv, scweaver, sdubroca, security-response-team, tglozar, tyberry, vkumar, walters, wcosta, williams, wmealing, ycote, ymankad |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to cause a 4 byte out-of-bounds read of XFRMA_MTIMER_THRESH when parsing netlink attributes, leading to potential leakage of sensitive heap data to userspace.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2218949, 2218950, 2224005, 2224006, 2225630 | ||
| Bug Blocks: | 2219629 | ||
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2225630] This was fixed for Fedora with the 6.4.12 stable kernel updates. This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:6583 https://access.redhat.com/errata/RHSA-2023:6583 |
========== 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 }, };