[PATCH v2] fsnotify: initialize destroy_next to avoid KMSAN uninit-value warning

[PATCH v2] fsnotify: initialize destroy_next to avoid KMSAN uninit-value warning

[avinashlalotra]

KMSAN reported an uninitialized value use in
fsnotify_connector_destroy_workfn(), specifically when accessing
`conn->destroy_next`:

    BUG: KMSAN: uninit-value in fsnotify_connector_destroy_workfn+0x108/0x160
    Uninit was created at:
     slab_alloc_node mm/slub.c:4197 [inline]
     kmem_cache_alloc_noprof+0x81b/0xec0 mm/slub.c:4204
     fsnotify_attach_connector_to_object fs/notify/mark.c:663

The struct fsnotify_mark_connector was allocated using
kmem_cache_alloc(), but the `destroy_next` field was never initialized,
leading to a use of uninitialized memory when the work function later
traversed the destroy list.

Fix this by explicitly initializing `destroy_next` to NULL immediately
after allocation.

Reported-by: syzbot+aaeb1646d01d0358cb2a@syzkaller.appspotmail.com
Signed-off-by: abinashlalotra <abinashsinghlalotra@gmail.com>

---
v2: Corrected the syzbot Reported-by email address.
---
 fs/notify/mark.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/notify/mark.c b/fs/notify/mark.c
