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

On Fri, 2026-03-27 at 15:31 +0530, Sumit Garg wrote:
> 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

Hi,

Our kernel driver does not registered as a TEE bus driver for some reasons,
and we need to use other API to ensure the OP-TEE driver is probed to
workaround this issue. But, we think this is error-prone for module developer
that need to call to OP-TEE.

Although this is not the case, I think that after calling tee_device_register(),
the optee device is shown under `/dev/` filesystem. There is a very small chance
for userspace program to trigger this race condition, and they don't have clue on
whether the device is properly being probed yet.

Best regards,
Shao-Fu Chen

> 
> > 
> > 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
> > 
> >