[PATCH] tomoyo: Fix NULL pointer dereference in tomoyo_init_request_info() when domain is NULL

[Tetsuo Handa]

On 2026/05/26 22:58, Jiakai Xu wrote:
>> Thank you for a patch, but I don't think we need this change.
> 
> Thanks for your review! I understand your perspective, but I believe
> the crash is a real NULL pointer dereference, and I'd like to explain
> why the defensive check is warranted.
> 
>> TOMOYO's initial domain is &tomoyo_kernel_domain, and each thread belongs to
>> a non-NULL domain. Therefore, tomoyo_domain() is not supposed to return NULL.
> 
> While tomoyo_domain() is not supposed to return NULL under normal
> operation, there are code paths that leave s->domain_info == NULL:
> 
>   a) Pre-init window (security/tomoyo/tomoyo.c, lines 598-612):
>      The task security blob is zero-allocated via kzalloc(), and
>      security_add_hooks() at line 603 is called BEFORE
>      s->domain_info = &tomoyo_kernel_domain at line 606. If any LSM
>      hook fires during that window, tomoyo_domain() returns NULL.

This code is executed during early boot stage. Other LSM hooks are not
supposed to fire.

> 
>   b) tomoyo_task_free() (tomoyo.c, lines 533-545) explicitly sets
>      s->domain_info = NULL after decrementing the refcount.

This code is executed when a "struct task_struct" is about to be released.
Nobody can find this "struct task_struct". Also, this "struct task_struct"
cannot be the current thread.

> 
>   c) tomoyo_find_next_domain() (domain.c, lines 876-883) writes
>      s->domain_info = NULL when the domain transition fails.

I couldn't catch, but old_domain is initialized as

  struct tomoyo_domain_info *old_domain = tomoyo_domain();

which cannot be NULL.

domain is guaranteed to be non-NULL because old_domain cannot be NULL.

	if (!domain)
		domain = old_domain;

Therefore, s->domain_info is guaranteed to be non-NULL because domain cannot be NULL.

	s->domain_info = domain;

If domain were NULL, the kernel should have already crashed at line 884.

> 
> I think adding a NULL check makes the code more robust. What do you 
> think?

Then, this will be NULL pointer dereference.
But fixing the location that is setting NULL is the correct approach.