Bug 33730 - sscanf crashes
Summary: sscanf crashes
Status: RESOLVED DUPLICATE of bug 12701
Alias: None
Product: glibc
Classification: Unclassified
Component: stdio (show other bugs)
Version: 2.41
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-20 02:51 UTC by Fred Tydeman
Modified: 2025-12-22 17:59 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Tydeman 2025-12-20 02:51:01 UTC
This program:
#include <assert.h>
#include <limits.h>
#include <errno.h>
#include <stdio.h>
#include <float.h>
#include <fenv.h>
#include <complex.h>
#include <math.h>

#pragma STDC FENV_ACCESS ON
#pragma STDC FP_CONTRACT OFF
#pragma STDC FENV_ROUND FE_TONEAREST
#pragma STDC FENV_DEC_ROUND FE_DEC_TONEAREST
#pragma STDC CX_LIMITED_RANGE OFF

int main(void){

  if(1){
    double d35 = -1.;
    int i35 = -1;
    int count = -1;
    char string[8] = "1234567";
    i35 = sscanf("junk()", "%le%n%8s", &d35, &count, string );
    (void)printf("Results for known junk\n");
    (void)printf("i35=%i\n", i35);
    (void)printf("d35=%g\n", d35);
    (void)printf("count=%i\n", count);
    (void)printf("string='%s'\n", string);

    // gcc.x86_64 15.2.1-5.fc42 updates 
    // libc.x86_64 2.41-11.fc42 updates => crash on next sscanf
    (void)printf("\nBad results for bad hex floating point\n");
    i35 = sscanf("100ergs", "%le%n%8s", &d35, &count, string );
    (void)printf("i35=%i\n", i35);
    (void)printf("d35=%g\n", d35);
    (void)printf("count=%i\n", count);
    (void)printf("string='%s'\n", string);
  }
  return 0;
}

With these commmand line options:

# flags common to both compiler and linker
export CLFLAGS="\
 -fsanitize=undefined \
 -fsanitize=address \
 -fsanitize=bounds-strict \
 -fstack-protector-all"
# flags for compiler
export CFLAGS="-H -std=c23 -O0 -march=native -mhard-float -mfpmath=387 -mieee-fp \
 -enable-decimal-float=yes \
 -fexcess-precision=standard \
 -ffp-contract=off \
 -fmath-errno \
 -fno-associative-math \
 -fno-builtin \
 -fno-cx-limited-range \
 -fno-fast-math \
 -fno-finite-math-only \
 -fno-reciprocal-math \
 -fno-unsafe-math-optimizations \
 -frounding-math \
 -fsignaling-nans \
 -fsigned-zeros \
 -ftrapping-math \
 ${INCS} \
 -I/usr/include/dfp"

On Intel x86_64 with Fedora Linux 42

gets this output:

=================================================================
==2232==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7beaa6000068 at pc 0x7feaa946fabc bp 0x7fff57078be0 sp 0x7fff570783a0
WRITE of size 9 at 0x7beaa6000068 thread T0
    #0 0x7feaa946fabb in scanf_common(void*, int, bool, char const*, __va_list_tag*) (/lib64/libasan.so.8+0x6fabb) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7feaa94b01d8 in __isoc23_vsscanf (/lib64/libasan.so.8+0xb01d8) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #2 0x7feaa94b099c in __isoc23_sscanf (/lib64/libasan.so.8+0xb099c) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #3 0x00000040076f in main (/lindata/fpcets/gcc64/1521/c87/test188.exe+0x40076f) (BuildId: ba11d9a55566bd9b1a737e9564621feebed9d7d3)
    #4 0x7feaa8611574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
    #5 0x7feaa8611627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 48c4b9b1efb1df15da8e787f489128bf31893317)
    #6 0x000000400454 in _start (/lindata/fpcets/gcc64/1521/c87/test188.exe+0x400454) (BuildId: ba11d9a55566bd9b1a737e9564621feebed9d7d3)

Address 0x7beaa6000068 is located in stack of thread T0 at offset 104 in frame
    #0 0x000000400525 in main (/lindata/fpcets/gcc64/1521/c87/test188.exe+0x400525) (BuildId: ba11d9a55566bd9b1a737e9564621feebed9d7d3)

  This frame has 3 object(s):
    [48, 52) 'count' (line 21)
    [64, 72) 'd35' (line 19)
    [96, 104) 'string' (line 22) <== Memory access at offset 104 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lindata/fpcets/gcc64/1521/c87/test188.exe+0x40076f) (BuildId: ba11d9a55566bd9b1a737e9564621feebed9d7d3) in main
Shadow bytes around the buggy address:
  0x7beaa5fffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa5fffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa5fffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa5ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa5ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7beaa6000000: f1 f1 f1 f1 f1 f1 04 f2 00 f2 f2 f2 00[f3]f3 f3
  0x7beaa6000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa6000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa6000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa6000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7beaa6000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2232==ABORTING
Comment 1 Fred Tydeman 2025-12-20 03:00:08 UTC
Note, with glibc 2.42-5, there is no crash.
And, the output is correct.
Comment 2 Adhemerval Zanella 2025-12-22 17:59:20 UTC
Fixed by 0a8e7ac95c69499959151f29c65fc112f09d3973.

*** This bug has been marked as a duplicate of bug 12701 ***