Re: Possible race during OP-TEE kernel module device probing

On Fri, Mar 27, 2026 at 09:01:15AM +0000, Shf Chen (陳少甫) via OP-TEE wrote:
> Hi,
> 
> We found a possible race condition issue during OP-TEE kernel driver probing the device.
> A NULL pointer dereference exception can happen when another kernel driver open OP-TEE context
> with tee_client_open_context() then do a SMC call to OP-TEE.
> Below is the exception:

How is your kernel driver being probed? Have you registered it as a
proper TEE bus driver? Any custom ways to invoke TEE kernel client APIs
are surely susceptible to races like the one you mentioned below.

-Sumit

> 
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> Mem abort info:
>   ESR = 0x0000000096000005
>   EC = 0x25: DABT (current EL), IL = 32 bits
>   SET = 0, FnV = 0
>   EA = 0, S1PTW = 0
>   FSC = 0x05: level 1 translation fault
> Data abort info:
>   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
>   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
>   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> user pgtable: 4k pages, 39-bit VAs, pgdp=00000001026bb000
> [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
> Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 03400005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> pc : optee_cq_wait_init+0x78/0x124 [optee]
> lr : optee_cq_wait_init+0x60/0x124 [optee]
> sp : ffffffc081fcb7f0
> x29: ffffffc081fcb7f0 x28: 0000000000000000 x27: 0000000000001000
> x26: ffffff8080e42c60 x25: ffffff8084d46040 x24: 0000000000000000
> x23: 0000000000000000 x22: ffffffc081fcb8c0 x21: ffffffc081fcb8a8
> x20: 0000000000000000 x19: ffffff8082741570 x18: ffffffe572f8ca00
> x17: 00000000fa28650f x16: 00000000fa28650f x15: ffffff8084d47000
> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000084d47000
> x11: 0000000000000000 x10: 0000000032000012 x9 : 04d4600000000001
> x8 : ffffffc081fcb8c8 x7 : 0000000000000000 x6 : 000000000000003f
> x5 : ffffff83c86649e0 x4 : 0000000000000008 x3 : 0000000000000000
> x2 : ffffff80827415a0 x1 : 0000000000000000 x0 : ffffffc081fcb8c0
> Call trace:
>  optee_cq_wait_init+0x78/0x124 [optee f6dbc35f8d96acbe1f3c329d72018151d796208d]
>  optee_smc_do_call_with_arg+0x12c/0x95c [optee f6dbc35f8d96acbe1f3c329d72018151d796208d]
>  optee_shm_register+0x284/0x360 [optee f6dbc35f8d96acbe1f3c329d72018151d796208d]
>  register_shm_helper+0x1a4/0x2f4 [tee cdd8a0d077d984bda1f31f9e8903836edbe46603]
>  tee_shm_register_kernel_buf+0x60/0x90 [tee cdd8a0d077d984bda1f31f9e8903836edbe46603]
>  cmdq_sec_allocate_wsm+0x58/0xc4 [mtk_cmdq_sec_mbox ac82dc958e32252a21c6ce55bb8839ebb288387a]
>  cmdq_sec_probe+0x80/0x4a0 [mtk_cmdq_sec_mbox ac82dc958e32252a21c6ce55bb8839ebb288387a]
> 
> We found the optee->call_queue hasn't been initialized when our driver called OP-TEE,
> and it might have some issues about the device data structure initialize order in
> optee_probe()[drivers/tee/optee/smc_abi.c]:
> 
> ---
> rc = tee_device_register(optee->teedev);  // <----- TEE device register here
> if (rc)
>     goto err_unreg_supp_teedev;
> 
> rc = tee_device_register(optee->supp_teedev);
> if (rc)
>     goto err_unreg_supp_teedev;
> 
> optee_cq_init(&optee->call_queue, thread_count);  // <----- Some data structures are initialized afterwards
> optee_supp_init(&optee->supp);
> optee->smc.memremaped_shm = memremaped_shm;
> optee->pool = pool;
> optee_shm_arg_cache_init(optee, arg_cache_flags);
> mutex_init(&optee->rpmb_dev_mutex);
> ---
> 
> We want to ask if the data structure initialization should be done before the tee device registration?
> 
> Best regards,
> Shao-Fu Chen
> 
>