Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Glusterfs libgfapi engine #7

Closed
wants to merge 10 commits into from
Closed

Glusterfs libgfapi engine #7

wants to merge 10 commits into from

Conversation

rootfs
Copy link
Contributor

@rootfs rootfs commented Apr 3, 2014

Hi,

Please review the following updates. More details available at the following gluster-devel mailing list.
http://lists.nongnu.org/archive/html/gluster-devel/2014-03/msg00189.html

Thanks
HC

@axboe
Copy link
Owner

axboe commented May 19, 2014

Pulled, thanks! In the future, please notify me and the fio list of such pull requests, otherwise I might not see them for a while...

@axboe axboe closed this May 19, 2014
lukaszstolarczuk pushed a commit to lukaszstolarczuk/fio that referenced this pull request Sep 15, 2020
sitsofe added a commit to sitsofe/fio that referenced this pull request Jan 15, 2021
Google's OSS-fuzz turned up a heap overrun when substituting keywords in
job files. To reproduce compile fio with address sanitizer options like
the following

LDFLAGS="-fsanitize=address" ./configure --disable-optimizations \
  --extra-cflags="-fsanitize=address"

The issue is demonstrated by the following job:

% printf '[t]\ndescription=$ncpus_' | fio --parse-only -
opt = 'description=$ncpus'
=================================================================
==22547==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000001863 at pc 0x000107a833c9 bp 0x7ffee82ac260 sp 0x7ffee82ac258
READ of size 1 at 0x603000001863 thread T0
    #0 0x107a833c8 in fio_keyword_replace options.c:5124
    axboe#1 0x107a7c6ab in dup_and_sub_options options.c:5158
    axboe#2 0x107a7bb4f in fio_options_parse options.c:5203
    axboe#3 0x1079b2214 in __parse_jobs_ini init.c:2076
    axboe#4 0x1079aff07 in parse_jobs_ini init.c:2127
    axboe#5 0x1079b7501 in parse_options init.c:2989
    axboe#6 0x107b876a4 in main fio.c:42
    axboe#7 0x7fff702f1cc8 in start (libdyld.dylib:x86_64+0x1acc8)

Fix the thinko (because opt is pointing to a later position) and
rearrange some code to make it clearer that olen is being used as an
initial offset

Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
sitsofe added a commit to sitsofe/fio that referenced this pull request Jan 16, 2021
Google's OSS-fuzz turned up a buffer overrun with value of the filename
option due to an overrun in a MAX_PATH sized buffer. To reproduce
compile fio with address sanitizer options like the following

LDFLAGS="-fsanitize=address" ./configure --disable-optimizations \
      --extra-cflags="-fsanitize=address"

The issue is demonstrated by the following job:

% COUNT=$(getconf PATH_MAX /); printf "[t]\nfilename=%${COUNT}s" \
  | sed 's/ /@/g' | fio --parse-only -
=================================================================
==45748==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee8e35780 at pc 0x00010735a343 bp 0x7ffee8e35270 sp 0x7ffee8e34a08
WRITE of size 1025 at 0x7ffee8e35780 thread T0
    #0 0x10735a342 in wrap_vsprintf (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x22342)
    axboe#1 0x10735a9ac in wrap_sprintf (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x229ac)
    axboe#2 0x106e83b01 in add_file filesetup.c:1656
    axboe#3 0x106ee8c87 in str_filename_cb options.c:1320
    axboe#4 0x106ee1b44 in __handle_option parse.c:792
    axboe#5 0x106ed99ad in handle_option parse.c:1014
    axboe#6 0x106eda07d in parse_option parse.c:1184
    axboe#7 0x106ef10ea in fio_options_parse options.c:5199
    axboe#8 0x106e27684 in __parse_jobs_ini init.c:2076
    axboe#9 0x106e25377 in parse_jobs_ini init.c:2127
    axboe#10 0x106e2c971 in parse_options init.c:2989
    axboe#11 0x106ffc884 in main fio.c:42
    axboe#12 0x7fff702f1cc8 in start (libdyld.dylib:x86_64+0x1acc8)

Address 0x7ffee8e35780 is located in stack of thread T0 at offset 1056 in frame
    #0 0x106e836ef in add_file filesetup.c:1644

  This frame has 1 object(s):
    [32, 1056) 'file_name' (line 1646) <== Memory access at offset 1056 overflows this variable

Return an error message to the user by doing the following:

- Allow "regular" string options to have a maxlen parameter
- Set the filename option to have a maxlen of MAX_PATH

Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants