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

Jump to bottom

ASan allows incorrect reordering of memory accesses #36

Closed
ramosian-glider opened this issue Aug 31, 2015 · 5 comments
Closed

ASan allows incorrect reordering of memory accesses #36

ramosian-glider opened this issue Aug 31, 2015 · 5 comments
Labels
Priority-Medium ProjectAddressSanitizer Status-Invalid Type-Defect

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 36

This is a piece of Chromium code on Mac:


(gdb) disas $eip $eip+0x20
Dump of assembler code from 0x5e62b97 to 0x5e62bb7:
0x05e62b97 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+439>:  mov
   0x1c(%esp),%eax
0x05e62b9b <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+443>:  lea
   0x7006f69(%eax),%eax
0x05e62ba1 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+449>:  mov
   %eax,%ecx
0x05e62ba3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+451>:  shr
   $0x3,%ecx
0x05e62ba6 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+454>:  mov
   0x20000000(%ecx),%cl
0x05e62bac <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+460>:  mov
   0x1c0(%esp),%edx
0x05e62bb3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+467>:  test
  %cl,%cl
0x05e62bb5 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+469>:  je
    0x5e62bc0 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+480>
End of assembler dump.

Note that the access to the original memory location (0x1c0(%esp)) occurs before the
shadow value is actually tested.
Such bugs may potentially cause the program to crash before the error is reported (if
we're accessing an unmapped region)

Dima suspects this is because we're passing the result of ptrtoint() to the reporting
function, thus the compiler does not notice that the pointer escapes.

Reported by ramosian.glider on 2012-02-07 11:14:05
@ramosian-glider
Copy link
Member Author 

How did you find it? Do you have a source reproducer?

Reported by konstantin.s.serebryany on 2012-02-07 17:48:13

@ramosian-glider
Copy link
Member Author 

I was just debugging a (non-existing) hang in Chrome.
I have a repro of ~300 lines that produces almost the same code:


     1b7:       8b 44 24 1c             mov    0x1c(%esp),%eax
     1bb:       8d 80 69 35 02 00       lea    0x23569(%eax),%eax
     1c1:       89 c1                   mov    %eax,%ecx
     1c3:       c1 e9 03                shr    $0x3,%ecx
     1c6:       8a 89 00 00 00 20       mov    0x20000000(%ecx),%cl
     1cc:       8b 94 24 c0 01 00 00    mov    0x1c0(%esp),%edx

, which corresponds to the following assembly:

Ltmp14:
LBB0_3:                                 ## %if.else
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  .loc  2 214 0                 ## browser.ii:214:0
  movl  %esi, %eax
  shrl  $3, %eax
  movb  536870912(%eax), %al
  testb %al, %al
  jne LBB0_32
LBB0_4:
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  movl  28(%esp), %eax          ## 4-byte Reload
  leal  __ZN12_GLOBAL__N_123g_shutdown_pipe_read_fdE-L0$pb(%eax), %eax
  movl  %eax, %ecx
  shrl  $3, %ecx
  movb  536870912(%ecx), %cl
  movl  448(%esp), %edx
Ltmp15:
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  testb %cl, %cl
  je  LBB0_6


But I'm not completely sure now that "movb  536870912(%ecx), %cl" and "movl  448(%esp),
%edx" access the shadow and the client memory for the same address.

Reported by ramosian.glider on 2012-02-08 09:20:16

@ramosian-glider
Copy link
Member Author 

So, there is not bug here, right?

Reported by konstantin.s.serebryany on 2012-02-24 22:56:35

  • Status changed: Invalid

@ramosian-glider
Copy link
Member Author 

Not sure yet. Let us leave this as an invalid bug, but keep in mind that we may miss
 a bug someday because of this.

Reported by ramosian.glider on 2012-02-28 11:04:40

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:58

  • Labels added: ProjectAddressSanitizer

@sarora5 sarora5 mentioned this issue Jun 12, 2019
Open
@oviano oviano mentioned this issue Mar 31, 2020
Open
@UjjwalChitransh UjjwalChitransh mentioned this issue Apr 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority-Medium ProjectAddressSanitizer Status-Invalid Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider