Bug 988153 - (CVE-2016-6136) VUL-0: CVE-2016-6136: kernel-source: Double-Fetch Vulnerability in Linux-4.6/kernel/auditsc.c
VUL-0: CVE-2016-6136: kernel-source: Double-Fetch Vulnerability in Linux-4.6/...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2016-07-08 08:00 UTC by Andreas Stieger
Modified: 2022-05-16 08:48 UTC (History)
9 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
mhocko: needinfo? (hhetter)

code attached to https://www.redhat.com/archives/linux-audit/2016-June/msg00029.html (33.74 KB, application/zip)
2016-07-08 08:00 UTC, Andreas Stieger

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Stieger 2016-07-08 08:00:17 UTC
Created attachment 683480 [details]
code attached to https://www.redhat.com/archives/linux-audit/2016-June/msg00029.html


From 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.

From https://github.com/linux-audit/audit-kernel/issues/18

> 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.

Comment 1 Andreas Stieger 2016-07-08 08:05:03 UTC
No patch just yet.
Comment 3 Swamp Workflow Management 2016-07-08 22:00:31 UTC
bugbot adjusting priority
Comment 5 Marcus Meissner 2017-03-02 10:58:47 UTC
Fix is in patches.kernel.org/patch-4.4.18-19 for SLES 12 SP2.
Comment 6 Marcus Meissner 2017-03-02 11:02:49 UTC
buggy code is in 3.12, 3.0, 2.6.32 too. 2.6.16 might not have it.
Comment 11 Tony Jones 2020-02-06 00:00:05 UTC
This was never ported back prior to stable-4.4

If the security team requires it be ported back to 3.x,  LMK.
Comment 16 Enzo Matsumiya 2022-05-10 15:08:00 UTC
As current audit maintainer, I'm taking over this one.

Should push it by the end of my day.
Comment 17 Enzo Matsumiya 2022-05-10 17:36:16 UTC
(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.
Comment 19 Gabriele Sonnu 2022-05-11 07:28:47 UTC
The 3.0 kernels won't be fixed since backporting the fix will probably break kABI. Closing.