Custom Query (733 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 733)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#831 fixed stack-buffer-overflow when starting Singular built with sanitize flags somebody Lars Kastner <lars.kastner@…>
Description

We configured Singular with

CXXFLAGS="-std=c++14 -stdlib=libc++ -O1 -g -fno-omit-frame-pointer -L${ASAN_PATH}/installed/mpfr/lib64 -fsanitize=address -fsanitize-address-use-after-scope -fno-sanitize=enum,vptr" LDFLAGS="-stdlib=libc++ -Wl,-rpath,${ASAN_PATH}/installed/ntl/lib -Wl,-rpath,${ASAN_PATH}/installed/mpfr/lib64" CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address -fsanitize-address-use-after-scope -fno-sanitize=enum,vptr"

i.e. with sanitize flags. Then after building we get the following error at startup:

kastner@marvin:~/local/asan/installed/singular_broken/bin> ./Singular 
=================================================================
==25997==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd31dc16ca at pc 0x00000052b44b bp 0x7ffd31dc1550 sp 0x7ffd31dc0d00
WRITE of size 11 at 0x7ffd31dc16ca thread T0
    #0 0x52b44a in scanf_common(void*, int, bool, char const*, __va_list_tag*) /homes/combi/kastner/local/asan/llvm-6.0.0-src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:343
    #1 0x52c0f5 in vsscanf /homes/combi/kastner/local/asan/llvm-6.0.0-src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1408
    #2 0x52c1e2 in sscanf /homes/combi/kastner/local/asan/llvm-6.0.0-src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1432
    #3 0x662618 in make_version(char*, int) /homes/combi/kastner/local/asan/singular-sources/Singular/libparse.l
    #4 0x65f1bc in yylplex(char const*, char const*, lib_style_types*, idrec*, int, lp_modes) /homes/combi/kastner/local/asan/singular-sources/Singular/libparse.l:264:16
    #5 0x62a079 in iiLoadLIB(_IO_FILE*, char const*, char const*, idrec*, int, int) /homes/combi/kastner/local/asan/singular-sources/Singular/iplib.cc:931:3
    #6 0x6287a7 in iiLibCmd(char*, int, int, int) /homes/combi/kastner/local/asan/singular-sources/Singular/iplib.cc:861:16
    #7 0x67052e in siInit(char*) /homes/combi/kastner/local/asan/singular-sources/Singular/misc_ip.cc:1465:5
    #8 0x5b74f4 in main /homes/combi/kastner/local/asan/singular-sources/Singular/tesths.cc:70:3
    #9 0x1479befb7724 in __libc_start_main (/lib64/libc.so.6+0x20724)
    #10 0x4b7428 in _start /home/abuild/rpmbuild/BUILD/glibc-2.22/csu/../sysdeps/x86_64/start.S:118

