Re: [bug report] KASAN slab-use-after-free at blktests srp/002 with siw driver

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

 



On Tue, Jun 04, 2024 at 02:15:44PM -0600, Bart Van Assche wrote:
> On 6/4/24 03:26, Zhu Yanjun wrote:
> > 
> > On 04.06.24 09:25, Shinichiro Kawasaki wrote:
> > > As I noted in another thread [1], KASAN slab-use-after-free is
> > > observed when
> > > I repeat the blktests test case srp/002 with the siw driver [2]. The
> > > kernel
> > > version was v6.10-rc2. The failure is recreated in stable manner
> > > when the test
> > > case is repeated around 30 times. It was not observed with the rxe
> > > driver.
> > > 
> > > I think this failure is same as that I reported in Jun/2023 [3]. The
> > > Call Trace
> > > reported is quite similar. Also, I confirmed that the trial fix
> > > patch that I
> > > created in Jun/2023 avoided the KASAN failure at srp/002.
> > 
> > "the trial fix patch that I created in Jun/2023" that you mentioned is
> > the commit in the link?
> > 
> > https://lore.kernel.org/linux-rdma/20230612054237.1855292-1-shinichiro.kawasaki@xxxxxxx/
> 
> To me that patch doesn't seem correct. Jason and Leon, is my understanding
> correct that you are the maintainers for the iwcm code? Can you please help
> with reviewing this patch?
>
> Thanks,
> 
> Bart.
> 
> From 879ca4e5f9ab8c4ce522b4edc144a3938a2f4afb Mon Sep 17 00:00:00 2001
> From: Bart Van Assche <bvanassche@xxxxxxx>
> Date: Tue, 4 Jun 2024 12:49:44 -0700
> Subject: [PATCH] RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
> 
> iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with
> an existing struct iw_cm_id (cm_id) as follows:
> 
>         conn_id->cm_id.iw = cm_id;
>         cm_id->context = conn_id;
>         cm_id->cm_handler = cma_iw_handler;
> 
> rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make
> sure that cm_work_handler() does not trigger a use-after-free by delaing
> freeing of the struct rdma_id_private until all pending work has finished.

I didn't try to look in detail but this certainly makes more sense to
me as a possible solution to a UAF

Presumably destroy_cm_id() does something to prevent new work from
being scheduled?

Jason




[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