Bugzilla – Bug 988153
VUL-0: CVE-2016-6136: kernel-source: Double-Fetch Vulnerability in Linux-4.6/kernel/auditsc.c
Last modified: 2022-05-16 08:48:17 UTC
Created attachment 683480 [details]
code attached to https://www.redhat.com/archives/linux-audit/2016-June/msg00029.html
> In function audit_log_single_execve_arg(), the whole argument is
> fetched from user space twice via copy_from_user(). In the first loop,
> it is firstly fetched (line 1038) to verify, aka looking for non-ascii
> chars. While in the second loop, the whole argument is fetched again
> (line 1105) from user space and used at line 1121 and line 1123
> respectively depends on the previous verification.
> However, a double fetch problem happens when the user space fetched
> data is changed by a concurrently running user thread under race
> condition during the verification and the usage, and the data
> inconsistency will cause serious problems. In this case, the verified
> non-ascii argument from the first loop is likely to be changed to an
> ascii one (i.e. containing ‘ “ ’) which will be used in the second
> loop. Then the argument is passed to audit_log_string() as none-ascii,
> then move forward in audit_log_n_string() of file audit.c, the string
> is enclosed with quote marks as well. Since the string contains
> another quote mark in the middle, problems will happen when processing
> the string based on quote mark, e.g. the string will be recognized as
> a shorter one based on the middle quote mark. I believe other
> consequences are also likely to be caused once the none control string
> is treated as a control string, or vice versa, which is very likely to
> happen under double fetch situations.
> Looking at this a bit more, we should be doing a strncpy_from_user() at
> the top of audit_log_single_execve_arg() and the operating only from
> that copied buffer. In addition to resolving this issue, it should
> simplify the code quite a bit.
No patch just yet.
bugbot adjusting priority
Fix is in patches.kernel.org/patch-4.4.18-19 for SLES 12 SP2.
buggy code is in 3.12, 3.0, 2.6.32 too. 2.6.16 might not have it.
This was never ported back prior to stable-4.4
If the security team requires it be ported back to 3.x, LMK.
As current audit maintainer, I'm taking over this one.
Should push it by the end of my day.
(In reply to Enzo Matsumiya from comment #16)
> Should push it by the end of my day.
Checking on the patch, it would require several other commits for cve/linux-3.0, which would be somewhat invasive (some of them breaks kABI, for example).
I didn't check for older branches, but the assumption is that it would be as much as invasive.
Also, this CVE has SUSE CVSSv3 5.3 (NVD 4.7), which IIRC is not eligible for LTSS.
Please let me know if this is *really* required.
The 3.0 kernels won't be fixed since backporting the fix will probably break kABI. Closing.