Re: rdma_rxe use-after-free

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 2018/11/10 2:28, Bart Van Assche 写道:
On 11/8/18 7:15 PM, Yanjun Zhu wrote:
On 2018/11/8 0:42, Bart Van Assche wrote:
==================================================================
BUG: KASAN: use-after-free in rxe_resp_queue_pkt+0x2b/0x70 [rdma_rxe]
Read of size 1 at addr ffff8800361722d5 by task kworker/1:2/26251

CPU: 1 PID: 26251 Comm: kworker/1:2 Not tainted 4.20.0-rc1-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Workqueue: target_completion target_complete_ok_work [target_core_mod]
Call Trace:
  <IRQ>
  dump_stack+0x86/0xca
  print_address_description+0x71/0x239
  kasan_report.cold.5+0x242/0x301
  __asan_load1+0x47/0x50
  rxe_resp_queue_pkt+0x2b/0x70 [rdma_rxe]

Is it memory corruption?

first, rxe_resp_queue_pkt, then, rxe_responder.

But now it seems that first rxe_responder, then rxe_resp_queue_pkt access it.

It is weird.

Hi Zhu,

I have not tried to root-cause this but I think this could also be the result of a race condition, e.g. one thread freeing the packet while another thread is still accessing it.

Both rxe_resp_queue_pkt and rxe_responder operate on a queue. rxe_resp_queue_pkt adds skb to the tail of the queue. rxe_responder fetch skb from the head of the queue. And after rxe_responder dequeues a skb from this queue, then this skb is freed.

So it is difficult to image that these is a race condition.
Bart.





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux