1. 28 Dec, 2021 1 commit
    • Gauvain Roussel-Tarbouriech's avatar
      pine: OS bugs galore! · 53ef22d8
      Gauvain Roussel-Tarbouriech authored
      This has to be our strangest bug _yet_.
      pine expects a reply of up to MAX_IPC_RETURN_SIZE, which is fine when
      using standard commands as we reuse a buffer to avoid an allocation
      bottleneck or in batch commands that needs relocation, as we don't know
      the size AOT and allocate it to MAX anyways.
      
      But that is forgetting batch commands that require relocation.
      You see, in this case, the return size is NOT MAX_IPC_RETURN_SIZE
      but is instead allocated to be exactly the predicted size.
      Now, in theory this should work, since our servers are well behaved and
      would be a minor bug.
      
      And yet windows shenanigans strike again.
      It seems like if you request _more_ data than was sent a race condition
      can happen that can overwrite some part of the heap that we told windows
      was fine to use. This only happens in very specific timing conditions
      but leads to heap corruption if you define your heap bigger than it is
      _even_ if you send the correct amount of data.
      
      This is probably due to an aligned memcpy copying more than we asked but
      that leads yet another question: VS debugger shows us that this heap is
      not allocated; ...is this copying freed kernel heap on userspace???
      If so, this is pretty bad. Buuuut I'm not going to check today, the bug
      is fixed after all :).
      53ef22d8
  2. 01 Jun, 2021 2 commits
  3. 31 May, 2021 3 commits
  4. 30 May, 2021 4 commits
  5. 29 May, 2021 15 commits
  6. 31 Mar, 2021 1 commit
  7. 30 Mar, 2021 4 commits
  8. 29 Mar, 2021 4 commits
  9. 07 Mar, 2021 2 commits
  10. 03 Mar, 2021 1 commit
  11. 01 Mar, 2021 3 commits