index 798340db69d7..28013046f732 100644
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -665,6 +665,7 @@ static int fsnotify_attach_connector_to_object(fsnotify_connp_t *connp,
 		return -ENOMEM;
 	spin_lock_init(&conn->lock);
 	INIT_HLIST_HEAD(&conn->list);
+	conn->destroy_next = NULL;
 	conn->flags = 0;
 	conn->prio = 0;
 	conn->type = obj_type;
-- 
2.43.0

Re: [PATCH v2] fsnotify: initialize destroy_next to avoid KMSAN uninit-value warning

[Jan Kara]

On Thu 19-06-25 16:21:17, avinashlalotra wrote:
> KMSAN reported an uninitialized value use in
> fsnotify_connector_destroy_workfn(), specifically when accessing
> `conn->destroy_next`:
> 
>     BUG: KMSAN: uninit-value in fsnotify_connector_destroy_workfn+0x108/0x160
>     Uninit was created at:
>      slab_alloc_node mm/slub.c:4197 [inline]
>      kmem_cache_alloc_noprof+0x81b/0xec0 mm/slub.c:4204
>      fsnotify_attach_connector_to_object fs/notify/mark.c:663
> 
> The struct fsnotify_mark_connector was allocated using
> kmem_cache_alloc(), but the `destroy_next` field was never initialized,
> leading to a use of uninitialized memory when the work function later
> traversed the destroy list.
> 
> Fix this by explicitly initializing `destroy_next` to NULL immediately
> after allocation.
> 
> Reported-by: syzbot+aaeb1646d01d0358cb2a@syzkaller.appspotmail.com
> Signed-off-by: abinashlalotra <abinashsinghlalotra@gmail.com>

This doesn't make sense. If you checked definition of
fsnotify_mark_connector you'd see that destroy_next is in union with void
*obj:

        union {
                /* Object pointer [lock] */
                void *obj;
                /* Used listing heads to free after srcu period expires */
                struct fsnotify_mark_connector *destroy_next;
        };

and we do initialize 'obj' pointer in
fsnotify_attach_connector_to_object(). So this report was caused either by
some other memory corruption or KMSAN getting utterly confused...

								Honza

> 
> ---
> v2: Corrected the syzbot Reported-by email address.
> ---
>  fs/notify/mark.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/notify/mark.c b/fs/notify/mark.c
> index 798340db69d7..28013046f732 100644
> --- a/fs/notify/mark.c
> +++ b/fs/notify/mark.c
> @@ -665,6 +665,7 @@ static int fsnotify_attach_connector_to_object(fsnotify_connp_t *connp,
>  		return -ENOMEM;
>  	spin_lock_init(&conn->lock);
>  	INIT_HLIST_HEAD(&conn->list);
> +	conn->destroy_next = NULL;
>  	conn->flags = 0;
>  	conn->prio = 0;
>  	conn->type = obj_type;
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH v2] fsnotify: initialize destroy_next to avoid KMSAN uninit-value warning

[Abinash]

Thank you for your response.

You are right — it doesn't make sense at first glance.

I went through the code again and tried to understand the connector's
lifecycle more clearly.
The destroy_next pointer is initialized when detaching the connector
from the inode and before the connector is destroyed.
This bug would only be possible if the connector allocated by
fsnotify_attach_connector_to_object() were to somehow
end up directly in the connector_destroy_list, which it does not.
Before reaching that list, in fsnotify_put_mark(), the function
fsnotify_detach_connector_from_object() nullifies the obj pointer.
After that, the destroy_next pointer is explicitly set to the head of
connector_destroy_list.

So there's no scenario where a connector from
fsnotify_attach_connector_to_object() can land
in connector_destroy_list without destroy_next being initialized...

This suggests that KMSAN might be confused, as the following loop:

while (conn) {
    free = conn;
    conn = conn->destroy_next;
    kmem_cache_free(fsnotify_mark_connector_cachep, free);
}

should not involve any uninitialized value access.


Thank You
regards
Abinash


On Thu, 19 Jun 2025 at 20:27, Jan Kara <jack@suse.cz> wrote:
>
> On Thu 19-06-25 16:21:17, avinashlalotra wrote:
> > KMSAN reported an uninitialized value use in
> > fsnotify_connector_destroy_workfn(), specifically when accessing
> > `conn->destroy_next`:
> >
> >     BUG: KMSAN: uninit-value in fsnotify_connector_destroy_workfn+0x108/0x160
> >     Uninit was created at:
> >      slab_alloc_node mm/slub.c:4197 [inline]
> >      kmem_cache_alloc_noprof+0x81b/0xec0 mm/slub.c:4204
> >      fsnotify_attach_connector_to_object fs/notify/mark.c:663
> >
> > The struct fsnotify_mark_connector was allocated using
> > kmem_cache_alloc(), but the `destroy_next` field was never initialized,
> > leading to a use of uninitialized memory when the work function later
> > traversed the destroy list.
> >
> > Fix this by explicitly initializing `destroy_next` to NULL immediately
> > after allocation.
> >
> > Reported-by: syzbot+aaeb1646d01d0358cb2a@syzkaller.appspotmail.com
> > Signed-off-by: abinashlalotra <abinashsinghlalotra@gmail.com>
>
> This doesn't make sense. If you checked definition of
> fsnotify_mark_connector you'd see that destroy_next is in union with void
> *obj:
>
>         union {
>                 /* Object pointer [lock] */
>                 void *obj;
>                 /* Used listing heads to free after srcu period expires */
>                 struct fsnotify_mark_connector *destroy_next;
>         };
>
> and we do initialize 'obj' pointer in
> fsnotify_attach_connector_to_object(). So this report was caused either by
> some other memory corruption or KMSAN getting utterly confused...
>
>                                                                 Honza
>
> >
> > ---
> > v2: Corrected the syzbot Reported-by email address.
> > ---
> >  fs/notify/mark.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/fs/notify/mark.c b/fs/notify/mark.c
> > index 798340db69d7..28013046f732 100644
> > --- a/fs/notify/mark.c
> > +++ b/fs/notify/mark.c
> > @@ -665,6 +665,7 @@ static int fsnotify_attach_connector_to_object(fsnotify_connp_t *connp,
> >               return -ENOMEM;
> >       spin_lock_init(&conn->lock);
> >       INIT_HLIST_HEAD(&conn->list);
> > +     conn->destroy_next = NULL;
> >       conn->flags = 0;
> >       conn->prio = 0;
> >       conn->type = obj_type;
> > --
> > 2.43.0
> >
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR