[syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_svc_request_handler

[syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_svc_request_handler

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    6628e7d4c6b2 Linux 7.4-rc1
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1308eadd580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f9bf69220d319004
dashboard link: https://syzkaller.appspot.com/bug?extid=693652ded53d3eb9cb91
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17bebe69580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12c1344e580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d415be35d54e/disk-6628e7d4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/69e49385122b/vmlinux-6628e7d4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/51be81fff25f/bzImage-6628e7d4.xz

AI-generated root cause summary:
In drivers/greybus/operation.c, gb_connection_recv() verifies that the received
buffer length is at least sizeof(header) and that size >= msg_size, but fails to
check whether msg_size (from header.size) is at least sizeof(header). When an
incoming message has header.size < sizeof(struct gb_operation_msg_hdr),
gb_operation_create_incoming() computes request_size = size - sizeof(struct
gb_operation_msg_hdr), causing an unsigned size_t underflow to SIZE_MAX. While
gb_operation_message_alloc() wraps the allocation size back to the short
msg_size (allocating e.g. 7 bytes), gb_operation_message_init() sets
payload_size to SIZE_MAX and sets payload to header + 1 (offset 8, past the end
of the buffer). Consequently, request handlers like gb_svc_version_request()
pass the payload_size validation and perform out-of-bounds heap reads on
op->request->payload.

full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=693652ded53d3eb9cb91

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+693652ded53d3eb9cb91@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-out-of-bounds in gb_svc_version_request drivers/greybus/svc.c:658 [inline]
BUG: KASAN: slab-out-of-bounds in gb_svc_request_handler+0x10de/0x1250 drivers/greybus/svc.c:1271
Read of size 1 at addr ffff888104ad2108 by task kworker/u8:0/12

CPU: 0 UID: 0 PID: 12 Comm: kworker/u8:0 Not tainted syzkaller #0 PREEMPT(lazy) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/07/2026
Workqueue: greybus1:0 gb_operation_work
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x13d/0x4b0 mm/kasan/report.c:482
 kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
 gb_svc_version_request drivers/greybus/svc.c:658 [inline]
 gb_svc_request_handler+0x10de/0x1250 drivers/greybus/svc.c:1271
 gb_operation_request_handle drivers/greybus/operation.c:243 [inline]
 gb_operation_work+0xb7/0x990 drivers/greybus/operation.c:280
 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3495
 process_scheduled_works kernel/workqueue.c:3578 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3659
 kthread+0x373/0x450 kernel/kthread.c:436
 ret_from_fork+0x69f/0xc90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 0:
 kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
 kasan_save_track+0x14/0x30 mm/kasan/common.c:78
 poison_kmalloc_redzone mm/kasan/common.c:409 [inline]
 __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:426
 kasan_kmalloc include/linux/kasan.h:263 [inline]
 __do_kmalloc_node mm/slub.c:5531 [inline]
 __kmalloc_noprof+0x315/0x7e0 mm/slub.c:5556
 _kmalloc_noprof include/linux/slab.h:995 [inline]
 _kzalloc_noprof include/linux/slab.h:1312 [inline]
 gb_operation_message_alloc+0x9b/0x2c0 drivers/greybus/operation.c:380
 gb_operation_create_common+0x9f/0x710 drivers/greybus/operation.c:532
 gb_operation_create_incoming drivers/greybus/operation.c:644 [inline]
 gb_connection_recv_request drivers/greybus/operation.c:926 [inline]
 gb_connection_recv+0x1dc/0x1050 drivers/greybus/operation.c:1063
 greybus_data_rcvd+0x244/0x600 drivers/greybus/connection.c:89
 cport_in_callback+0x1fb/0x280 drivers/greybus/es2.c:840
 __usb_hcd_giveback_urb+0x38e/0x610 drivers/usb/core/hcd.c:1657
 usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
 dummy_timer+0xdb5/0x3840 drivers/usb/gadget/udc/dummy_hcd.c:2051
 __run_hrtimer kernel/time/hrtimer.c:2079 [inline]
 __hrtimer_run_queues+0x448/0x9a0 kernel/time/hrtimer.c:2136
 hrtimer_run_softirq+0x1ca/0x360 kernel/time/hrtimer.c:2153
 handle_softirqs+0x209/0xa00 kernel/softirq.c:669
 __do_softirq kernel/softirq.c:703 [inline]
 invoke_softirq kernel/softirq.c:542 [inline]
 __irq_exit_rcu+0x17a/0x220 kernel/softirq.c:786
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:809
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
 sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1062
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674

The buggy address belongs to the object at ffff888104ad2100
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 1 bytes to the right of
 allocated 7-byte region [ffff888104ad2100, ffff888104ad2107)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888104ad2600 pfn:0x104ad2
flags: 0x200000000000200(workingset|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000200 ffff888100041500 ffffea00040eb410 ffffea000403ef50
raw: ffff888104ad2600 000000000080007a 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 5446373684
 set_page_owner include/linux/page_owner.h:33 [inline]
 post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1856
 prep_new_page mm/page_alloc.c:1864 [inline]
 get_page_from_freelist+0xf4b/0x3440 mm/page_alloc.c:3935
 __alloc_frozen_pages_noprof+0x299/0x2d50 mm/page_alloc.c:5444
 alloc_slab_page mm/slub.c:3384 [inline]
 allocate_slab mm/slub.c:3499 [inline]
 new_slab+0xb1/0x6d0 mm/slub.c:3550
 refill_objects+0xe3/0x410 mm/slub.c:7539
 refill_sheaf mm/slub.c:2917 [inline]
 __pcs_replace_empty_main+0x35e/0x650 mm/slub.c:4811
 alloc_from_pcs mm/slub.c:4887 [inline]
 slab_alloc_node mm/slub.c:5021 [inline]
 __do_kmalloc_node mm/slub.c:5530 [inline]
 __kmalloc_noprof+0x617/0x7e0 mm/slub.c:5556
 _kmalloc_noprof include/linux/slab.h:995 [inline]
 _kzalloc_noprof include/linux/slab.h:1312 [inline]
 acpi_ns_internalize_name+0x161/0x2e0 drivers/acpi/acpica/nsutils.c:331
 acpi_ns_get_node_unlocked+0x18c/0x500 drivers/acpi/acpica/nsutils.c:666
 acpi_ns_get_node+0x6c/0xf0 drivers/acpi/acpica/nsutils.c:726
 acpi_ns_evaluate+0xb01/0x1670 drivers/acpi/acpica/nseval.c:62
 acpi_ut_evaluate_object+0xf7/0x610 drivers/acpi/acpica/uteval.c:60
 acpi_ut_execute_power_methods+0x1f9/0x3c0 drivers/acpi/acpica/uteval.c:288
 acpi_get_object_info+0xa43/0xbe0 drivers/acpi/acpica/nsxfname.c:366
 acpi_set_pnp_ids drivers/acpi/scan.c:1405 [inline]
 acpi_init_device_object+0xc12/0x1a90 drivers/acpi/scan.c:1827
 acpi_add_single_object+0xe8/0x1a10 drivers/acpi/scan.c:1877
page last free pid 1 tgid 1 ts 5222696283 stack trace:
 reset_page_owner include/linux/page_owner.h:26 [inline]
 __free_pages_prepare mm/page_alloc.c:1403 [inline]
 __free_frozen_pages+0x714/0xfc0 mm/page_alloc.c:2954
 qlink_free mm/kasan/quarantine.c:163 [inline]
 qlist_free_all+0x47/0xf0 mm/kasan/quarantine.c:179
 kasan_quarantine_remove_cache+0x168/0x190 mm/kasan/quarantine.c:388
 kmem_cache_shrink+0xd/0x20 mm/slab_common.c:620
 acpi_os_purge_cache+0x15/0x20 drivers/acpi/osl.c:1622
 acpi_purge_cached_objects+0xa3/0x140 drivers/acpi/acpica/utxface.c:239
 acpi_initialize_objects+0x8b/0x100 drivers/acpi/acpica/utxfinit.c:250
 acpi_bus_init drivers/acpi/bus.c:1381 [inline]
 acpi_init+0x1b0/0x840 drivers/acpi/bus.c:1471
 do_one_initcall+0x11c/0x6f0 init/main.c:1419
 do_initcall_level init/main.c:1481 [inline]
 do_initcalls init/main.c:1497 [inline]
 do_basic_setup init/main.c:1517 [inline]
 kernel_init_freeable+0x6ea/0x7b0 init/main.c:1732
 kernel_init+0x21/0x1e0 init/main.c:1622
 ret_from_fork+0x69f/0xc90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff888104ad2000: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
 ffff888104ad2080: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
>ffff888104ad2100: 07 fc fc fc fa fc fc fc 06 fc fc fc 06 fc fc fc
                      ^
 ffff888104ad2180: 06 fc fc fc 06 fc fc fc 06 fc fc fc 06 fc fc fc
 ffff888104ad2200: 06 fc fc fc 06 fc fc fc fa fc fc fc fa fc fc fc
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_svc_request_handler

[Alex Elder]

On 11/5/26 5:09 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    6628e7d4c6b2 Linux 7.4-rc1
> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> console output: https://syzkaller.appspot.com/x/log.txt?x=1308eadd580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=f9bf69220d319004
> dashboard link: https://syzkaller.appspot.com/bug?extid=693652ded53d3eb9cb91
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17bebe69580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12c1344e580000

Maybe I'm looking at the wrong code, but I think the AI summary
is wrong, though I believe the KASAN report.  It seems more like
a use-after-free or something.  (I haven't dug further for now,
but I'll explain why I think AI summary is wrong.)

> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d415be35d54e/disk-6628e7d4.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/69e49385122b/vmlinux-6628e7d4.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/51be81fff25f/bzImage-6628e7d4.xz
> 
> AI-generated root cause summary:
> In drivers/greybus/operation.c, gb_connection_recv() verifies that the received
> buffer length is at least sizeof(header) and that size >= msg_size, but fails to
> check whether msg_size (from header.size) is at least sizeof(header). When an
> incoming message has header.size < sizeof(struct gb_operation_msg_hdr),
> gb_operation_create_incoming() computes request_size = size - sizeof(struct
> gb_operation_msg_hdr), causing an unsigned size_t underflow to SIZE_MAX. While


Here is what I see happening at the beginning of gb_connection_recv():
- If the connection is disabled or offloaded, return immediately
- If the size of the buffer (passed in as the "size" argument) is less
   than the size of an operation message header, return
- If the 16-bit size embedded in the message header is less than the
   size of the buffer, return

In other words, after these checks, we know:

   sizeof(header) <= buffer size (size)       AND
   buffer size (size) <= size encoded in the header (msg_size)

Therefore (transitive property), this is true:

   sizeof(header) <= size encoded in the header (msg_size)

And it's not possible after these checks for this to be true:

     header.size < sizeof(struct gb_operation_msg_hdr)

or put another way:

     msg_size < sizeof(header)        cannot hold


It surprises me this would be missed in the AI summary--and I
fear I'm mistaken.  If I'm missing something or wrong about this,
please feel free to say so.

					-Alex

> gb_operation_message_alloc() wraps the allocation size back to the short
> msg_size (allocating e.g. 7 bytes), gb_operation_message_init() sets
> payload_size to SIZE_MAX and sets payload to header + 1 (offset 8, past the end
> of the buffer). Consequently, request handlers like gb_svc_version_request()
> pass the payload_size validation and perform out-of-bounds heap reads on
> op->request->payload.
> 
> full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=693652ded53d3eb9cb91
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+693652ded53d3eb9cb91@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in gb_svc_version_request drivers/greybus/svc.c:658 [inline]
> BUG: KASAN: slab-out-of-bounds in gb_svc_request_handler+0x10de/0x1250 drivers/greybus/svc.c:1271
> Read of size 1 at addr ffff888104ad2108 by task kworker/u8:0/12
> 
> CPU: 0 UID: 0 PID: 12 Comm: kworker/u8:0 Not tainted syzkaller #0 PREEMPT(lazy)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/07/2026
> Workqueue: greybus1:0 gb_operation_work
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:94 [inline]
>   dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
>   print_address_description mm/kasan/report.c:378 [inline]
>   print_report+0x13d/0x4b0 mm/kasan/report.c:482
>   kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
>   gb_svc_version_request drivers/greybus/svc.c:658 [inline]
>   gb_svc_request_handler+0x10de/0x1250 drivers/greybus/svc.c:1271
>   gb_operation_request_handle drivers/greybus/operation.c:243 [inline]
>   gb_operation_work+0xb7/0x990 drivers/greybus/operation.c:280
>   process_one_work+0xac7/0x1b10 kernel/workqueue.c:3495
>   process_scheduled_works kernel/workqueue.c:3578 [inline]
>   worker_thread+0x5ef/0xe50 kernel/workqueue.c:3659
>   kthread+0x373/0x450 kernel/kthread.c:436
>   ret_from_fork+0x69f/0xc90 arch/x86/kernel/process.c:158
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>   </TASK>
> 
> Allocated by task 0:
>   kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
>   kasan_save_track+0x14/0x30 mm/kasan/common.c:78
>   poison_kmalloc_redzone mm/kasan/common.c:409 [inline]
>   __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:426
>   kasan_kmalloc include/linux/kasan.h:263 [inline]
>   __do_kmalloc_node mm/slub.c:5531 [inline]
>   __kmalloc_noprof+0x315/0x7e0 mm/slub.c:5556
>   _kmalloc_noprof include/linux/slab.h:995 [inline]
>   _kzalloc_noprof include/linux/slab.h:1312 [inline]
>   gb_operation_message_alloc+0x9b/0x2c0 drivers/greybus/operation.c:380
>   gb_operation_create_common+0x9f/0x710 drivers/greybus/operation.c:532
>   gb_operation_create_incoming drivers/greybus/operation.c:644 [inline]
>   gb_connection_recv_request drivers/greybus/operation.c:926 [inline]
>   gb_connection_recv+0x1dc/0x1050 drivers/greybus/operation.c:1063
>   greybus_data_rcvd+0x244/0x600 drivers/greybus/connection.c:89
>   cport_in_callback+0x1fb/0x280 drivers/greybus/es2.c:840
>   __usb_hcd_giveback_urb+0x38e/0x610 drivers/usb/core/hcd.c:1657
>   usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
>   dummy_timer+0xdb5/0x3840 drivers/usb/gadget/udc/dummy_hcd.c:2051
>   __run_hrtimer kernel/time/hrtimer.c:2079 [inline]
>   __hrtimer_run_queues+0x448/0x9a0 kernel/time/hrtimer.c:2136
>   hrtimer_run_softirq+0x1ca/0x360 kernel/time/hrtimer.c:2153
>   handle_softirqs+0x209/0xa00 kernel/softirq.c:669
>   __do_softirq kernel/softirq.c:703 [inline]
>   invoke_softirq kernel/softirq.c:542 [inline]
>   __irq_exit_rcu+0x17a/0x220 kernel/softirq.c:786
>   irq_exit_rcu+0x9/0x30 kernel/softirq.c:809
>   instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
>   sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1062
>   asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
> 
> The buggy address belongs to the object at ffff888104ad2100
>   which belongs to the cache kmalloc-8 of size 8
> The buggy address is located 1 bytes to the right of
>   allocated 7-byte region [ffff888104ad2100, ffff888104ad2107)
> 
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888104ad2600 pfn:0x104ad2
> flags: 0x200000000000200(workingset|node=0|zone=2)
> page_type: f5(slab)
> raw: 0200000000000200 ffff888100041500 ffffea00040eb410 ffffea000403ef50
> raw: ffff888104ad2600 000000000080007a 00000000f5000000 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 5446373684
>   set_page_owner include/linux/page_owner.h:33 [inline]
>   post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1856
>   prep_new_page mm/page_alloc.c:1864 [inline]
>   get_page_from_freelist+0xf4b/0x3440 mm/page_alloc.c:3935
>   __alloc_frozen_pages_noprof+0x299/0x2d50 mm/page_alloc.c:5444
>   alloc_slab_page mm/slub.c:3384 [inline]
>   allocate_slab mm/slub.c:3499 [inline]
>   new_slab+0xb1/0x6d0 mm/slub.c:3550
>   refill_objects+0xe3/0x410 mm/slub.c:7539
>   refill_sheaf mm/slub.c:2917 [inline]
>   __pcs_replace_empty_main+0x35e/0x650 mm/slub.c:4811
>   alloc_from_pcs mm/slub.c:4887 [inline]
>   slab_alloc_node mm/slub.c:5021 [inline]
>   __do_kmalloc_node mm/slub.c:5530 [inline]
>   __kmalloc_noprof+0x617/0x7e0 mm/slub.c:5556
>   _kmalloc_noprof include/linux/slab.h:995 [inline]
>   _kzalloc_noprof include/linux/slab.h:1312 [inline]
>   acpi_ns_internalize_name+0x161/0x2e0 drivers/acpi/acpica/nsutils.c:331
>   acpi_ns_get_node_unlocked+0x18c/0x500 drivers/acpi/acpica/nsutils.c:666
>   acpi_ns_get_node+0x6c/0xf0 drivers/acpi/acpica/nsutils.c:726
>   acpi_ns_evaluate+0xb01/0x1670 drivers/acpi/acpica/nseval.c:62
>   acpi_ut_evaluate_object+0xf7/0x610 drivers/acpi/acpica/uteval.c:60
>   acpi_ut_execute_power_methods+0x1f9/0x3c0 drivers/acpi/acpica/uteval.c:288
>   acpi_get_object_info+0xa43/0xbe0 drivers/acpi/acpica/nsxfname.c:366
>   acpi_set_pnp_ids drivers/acpi/scan.c:1405 [inline]
>   acpi_init_device_object+0xc12/0x1a90 drivers/acpi/scan.c:1827
>   acpi_add_single_object+0xe8/0x1a10 drivers/acpi/scan.c:1877
> page last free pid 1 tgid 1 ts 5222696283 stack trace:
>   reset_page_owner include/linux/page_owner.h:26 [inline]
>   __free_pages_prepare mm/page_alloc.c:1403 [inline]
>   __free_frozen_pages+0x714/0xfc0 mm/page_alloc.c:2954
>   qlink_free mm/kasan/quarantine.c:163 [inline]
>   qlist_free_all+0x47/0xf0 mm/kasan/quarantine.c:179
>   kasan_quarantine_remove_cache+0x168/0x190 mm/kasan/quarantine.c:388
>   kmem_cache_shrink+0xd/0x20 mm/slab_common.c:620
>   acpi_os_purge_cache+0x15/0x20 drivers/acpi/osl.c:1622
>   acpi_purge_cached_objects+0xa3/0x140 drivers/acpi/acpica/utxface.c:239
>   acpi_initialize_objects+0x8b/0x100 drivers/acpi/acpica/utxfinit.c:250
>   acpi_bus_init drivers/acpi/bus.c:1381 [inline]
>   acpi_init+0x1b0/0x840 drivers/acpi/bus.c:1471
>   do_one_initcall+0x11c/0x6f0 init/main.c:1419
>   do_initcall_level init/main.c:1481 [inline]
>   do_initcalls init/main.c:1497 [inline]
>   do_basic_setup init/main.c:1517 [inline]
>   kernel_init_freeable+0x6ea/0x7b0 init/main.c:1732
>   kernel_init+0x21/0x1e0 init/main.c:1622
>   ret_from_fork+0x69f/0xc90 arch/x86/kernel/process.c:158
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> 
> Memory state around the buggy address:
>   ffff888104ad2000: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
>   ffff888104ad2080: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
>> ffff888104ad2100: 07 fc fc fc fa fc fc fc 06 fc fc fc 06 fc fc fc
>                        ^
>   ffff888104ad2180: 06 fc fc fc 06 fc fc fc 06 fc fc fc 06 fc fc fc
>   ffff888104ad2200: 06 fc fc fc 06 fc fc fc fa fc fc fc fa fc fc fc
> ==================================================================
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup

Re: [syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_svc_request_handler

[Chandradhar Kumar]

On Thu, Nov 05, 2026 at 08:08:01AM -0600, Alex Elder wrote:
> Here is what I see happening at the beginning of gb_connection_recv():
> - If the connection is disabled or offloaded, return immediately
> - If the size of the buffer (passed in as the "size" argument) is less
>   than the size of an operation message header, return
> - If the 16-bit size embedded in the message header is less than the
>   size of the buffer, return
> 
> In other words, after these checks, we know:
> 
>   sizeof(header) <= buffer size (size)       AND
>   buffer size (size) <= size encoded in the header (msg_size)
No, it does not verify this, it verify:
	size encoded in the header <= size (buffer size)
> 
> Therefore (transitive property), this is true:
> 
>   sizeof(header) <= size encoded in the header (msg_size)
So, the transitive property is not true.

I have sent a patch for this bug which verify the msg_size and header
separately, which fixes the out of bounds read.
patch link: https://lore.kernel.org/all/20261106094303.55158-1-chandradhar.2003@gmail.com/

Hey please review the patch if there is something wrong or there are any
other way to fix the bug.

Thanks.
> 
> And it's not possible after these checks for this to be true:
> 
>     header.size < sizeof(struct gb_operation_msg_hdr)
> 
> or put another way:
> 
>     msg_size < sizeof(header)        cannot hold
> 
> 
> It surprises me this would be missed in the AI summary--and I
> fear I'm mistaken.  If I'm missing something or wrong about this,
> please feel free to say so.
> 
> 					-Alex

Re: [syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Read in gb_svc_request_handler

[Alex Elder]

On 11/7/26 8:17 AM, Chandradhar Kumar wrote:
> On Thu, Nov 05, 2026 at 08:08:01AM -0600, Alex Elder wrote:
>> Here is what I see happening at the beginning of gb_connection_recv():
>> - If the connection is disabled or offloaded, return immediately
>> - If the size of the buffer (passed in as the "size" argument) is less
>>    than the size of an operation message header, return
>> - If the 16-bit size embedded in the message header is less than the
>>    size of the buffer, return
>>
>> In other words, after these checks, we know:
>>
>>    sizeof(header) <= buffer size (size)       AND
>>    buffer size (size) <= size encoded in the header (msg_size)
> No, it does not verify this, it verify:
> 	size encoded in the header <= size (buffer size)

You're right, I misread this.

We don't read the header unless size tells us the entire
message ("buffer size") is at least the size of the header.

And then we ensure the buffer contains the entire message
(whose msg_size is decoded from the header).

But if the size encoded in the message header is bogus
(and in particular, smaller than the header size) we
have a problem.

>> Therefore (transitive property), this is true:
>>
>>    sizeof(header) <= size encoded in the header (msg_size)
> So, the transitive property is not true.

Agreed.  Thanks for explaining where I was wrong.

> I have sent a patch for this bug which verify the msg_size and header
> separately, which fixes the out of bounds read.
> patch link: https://lore.kernel.org/all/20261106094303.55158-1-chandradhar.2003@gmail.com/

					-Alex
> Hey please review the patch if there is something wrong or there are any
> other way to fix the bug.
> 
> Thanks.
>>
>> And it's not possible after these checks for this to be true:
>>
>>      header.size < sizeof(struct gb_operation_msg_hdr)
>>
>> or put another way:
>>
>>      msg_size < sizeof(header)        cannot hold
>>
>>
>> It surprises me this would be missed in the AI summary--and I
>> fear I'm mistaken.  If I'm missing something or wrong about this,
>> please feel free to say so.
>>
>> 					-Alex