Address 0x7ffd31dc16ca is located in stack of thread T0 at offset 42 in frame
    #0 0x6624af in make_version(char*, int) /homes/combi/kastner/local/asan/singular-sources/Singular/libparse.l:847

  This frame has 2 object(s):
    [32, 42) 'ver' (line 848) <== Memory access at offset 42 overflows this variable
    [64, 80) 'date' (line 849)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /homes/combi/kastner/local/asan/llvm-6.0.0-src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:343 in scanf_common(void*, int, bool, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
  0x1000263b0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000263b0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000263b02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000263b02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000263b02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000263b02d0: 00 00 00 00 f1 f1 f1 f1 00[02]f2 f2 00 00 f3 f3
  0x1000263b02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000263b02f0: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x1000263b0300: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x1000263b0310: f8 f8 f8 f8 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00
  0x1000263b0320: 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
==25997==ABORTING

Benjamin Lorenz suggests the following fix

diff --git a/Singular/libparse.cc b/Singular/libparse.cc
index ee5876d88..738405e38 100644
--- a/Singular/libparse.cc
+++ b/Singular/libparse.cc
@@ -3383,8 +3383,8 @@ void reinit_yylp()
 
 void make_version(char *p,int what)
 {
-  char ver[10];
-  char date[16];
+  char ver[11];
+  char date[17];
   ver[0]='?'; ver[1]='.'; ver[2]='?'; ver[3]='\0';
   date[0]='?'; date[1]='\0';
   if(what) sscanf(p,"%*[^=]= %*s %*s %10s %16s",ver,date);
diff --git a/Singular/libparse.ll b/Singular/libparse.ll
index 101eece80..600f09869 100644
--- a/Singular/libparse.ll
+++ b/Singular/libparse.ll
@@ -845,8 +845,8 @@ void reinit_yylp()
 
 void make_version(char *p,int what)
 {
-  char ver[10];
-  char date[16];
+  char ver[11];
+  char date[17];
   ver[0]='?'; ver[1]='.'; ver[2]='?'; ver[3]='\0';
   date[0]='?'; date[1]='\0';
   if(what) sscanf(p,"%*[^=]= %*s %*s %10s %16s",ver,date);

If I understand correctly, then this is due to the following part of man sscanf:

s      Matches a sequence of non-white-space characters; the next pointer must be  a
       pointer to character array that is long enough to hold the input sequence and
       the terminating null byte ('\0'), which is added  automatically.   The  input
       string  stops  at white space or at the maximum field width, whichever occurs
       first.
#830 not a bug rings returned via parallel.lib do not remember their objects somebody ren
Description

While parallelizing my code for tropical geometry, I realized that rings returned from a function called via parallel.lib do not remember their members. Is this something that is easily fixable within the current framework?

proc ttt() { ring r; ideal I; export(I); return(r); }
def r = ttt();
setring r;
listvar(); // contains I

LIB "parallel.lib";
list out = parallelWaitAll("ttt",list(list()));
def s = out[1];
setring s;
listvar(); // no I
#829 not a bug std in Singular 4.1.1 not terminating for a working example in Singular 4.1.0 somebody ren
Description

The enclosed Groebner basis computation terminates within minutes in Singular 4.1.0, but gets stuck indefinitely in Singular 4.1.1 (latest spielwiese version) at the following step of the prot output:

bash-3.2$ Singular example.sing
                     SINGULAR                                 /  Development
 A Computer Algebra System for Polynomial Computations       /   version 4.1.1
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   Feb 2018
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \
std in (101,d1,d2,d3,d4,d5,d6),(E1,E2,E3,E4,E5,E6,F12,F13,F14,F15,F16,F23,F24,F25,F26,F34,F35,F36,F45,F46,F56,G1,G2,G3,G4,G5,G6),(dp(27),C)
[3:1]2(269)s(268)ss(269)s(268)ss(270)s(272)--s(273)--s(270)--s(268)--s--s(269)--s(270)-----s(264)-----s(259)-----s(256)-----s(254)-----s(253)-----s(249)s(251)s(254)s(258)s(263)s(269)s--s(268)--s(270)s(273)--s(277)s(284)s-----s(280)-----ss(283)-----s(285)s(293)s(296)--s(299)--s(302)--(300)s(307)--s(314)s(320)s(323)-----s(324)--s(327)-----s(330)--s(338)s(345)s(350)-----s(351)-----s(353)-----s(356)-----s(363)s(370)s(380)s(386)--s(392)--s(399)--s(403)--s(407)-----s(411)--s(419)--s(424)--s(430)-----s(434)-----s(441)--s(447)s(457)--s(464)-----s(469)-----s(476)-----s(481)--s(490)--s(494)-----s(496)-----s(500)s(510)-----s(516)--s(525)-----s(531)-----s(538)----3-----------------------s(517)s(524)s(535)s(542)s(550)s(562)s(574)---------s(573)---------------s(567)---s(575)s(587)-----s(593)------s(599)-s(611)s(620)-s(629)-s(640)-s(649)-s(659)-s(672)-s(685)s(701)-(700)----s(709)---s(717)-s(729)------------------------s(717)-s(729)s(739)-s(749)-s(762)-s(777)-------s(784)---s(792)-s(805)-----(800)-s(811)----------s(814)-----------s(818)---s(826)-s(840)------s(846)------s(853)--------------------------s(839)s(855)---------s(860)s(875)-------------s(877)s(893)---------s(900)s(917)-------s(928)-----------------s(926)----------------s----
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.