Bug 120681 - Double-Fetch bug in Linux-4.6/kernel/auditsc.c
Summary: Double-Fetch bug in Linux-4.6/kernel/auditsc.c
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: other_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-20 13:38 UTC by Pengfei Wang
Modified: 2016-06-20 13:38 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.6
Tree: Mainline
Regression: No


Attachments
source files (33.74 KB, application/zip)
2016-06-20 13:38 UTC, Pengfei Wang
Details

Description Pengfei Wang 2016-06-20 13:38:10 UTC
Created attachment 220681 [details]
source files

Hello,

I found this Double-Fetch bug in Linux-4.6.1/kernel/auditsc.c when I was examining the source code. 

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, i.e. 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.

I am looking forward to a reply to confirm this, thank you!


Kind regards
Pengfei

Note You need to log in before you can comment on or make changes to this bug.