[Bug sanitizer/111620] [RISC-V]fsanitize is not working with c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111620
--- Comment #2 from Akhilesh Kumar ---
with 110036 (CHECK failed) issue is fixed, but Even after patch ASAN unable to
detect corruption like "Use_after_free(heap)","Heap buffer overflow","Stack
buffer overflow" and "Use after scope"
some features like "Double Free" and "Memory leaks" are working after 110036
In all corruption scenarios I am getting "DEADLYSIGNAL"
Seems program jumped to some wild address, which is unknown to AddressSanitizer
#include
using namespace std;
int main()
{
int *p=new int;
delete p;
cout<<*p<
[Bug sanitizer/111620] New: [RISC-V]fsanitize is not working with cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111620
Bug ID: 111620
Summary: [RISC-V]fsanitize is not working with cpp
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello
During ASAN verification I observed most of the ASAN is not working for cpp
sharing logs and sample code.
user@starfive:~/akhilesh/asan$ g++ print.cpp -fsanitize=address
user@starfive:~/akhilesh/asan$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==17785==ERROR: AddressSanitizer: SEGV on unknown address 0x00081f468e44 (pc
0x002ae2626c74 bp 0x003ffa3472e0 sp 0x003ffa347210 T0)
==17785==The signal is caused by a WRITE memory access.
#0 0x2ae2626c74 in main (/home/user/akhilesh/asan/a.out+0xc74)
#1 0x3fbdac4b02 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#2 0x3fbdac4baa in __libc_start_main_impl csu/libc-start.c:381
#3 0x2ae2626b6e in _start (/home/user/akhilesh/asan/a.out+0xb6e)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/user/akhilesh/asan/a.out+0xc74) in main
==17785==ABORTING
user@starfive:~/akhilesh/asan$ cat print.cpp
#include
using namespace std;
int main()
{
int arr[10];
arr[5]=8;
cout<
using namespace std;
int main()
{
cout << "Hello";
return 0;
}
=run time logs===
ser@starfive:~/akhilesh/asan$ g++ -g use_after_free.cpp -fsanitize=address
user@starfive:~/akhilesh/asan$ ./a.out
AddressSanitizer: CHECK failed: asan_poisoning.cpp:36 "((AddrIsInMem(addr))) !=
(0)" (0x0, 0x0) (tid=17449)
#0 0x3fb771805c in CheckUnwind
../../../../src/libsanitizer/asan/asan_rtl.cpp:67
#1 0x3fb7730a3a in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86
#2 0x3fb7711dca in __asan::PoisonShadow(unsigned long, unsigned long,
unsigned char) ../../../../src/libsanitizer/asan/asan_poisoning.cpp:36
#3 0x3fb76a2e36 in __asan::AsanMapUnmapCallback::OnMap(unsigned long,
unsigned long) const ../../../../src/libsanitizer/asan/asan_allocator.cpp:246
#4 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::MapWithCallback(unsigned long, unsigned long, char const*)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:717
#5 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::MapWithCallback(unsigned long, unsigned long, char const*)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:709
#6 0x3fb76a2e36 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned long,
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::RegionInfo*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:798
#7 0x3fb76a3246 in
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned long, unsigned int*,
unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:220
#8 0x3fb76a32bc in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
> >::PerClass*,
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:103
#9 0x3fb76a353c in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:39
#10 0x3fb76a353c in
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>,
__sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
> >*, unsigned long, unsigned long)
[Bug libstdc++/111323] New: [RISC_V] During Insmod "unknown relocation type 57" type in kernel space observed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111323
Bug ID: 111323
Summary: [RISC_V] During Insmod "unknown relocation type 57"
type in kernel space observed
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
Target Milestone: ---
Hello
with gcc 13.1 open source RISC-V Toolchain I observed "unknown relocation type
57" error message during insmod my kernel modules it seems this issue could
occurs in RISC-V when we try to assemble or link a program, and the toolchain
encounters a relocation type that it doesn't recognize or support.
as per latest kernel 6.1 (which i am using code) doesn't support RELOC_NUMBER
(R_RISCV_32_PCREL, 57) .
Here is my sample driver makefile
=
CFLAGSÂ +=-std=gnu11 #with this option getting "unknown relocation type 57"
obj-m := hello.o
hello-y := hello.o
all:
make -C ${KDIR} M=$(PWD) modules
clean:
make -C ${KDIR} M=$(PWD) clean
My dummy drive hello.c
#include
#include
int init_module(void) { printk(KERN_INFO "Hello
world.\n"); return 0; }
void cleanup_module(void) { printk(KERN_INFO "Goodbye
world.\n"); }
MODULE_LICENSE("GPL");
==
Using -std=gnu11 with gcc 13 generates R_RISCV_SET6 relocation in eh_frame
section which is not generated without -std=gnu11 flag even with same compiler
optimisations:
My insmod logs
=
/bin # insmod hello.ko
[ 11.807337] hello: loading out-of-tree module taints kernel.
[ 11.809680] hello: Unknown relocation type 57
insmod: can't insert 'hello.ko': invalid parameter
=
readelf output with -std=gnu11
Relocation section '.rela.eh_frame' at offset 0xb08 contains 10 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
001c 001e0039 R_RISCV_32_PCREL .L0 + 0
0020 001f0023 R_RISCV_ADD32 0022 .L0 + 0
0020 001e0027 R_RISCV_SUB32 .L0 + 0
0031 00200035 R_RISCV_SET6 001a .L0 + 0
0031 00210034 R_RISCV_SUB6 0008 .L0 + 0
0044 00220039 R_RISCV_32_PCREL 0022 .L0 + 0
0048 00230023 R_RISCV_ADD32 0042 .L0 + 0
0048 00220027 R_RISCV_SUB32 0022 .L0 + 0
0059 00240035 R_RISCV_SET6 003c .L0 + 0
0059 00250034 R_RISCV_SUB6 002a .L0 + 0
readelf output without -std=gnu11
Relocation section '.rela.text.unlikely' at offset 0x920 contains 6 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
0008 00190017 R_RISCV_PCREL_HI2 .LC0 + 0
000c 001a0018 R_RISCV_PCREL_LO1 0008 .L0 + 0
0010 00200013 R_RISCV_CALL_PLT _printk + 0
002a 001b0017 R_RISCV_PCREL_HI2 0010 .LC1 + 0
002e 001c0018 R_RISCV_PCREL_LO1 002a .L0 + 0
0032 00200013 R_RISCV_CALL_PLT _printk +
As a workaround i have two options either remove -std=gnu11 and use default
standards (-std=gnu17) or use KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables option
but my query is why such relocations are generated with -std=gnu11
[Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
Bug ID: 97941
Summary: [HWASAN] use After free not working as per expectation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello Matthew
While HWASAN verification feature, Source I taken from GCC11 trunk.
I observed Some HWASAN features are not working as per expectation.
Like use After free, Is this known behaviors/Issue ?
int main() {
char *x = (char*)malloc(10 * sizeof(char*));
free(x);
return x[5];
}
./myhak
HWAddressSanitizer:DEADLYSIGNAL
==1227==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0030 (pc
0x004096c8 bp 0x005f00ae9fe0 sp 0x005f00ae8d10 T1227)
==1227==The signal is caused by a UNKNOWN memory access.
==1227==Hint: address points to the zero page.
#0 0x4096c8 in GetAccessInfo
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
#1 0x4096c8 in HwasanOnSIGTRAP
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:445
#2 0x4096c8 in __hwasan::HwasanOnDeadlySignal(int, void*, void*)
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:470
#3 0x5f00ae9fec ()
#4 0x406918 in __hwasan_load1
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan.cpp:446
#5 0x43815c in main
(/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x43815c)
#6 0x55009830a0 in __libc_start_main ../csu/libc-start.c:308
#7 0x4023c4 (/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x4023c4)
HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
in GetAccessInfo
==1227==ABORTING
