greybus-dev

greybus-dev@lists.linaro.org

15 participants
926 discussions

[PATCH v2] staging: greybus: light: fix leak of cdev->name

by Cong Nguyen

gb_lights_channel_config() builds the LED classdev name with kasprintf() and stores it in cdev->name for every channel during the configuration phase, which runs before the channel is registered. That name was only released by __gb_lights_led_unregister(), i.e. only for a normal LED channel that was actually registered. It was therefore leaked in two cases: - a channel that is configured but never registered, e.g. channel_attr_groups_set() fails, the flash configuration fails, or a later channel in the same light fails to configure and the whole light is torn down; the release path calls gb_lights_channel_unregister() (which returns early because the channel is not registered) and then gb_lights_channel_free(); - a flash, torch or indicator channel, whose unregister path (__gb_lights_flash_led_unregister()) never releases cdev->name at all, so the name leaks even on a successful teardown. cdev->name is a configuration-phase allocation, like channel->color_name and channel->mode_name. Free it in gb_lights_channel_free() next to those, since that runs unconditionally on every teardown path, and drop the special case free from __gb_lights_led_unregister(). gb_lights_channel_unregister() is only ever called from gb_lights_channel_release(), immediately followed by gb_lights_channel_free(), so the name is still released on the registered path and is freed exactly once. Commit 04820da21050 ("staging: greybus: light: Release memory obtained by kasprintf") fixed the leak for the registered normal-LED path only; this covers the remaining cases. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen <congnt264(a)gmail.com> --- Changes in v2: - Add Assisted-by: tag to document AI assistance, per Documentation/process/coding-assistants.rst (Greg KH). - No functional change. drivers/staging/greybus/light.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index cab02b5da867..1ecca479b5f4 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -905,8 +905,6 @@ static void __gb_lights_led_unregister(struct gb_channel *channel) return; led_classdev_unregister(cdev); - kfree(cdev->name); - cdev->name = NULL; channel->led = NULL; } @@ -1063,6 +1061,9 @@ static int gb_lights_light_register(struct gb_light *light) static void gb_lights_channel_free(struct gb_channel *channel) { + struct led_classdev *cdev = get_channel_cdev(channel); + + kfree(cdev->name); kfree(channel->attrs); kfree(channel->attr_group); kfree(channel->attr_groups); -- 2.25.1

2 months, 1 week

Re: [PATCH v2] greybus: operation: Fix NULL pointer dereference in gb_operation_message_alloc()

by Johan Hovold

On Fri, Aug 28, 2026 at 06:00:04PM +0800, Yang Zi wrote: > gb_connection_recv() accepts a received message whose advertised size is > smaller than struct gb_operation_msg_hdr. In particular, a header with a > size of zero passes the incomplete-message check and reaches > gb_operation_create_incoming(). Thanks for the fix. Please shorten the commit summary (Subject) to something less verbose, like: greybus: operation: fix NULL-deref on short request > This issue was found using a locally modified syzkaller. The > analysis and fix were assisted by GPT-5.6. This can go at the end of the commit message. > The subtraction used to derive the request payload size then underflows. > When gb_operation_message_alloc() adds the header size, the result wraps > to zero, bypassing the maximum-buffer-size check. kzalloc(0) returns > ZERO_SIZE_PTR and gb_operation_message_init() subsequently dereferences > it. > > Reject advertised sizes smaller than the message header. Also check the > payload size before adding the header size, so that the size calculation > cannot wrap and bypass the buffer-size limit. This is arguably two changes; a fix for the NULL-deref due to the missing header sanity check and a hardening against any further bugs like it. But I guess they can go in together in one patch like you do here. > Fixes: 87d208feb74f ("greybus: embed message buffer into message structure") This is not the commit that introduced the issue. This should be: Fixes: d90c25b0a279 ("greybus: let operation layer examine incoming data") as that's the commit that started acting on the header size field without first rejecting invalid headers (even if there was a WARN_ON() at that time). > Assisted-by: Codex:gpt-5.6 > Signed-off-by: Yang Zi <2959243019(a)qq.com> > --- > v2: > - Add the syzkaller provenance and Assisted-by trailer. > - Regenerate the patch for git-send-email. > - Verify the received patch with git am and checkpatch. > > drivers/greybus/operation.c | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c > index 7e12ffb2dd60..c3d51176c373 100644 > --- a/drivers/greybus/operation.c > +++ b/drivers/greybus/operation.c > @@ -364,14 +364,21 @@ gb_operation_message_alloc(struct gb_host_device *hd, u8 type, > { > struct gb_message *message; > struct gb_operation_msg_hdr *header; > - size_t message_size = payload_size + sizeof(*header); > + size_t message_size; > > - if (message_size > hd->buffer_size_max) { > + /* > + * Reject a payload size that would make the total message size > + * overflow, before it wraps around and bypasses the maximum > + * buffer size check. > + */ I think you can drop the comment. > + if (payload_size > hd->buffer_size_max - sizeof(*header)) { > dev_warn(&hd->dev, "requested message size too big (%zu > %zu)\n", And this should now say "payload size". > - message_size, hd->buffer_size_max); > + payload_size, hd->buffer_size_max - sizeof(*header)); > return NULL; > } > > + message_size = payload_size + sizeof(*header); > + > /* Allocate the message structure and buffer. */ > message = kmem_cache_zalloc(gb_message_cache, gfp_flags); > if (!message) > @@ -1047,6 +1054,11 @@ void gb_connection_recv(struct gb_connection *connection, > /* Use memcpy as data may be unaligned */ > memcpy(&header, data, sizeof(header)); > msg_size = le16_to_cpu(header.size); > + if (msg_size < sizeof(header)) { > + dev_err_ratelimited(dev, "%s: short message received (%zu < %zu)\n", > + connection->name, msg_size, sizeof(header)); > + return; > + } > if (size < msg_size) { > dev_err_ratelimited(dev, > "%s: incomplete message 0x%04x of type 0x%02x received (%zu < %zu)\n", Johan

2 months, 1 week

[BUG] greybus: ODEBUG free-active-timer in gb_operation_sync_timeout()

by Farhad Alemi

Hello, As part of the kernel research at ASU's SEFCOM lab, we hit the crash below. Crash reports can be found here: https://github.com/farhad-alemi/public_bug_reports/tree/main/165-warning-od… ODEBUG: free active (active state 0) object: ffff888014747a70 object type: timer_list hint: gb_operation_timeout+0x0/0x100 drivers/greybus/operation.c:1265 WARNING: lib/debugobjects.c:632 at debug_check_no_obj_freed+0x3fd/0x540 lib/debugobjects.c:1156, CPU#1: kworker/u8:3/10201 Call Trace: kmem_cache_free+0xcb/0x4d0 mm/slub.c:6378 gb_operation_sync_timeout+0x1c7/0x270 drivers/greybus/operation.c:1172 gb_operation_sync include/linux/greybus/operation.h:203 [inline] gb_svc_dme_peer_get+0x10a/0x250 drivers/greybus/svc.c:428 gb_interface_read_and_clear_init_status drivers/greybus/interface.c:380 [inline] gb_interface_enable+0x146/0x900 drivers/greybus/interface.c:1075 gb_module_register_interface drivers/greybus/module.c:162 [inline] gb_module_add+0x1b3/0x3d0 drivers/greybus/module.c:209 Our reproducer.c is available upon request. Happy to test a patch if that would help. Regards,

2 months, 1 week

[syzbot] [greybus?] [usb?] KASAN: slab-out-of-bounds Write in gb_operation_message_alloc

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 45c13f3f9e3b Merge tag 'hwlock-v7.3' of git://git.kernel.o.. 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=17ab5299580000 kernel config: https://syzkaller.appspot.com/x/.config?x=9b0fc292fc5639c dashboard link: https://syzkaller.appspot.com/bug?extid=2fd6aefc361af86911d5 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=137a3579580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=173ed625580000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/ac6556827073/disk-45c13f3f.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/01ff014f18d2/vmlinux-45c13f3f.… kernel image: https://storage.googleapis.com/syzbot-assets/77e9c6302a14/bzImage-45c13f3f.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2fd6aefc361af86911d5(a)syzkaller.appspotmail.com usb 4-1: invalid cport id 160 received ================================================================== BUG: KASAN: slab-out-of-bounds in gb_operation_message_init drivers/greybus/operation.c:341 [inline] BUG: KASAN: slab-out-of-bounds in gb_operation_message_alloc+0x26e/0x2c0 drivers/greybus/operation.c:385 Write of size 2 at addr ffff888100b7e582 by task syz.3.17/3979 CPU: 1 UID: 0 PID: 3979 Comm: syz.3.17 Not tainted syzkaller #0 PREEMPT(lazy) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 Call Trace: <IRQ> __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_operation_message_init drivers/greybus/operation.c:341 [inline] gb_operation_message_alloc+0x26e/0x2c0 drivers/greybus/operation.c:385 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+0xdb2/0x3700 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x462/0x9c0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1ca/0x360 kernel/time/hrtimer.c:2141 handle_softirqs+0x1d9/0x9b0 kernel/softirq.c:645 __do_softirq kernel/softirq.c:679 [inline] invoke_softirq kernel/softirq.c:519 [inline] __irq_exit_rcu+0x192/0x210 kernel/softirq.c:767 irq_exit_rcu+0x9/0x30 kernel/softirq.c:784 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 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674 RIP: 0010:lock_acquire+0x5e/0x370 kernel/locking/lockdep.c:5890 Code: 05 4f b0 92 0b 83 f8 07 0f 87 da 00 00 00 48 0f a3 05 de da 84 09 0f 82 b1 02 00 00 8b 35 7e e8 84 09 85 f6 0f 85 c7 00 00 00 <48> 8b 44 24 30 65 48 2b 05 ed af 92 0b 0f 85 f1 02 00 00 48 83 c4 RSP: 0018:ffffc90001567328 EFLAGS: 00000206 RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff89304d6c RDI: ffffffff87d29880 RBP: ffffffff898e49a0 R08: 00000000ef9d33e4 R09: 0000000000000007 R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 rcu_lock_acquire include/linux/rcupdate.h:309 [inline] rcu_read_lock include/linux/rcupdate.h:849 [inline] class_rcu_constructor include/linux/rcupdate.h:1216 [inline] unwind_next_frame+0xd1/0x2090 arch/x86/kernel/unwind_orc.c:495 arch_stack_walk+0x94/0xf0 arch/x86/kernel/stacktrace.c:25 stack_trace_save+0x8e/0xc0 kernel/stacktrace.c:122 kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6e/0x70 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4683 [inline] slab_alloc_node mm/slub.c:4996 [inline] kmem_cache_alloc_noprof+0x264/0x650 mm/slub.c:5010 alloc_pid+0x1bd/0x1930 kernel/pid.c:188 copy_process+0x52a8/0x8100 kernel/fork.c:2323 kernel_clone+0x176/0x9d0 kernel/fork.c:2766 __do_sys_clone3+0x214/0x290 kernel/fork.c:3069 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x119/0x710 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc24a59eec9 Code: 90 b8 01 00 00 00 b9 01 00 00 00 eb ec 0f 1f 40 00 b8 ea ff ff ff 48 85 ff 74 28 48 85 d2 74 23 49 89 c8 b8 b3 01 00 00 0f 05 <48> 85 c0 7c 14 74 01 c3 31 ed 4c 89 c7 ff d2 48 89 c7 b8 3c 00 00 RSP: 002b:00007fff626e2d18 EFLAGS: 00000206 ORIG_RAX: 00000000000001b3 RAX: ffffffffffffffda RBX: 00007fc24a55a460 RCX: 00007fc24a59eec9 RDX: 00007fc24a55a460 RSI: 0000000000000058 RDI: 00007fff626e2d70 RBP: 00007fc24a3bd6c0 R08: 00007fc24a3bd6c0 R09: 00007fff626e2e57 R10: 0000000000000008 R11: 0000000000000206 R12: ffffffffffffffe8 R13: 0000000000000006 R14: 00007fff626e2d70 R15: 00007fff626e2e58 </TASK> Allocated by task 3979: 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:398 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5414 [inline] __kmalloc_noprof+0x315/0x7e0 mm/slub.c:5439 _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+0xdb2/0x3700 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x462/0x9c0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1ca/0x360 kernel/time/hrtimer.c:2141 handle_softirqs+0x1d9/0x9b0 kernel/softirq.c:645 __do_softirq kernel/softirq.c:679 [inline] invoke_softirq kernel/softirq.c:519 [inline] __irq_exit_rcu+0x192/0x210 kernel/softirq.c:767 irq_exit_rcu+0x9/0x30 kernel/softirq.c:784 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 ffff888100b7e580 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 2 bytes inside of allocated 3-byte region [ffff888100b7e580, ffff888100b7e583) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100b7e flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff888100041500 dead000000000100 dead000000000122 raw: 0000000000000000 0000000000800080 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 0xd2c00(GFP_NOIO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 4953479885 set_page_owner include/linux/page_owner.h:33 [inline] post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1871 prep_new_page mm/page_alloc.c:1879 [inline] get_page_from_freelist+0xf4b/0x3430 mm/page_alloc.c:3943 __alloc_frozen_pages_noprof+0x2d7/0x2f70 mm/page_alloc.c:5436 alloc_slab_page mm/slub.c:3347 [inline] allocate_slab mm/slub.c:3462 [inline] new_slab+0xa9/0x6e0 mm/slub.c:3513 refill_objects+0xe3/0x410 mm/slub.c:7410 refill_sheaf mm/slub.c:2885 [inline] __pcs_replace_empty_main+0x35e/0x650 mm/slub.c:4774 alloc_from_pcs mm/slub.c:4850 [inline] slab_alloc_node mm/slub.c:4984 [inline] __do_kmalloc_node mm/slub.c:5413 [inline] __kmalloc_node_track_caller_noprof+0x634/0x820 mm/slub.c:5545 __kmemdup_nul mm/util.c:64 [inline] kstrdup+0x51/0xe0 mm/util.c:84 kstrdup_const+0x63/0x80 mm/util.c:104 __kernfs_new_node+0x9b/0xa10 fs/kernfs/dir.c:661 kernfs_new_node+0x117/0x150 fs/kernfs/dir.c:751 kernfs_create_link+0xcc/0x240 fs/kernfs/symlink.c:39 sysfs_do_create_link_sd+0x90/0x140 fs/sysfs/symlink.c:44 sysfs_do_create_link fs/sysfs/symlink.c:80 [inline] sysfs_create_link+0x61/0xc0 fs/sysfs/symlink.c:92 __add_disk+0x619/0xe40 block/genhd.c:500 add_disk_fwnode+0x118/0x480 block/genhd.c:593 page last free pid 47 tgid 47 ts 4951179657 stack trace: reset_page_owner include/linux/page_owner.h:26 [inline] __free_pages_prepare mm/page_alloc.c:1418 [inline] __free_frozen_pages+0x714/0xfc0 mm/page_alloc.c:2962 __kasan_populate_vmalloc_do mm/kasan/shadow.c:393 [inline] __kasan_populate_vmalloc+0x1ea/0x210 mm/kasan/shadow.c:424 kasan_populate_vmalloc include/linux/kasan.h:580 [inline] alloc_vmap_area+0x95d/0x2bb0 mm/vmalloc.c:2146 __get_vm_area_node+0x1ed/0x350 mm/vmalloc.c:3249 __vmalloc_node_range_noprof+0x262/0x1460 mm/vmalloc.c:4065 __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4166 alloc_thread_stack_node kernel/fork.c:359 [inline] dup_task_struct kernel/fork.c:930 [inline] copy_process+0x803/0x8100 kernel/fork.c:2133 kernel_clone+0x176/0x9d0 kernel/fork.c:2766 user_mode_thread+0xd1/0x120 kernel/fork.c:2843 call_usermodehelper_exec_work kernel/umh.c:169 [inline] call_usermodehelper_exec_work+0xcb/0x180 kernel/umh.c:155 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387 process_scheduled_works kernel/workqueue.c:3470 [inline] worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551 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 Memory state around the buggy address: ffff888100b7e480: 02 fc fc fc 07 fc fc fc 05 fc fc fc 07 fc fc fc ffff888100b7e500: 07 fc fc fc 07 fc fc fc 00 fc fc fc fa fc fc fc >ffff888100b7e580: 03 fc fc fc 00 fc fc fc 00 fc fc fc 05 fc fc fc ^ ffff888100b7e600: 05 fc fc fc 05 fc fc fc 05 fc fc fc 05 fc fc fc ffff888100b7e680: 05 fc fc fc 05 fc fc fc 02 fc fc fc 02 fc fc fc ================================================================== ---------------- Code disassembly (best guess): 0: 05 4f b0 92 0b add $0xb92b04f,%eax 5: 83 f8 07 cmp $0x7,%eax 8: 0f 87 da 00 00 00 ja 0xe8 e: 48 0f a3 05 de da 84 bt %rax,0x984dade(%rip) # 0x984daf4 15: 09 16: 0f 82 b1 02 00 00 jb 0x2cd 1c: 8b 35 7e e8 84 09 mov 0x984e87e(%rip),%esi # 0x984e8a0 22: 85 f6 test %esi,%esi 24: 0f 85 c7 00 00 00 jne 0xf1 * 2a: 48 8b 44 24 30 mov 0x30(%rsp),%rax <-- trapping instruction 2f: 65 48 2b 05 ed af 92 sub %gs:0xb92afed(%rip),%rax # 0xb92b024 36: 0b 37: 0f 85 f1 02 00 00 jne 0x32e 3d: 48 rex.W 3e: 83 .byte 0x83 3f: c4 .byte 0xc4 --- 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(a)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

2 months, 1 week

[BUG] greybus: ODEBUG init-active on a greybus_reset timer, and use-after-free in do_work()

by Farhad Alemi

Hello, As part of the kernel research at ASU's SEFCOM lab, we hit the crash below. Crash reports can be found here: https://github.com/farhad-alemi/public_bug_reports/tree/main/167-warning-od… greybus 3-svc: Resetting the greybus network, watch out!!! ODEBUG: init active (active state 0) object: ffffffff92bbc2a0 object type: timer_list hint: greybus_reset+0x0/0x50 WARNING: lib/debugobjects.c:632 at __debug_object_init+0x2a8/0x4a0 lib/debugobjects.c:790, CPU#0: kworker/0:4/11040 Call Trace: debug_timer_init kernel/time/timer.c:788 [inline] debug_init kernel/time/timer.c:836 [inline] timer_init_key+0x34/0x1e0 kernel/time/timer.c:880 list_splice_tail_init include/linux/list.h:620 [inline] do_work+0x19e/0x2b0 drivers/md/dm-kcopyd.c:664 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0x881/0x1170 kernel/workqueue.c:3397 worker_thread+0x988/0xde0 kernel/workqueue.c:3478 WARNING: kernel/workqueue.c:806 at insert_work+0x1f3/0x240 BUG: KASAN: slab-use-after-free in do_work+0x257/0x2b0 Our reproducer.c is available upon request. Happy to test a patch if that would help. Regards,

2 months, 1 week

[PATCH 0/7] Add Greybus Sotfsvc and UART Node drivers

by Ayush Singh

A Greybus network needs an SVC (Supervisory Controller) to bring interfaces up, assign device IDs and connect CPorts to the AP. On a UniPro network the SVC is a real entity on the bus. On transports that merely carry Greybus messages - a UART, an I2C bus, a network link - nothing on the wire plays that role, so the SVC has to be emulated somewhere: in a user-space bridge (gbridge), in coprocessor firmware (cc1352p7 in gb-beagleplay), or open-coded inside the host driver itself. This series moves the emulation into the kernel and makes it shared. This was discussed in a prior RFC as well [2], but to keep things short, removing the need for an external SVC greatly simplifies the greybus network setup when nodes are directly connected over common transports such as UART, I2C etc. gb-uart-node gb-softsvc greybus core (transport, serdev) <-> (SVC + host device) <-> (bundles, protocols) NodeOps module_insert() submit_message() module_remove() gb-softsvc registers itself as a Greybus host device and answers the SVC-side operations the core expects during interface bring-up and teardown. A host driver implements the NodeOps trait to push data towards its node, calls module_insert() to announce a new node, submit_message() to hand incoming Greybus messages back to the core, and module_remove() on disconnect. The first user is gb-uart-node, a driver for Greybus nodes attached over a plain serial port. Framing is HDLC, with a one-byte address (0x01 for Greybus) and control byte, followed by the 16-bit CPort ID and the Greybus message. No SVC firmware is required on the far end, so the node can be a bare microcontroller speaking Greybus - a BeagleConnect Freedom over its serial link, in this case. The testing is performed with greybus-zephyr [0] implementation. Both drivers are written in Rust, which is why the middle of the series is abstractions rather than drivers. Only the APIs these two drivers need are covered: protocols.rs abstracts the SVC-facing parts of greybus_protocols.h, and types such as Greybus Interface do not implement AlwaysRefCounted yet. The intent is to grow this as more Rust host drivers appear rather than to abstract the whole subsystem up front. Patches 1 and 2 are small C-side preparations to the Greybus core: exporting gb_connection_get()/gb_connection_put() and adding gb_connection_hd_find_by_intf(), a lookup by remote interface and CPort id for callers that only know the far end of a connection. Patch 3 adds a CRC-CCITT abstraction, needed for HDLC frame checks. Patch 4 adds the Greybus abstractions, patches 5 and 6 the two drivers, and patch 7 the device tree binding for BeagleConnect Freedom. Open questions *************** - gb-uart-node imports types from gb-softsvc, so the series carries the Rust-to-Rust cross-module calling setup from nova-core [1]: gb_softsvc_exports.c plus the Makefile plumbing that emits crate metadata and generates the export list. This is a workaround for the build system not supporting Rust cross-module dependencies natively, and it should go away once that lands. - Connection create/destroy and interface activate/resume in gb-softsvc currently just acknowledge the request. Callbacks into NodeOps can be added when a transport actually needs to act on them; I did not want to invent an interface without a user. - Zerocopy is currently not being used in grebeybus/protocols.rs. They cannot be derived yet since types generated by bindgen do not have them, and it seems explicitly forbindden to manually impl the traits. So using old traits from transmute. - The bindings are supposed to be created for actual device, but any MCU that supports Zephyr, can run the greybus-zephyr firmware with UART transport. So not sure if adding a beagle,beagleconnect-freedom compatible is the correct choice here. - The individual patches can be spun off into independent patch series if required. The reason for this single patch series is to provide a complete picture of usage. - Since gb-softsvc currently is not being used from a C driver, no C API is provided. However, if required, it can be added. - Writing to UART from gb-uart-node is currently a bit broken. I am not quite sure what the safe way is to go from a non-bound device to a bound device. Any suggestions on this front are welcome. - I am not sure if Rust abstractions should have a seperate entry in MAINTAINERS with me as the maintainer, or if they should just be added to the respective subsystem entries. [0]: https://github.com/beagleboard/greybus-zephyr [1]: https://lore.kernel.org/all/20260622-nova-exports-v5-0-6191773fc977@nvidia.… [2]: https://lore.kernel.org/all/ecca8eb2-8e5a-4770-bcf6-3fb49773088b@beagleboar… Signed-off-by: Ayush Singh <ayush(a)beagleboard.org> --- Ayush Singh (7): greybus: connection: Export gb_connection_get() and gb_connection_put() greybus: connection: Add gb_connection_hd_find_by_intf() rust: crc_ccitt: add CRC-CCITT abstraction rust: kernel: Add greybus abstractions drivers: greybus: Add software SVC implementation greybus: Add Rust UART node driver dt-bindings: beagle: Add BeagleConnect Freedom .../beagle/beagle,beagleconnect-freedom.yaml | 30 ++ MAINTAINERS | 15 + drivers/greybus/.gitignore | 1 + drivers/greybus/Kconfig | 27 ++ drivers/greybus/Makefile | 50 +++ drivers/greybus/connection.c | 28 +- drivers/greybus/gb_softsvc.rs | 472 +++++++++++++++++++++ drivers/greybus/gb_softsvc_exports.c | 15 + drivers/greybus/gb_uart_node.rs | 231 ++++++++++ include/linux/greybus/connection.h | 6 + lib/crc/Kconfig | 7 + rust/bindings/bindings_helper.h | 2 + rust/kernel/crc_ccitt.rs | 26 ++ rust/kernel/greybus/hd.rs | 315 ++++++++++++++ rust/kernel/greybus/mod.rs | 230 ++++++++++ rust/kernel/greybus/protocols.rs | 392 +++++++++++++++++ rust/kernel/lib.rs | 4 + 17 files changed, 1849 insertions(+), 2 deletions(-) --- base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727 change-id: 20260810-gb-uart-transport-9255d6557c4c Best regards, -- Ayush Singh <ayush(a)beagleboard.org>

2 months, 2 weeks

[PATCH] staging: greybus: audio: use dynamic vendor and product IDs

by huangjia2hi＠163.com

From: Jiazhi Huang <huangjia2hi(a)163.com> Replace hardcoded magic numbers for Vendor ID (vid) and Product ID (pid) in gb_audio_mgmt_node_desc with dynamic values obtained from the greybus interface. This resolves the associated TODO comments by using the actual vendor and product IDs provided by the interface structure. Signed-off-by: Jiazhi Huang <huangjia2hi(a)163.com> --- drivers/staging/greybus/audio_module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/audio_module.c b/drivers/staging/greybus/audio_module.c index 4cd1f42c11f0..9eed3ac0c49d 100644 --- a/drivers/staging/greybus/audio_module.c +++ b/drivers/staging/greybus/audio_module.c @@ -358,8 +358,8 @@ static int gb_audio_probe(struct gb_bundle *bundle, dev_dbg(dev, "Inform set_event:%d to above layer\n", 1); /* prepare for the audio manager */ strscpy(desc.name, gbmodule->name, sizeof(desc.name)); - desc.vid = 2; /* todo */ - desc.pid = 3; /* todo */ + desc.vid = bundle->intf->vendor_id; + desc.pid = bundle->intf->product_id; desc.intf_id = gbmodule->dev_id; desc.op_devices = gbmodule->op_devices; desc.ip_devices = gbmodule->ip_devices; -- 2.55.0

2 months, 2 weeks

[PATCH] staging: greybus: uart: convert from IDR to XArray

by Dmitry Priz

IDR is deprecated in favor of XArray, which manages its own internal locking and provides a more consistent allocation API. Convert tty_minors from an IDR to an allocating XArray. Update the error check in gb_uart_probe() from -ENOSPC to -EBUSY, since that is the error xa_alloc() returns when the allocation range is exhausted, unlike idr_alloc() which returned -ENOSPC. Build-tested and verified via boot in QEMU: the module loads, registers with the greybus core, and unloads cleanly. Signed-off-by: Dmitry Priz <dimahtms(a)gmail.com> --- drivers/staging/greybus/uart.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index 7d060b4cd33d..edd6b0e25c8c 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -22,7 +22,7 @@ #include <linux/serial.h> #include <linux/tty_driver.h> #include <linux/tty_flip.h> -#include <linux/idr.h> +#include <linux/xarray.h> #include <linux/fs.h> #include <linux/kdev_t.h> #include <linux/kfifo.h> @@ -67,7 +67,7 @@ struct gb_tty { }; static struct tty_driver *gb_tty_driver; -static DEFINE_IDR(tty_minors); +static DEFINE_XARRAY_ALLOC(tty_minors); static DEFINE_MUTEX(table_lock); static int gb_uart_receive_data_handler(struct gb_operation *op) @@ -342,7 +342,7 @@ static struct gb_tty *get_gb_by_minor(unsigned int minor) struct gb_tty *gb_tty; mutex_lock(&table_lock); - gb_tty = idr_find(&tty_minors, minor); + gb_tty = xa_load(&tty_minors, minor); if (gb_tty) { mutex_lock(&gb_tty->mutex); if (gb_tty->disconnected) { @@ -359,14 +359,19 @@ static struct gb_tty *get_gb_by_minor(unsigned int minor) static int alloc_minor(struct gb_tty *gb_tty) { - int minor; + u32 id; + int ret; mutex_lock(&table_lock); - minor = idr_alloc(&tty_minors, gb_tty, 0, GB_NUM_MINORS, GFP_KERNEL); + ret = xa_alloc(&tty_minors, &id, gb_tty, XA_LIMIT(0, GB_NUM_MINORS - 1), GFP_KERNEL); mutex_unlock(&table_lock); - if (minor >= 0) - gb_tty->minor = minor; - return minor; + + if (ret < 0) + return ret; + + gb_tty->minor = id; + + return id; } static void release_minor(struct gb_tty *gb_tty) @@ -375,7 +380,7 @@ static void release_minor(struct gb_tty *gb_tty) gb_tty->minor = 0; /* Maybe should use an invalid value instead */ mutex_lock(&table_lock); - idr_remove(&tty_minors, minor); + xa_erase(&tty_minors, minor); mutex_unlock(&table_lock); } @@ -854,7 +859,7 @@ static int gb_uart_probe(struct gbphy_device *gbphy_dev, minor = alloc_minor(gb_tty); if (minor < 0) { - if (minor == -ENOSPC) { + if (minor == -EBUSY) { dev_err(&gbphy_dev->dev, "no more free minor numbers\n"); retval = -ENODEV; @@ -984,7 +989,7 @@ static void gb_tty_exit(void) { tty_unregister_driver(gb_tty_driver); tty_driver_kref_put(gb_tty_driver); - idr_destroy(&tty_minors); + xa_destroy(&tty_minors); } static const struct gbphy_device_id gb_uart_id_table[] = { -- 2.53.0

2 months, 2 weeks

Re: [PATCH] greybus: operation: Fix NULL pointer dereference in gb_operation_message_alloc()

by Johan Hovold

On Tue, Aug 25, 2026 at 05:23:09PM +0800, Yang Zi wrote: > gb_connection_recv() reads msg_size from the received message header but > only rejects it when it is larger than the received buffer > ("size < msg_size"); it does not reject msg_size smaller than the message > header itself. A malicious or corrupted header.size of 0 passes that > check and is forwarded to gb_operation_create_incoming() with size 0. > > There, request_size = size - sizeof(struct gb_operation_msg_hdr) > underflows to SIZE_MAX - 7, and in gb_operation_message_alloc() > message_size = payload_size + sizeof(*header) wraps back around to 0. > The "message_size > hd->buffer_size_max" check is therefore bypassed, > kzalloc(0) returns ZERO_SIZE_PTR, and gb_operation_message_init() writes > header->size to that pointer. > > KASAN report: > > BUG: KASAN: null-ptr-deref in gb_operation_message_init drivers/greybus/operation.c:340 [inline] [greybus] > BUG: KASAN: null-ptr-deref in gb_operation_message_alloc+0xab4/0xdb0 drivers/greybus/operation.c:385 [greybus] > Write of size 2 at addr 0000000000000010 by task syz.0.1/1100 > > Fix this by rejecting messages whose claimed size is smaller than the > message header in gb_connection_recv(), and additionally make > gb_operation_message_alloc() overflow-safe by comparing the payload size > against hd->buffer_size_max - sizeof(*header) before adding the header > size. > > Signed-off-by: Yang Zi <2959243019(a)qq.com> How was this issue found and fixed? Did you use an LLM and are missing an Assisted-by tag? Based on a quick glance, this look correct, but your patch is corrupt and cannot be applied. (This appears to be the case with all the 30+ patches you sent out today.) Please fix your mail setup and send a v2 (try sending it to yourself first and make sure you can apply it and run checkpatch on it). You should look into using git-send-email. Johan

2 months, 2 weeks

[PATCH] staging: greybus: audio_manager: add missing newlines in sysfs show

by Kosugi Souta

sysfs show functions should terminate output with a trailing newline. Add the missing '\n' to the six show functions in audio_manager_module.c. Compile tested only. Signed-off-by: Kosugi Souta <k.souta0926(a)gmail.com> --- drivers/staging/greybus/audio_manager_module.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/audio_manager_module.c b/drivers/staging/greybus/audio_manager_module.c index dc90cc2d2308..5737f2a32f5a 100644 --- a/drivers/staging/greybus/audio_manager_module.c +++ b/drivers/staging/greybus/audio_manager_module.c @@ -75,7 +75,7 @@ static void gb_audio_module_release(struct kobject *kobj) static ssize_t gb_audio_module_name_show(struct gb_audio_manager_module *module, struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "%s", module->desc.name); + return sysfs_emit(buf, "%s\n", module->desc.name); } static struct gb_audio_manager_module_attribute gb_audio_module_name_attribute = @@ -84,7 +84,7 @@ static struct gb_audio_manager_module_attribute gb_audio_module_name_attribute = static ssize_t gb_audio_module_vid_show(struct gb_audio_manager_module *module, struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "%d", module->desc.vid); + return sysfs_emit(buf, "%d\n", module->desc.vid); } static struct gb_audio_manager_module_attribute gb_audio_module_vid_attribute = @@ -93,7 +93,7 @@ static struct gb_audio_manager_module_attribute gb_audio_module_vid_attribute = static ssize_t gb_audio_module_pid_show(struct gb_audio_manager_module *module, struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "%d", module->desc.pid); + return sysfs_emit(buf, "%d\n", module->desc.pid); } static struct gb_audio_manager_module_attribute gb_audio_module_pid_attribute = @@ -103,7 +103,7 @@ static ssize_t gb_audio_module_intf_id_show(struct gb_audio_manager_module *modu struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "%d", module->desc.intf_id); + return sysfs_emit(buf, "%d\n", module->desc.intf_id); } static struct gb_audio_manager_module_attribute @@ -114,7 +114,7 @@ static ssize_t gb_audio_module_ip_devices_show(struct gb_audio_manager_module *m struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "0x%X", module->desc.ip_devices); + return sysfs_emit(buf, "0x%X\n", module->desc.ip_devices); } static struct gb_audio_manager_module_attribute @@ -125,7 +125,7 @@ static ssize_t gb_audio_module_op_devices_show(struct gb_audio_manager_module *m struct gb_audio_manager_module_attribute *attr, char *buf) { - return sysfs_emit(buf, "0x%X", module->desc.op_devices); + return sysfs_emit(buf, "0x%X\n", module->desc.op_devices); } static struct gb_audio_manager_module_attribute -- 2.53.0

2 months, 2 weeks

← Newer
1
...
9
10
11
12
13
14
15
...
93
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev