greybus-dev

greybus-dev@lists.linaro.org

21 participants
881 discussions

[PATCH] staging: greybus: use sysfs_emit instead of sprintf in light.c

by Tomasz Unger

Per Documentation/filesystems/sysfs.rst, new implementations of show() methods should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space, since it is aware of the sysfs PAGE_SIZE buffer and includes sanity checks that sprintf() lacks. This fixes fade_in_show() and fade_out_show() (both generated by the gb_lights_fade_attr() macro) and color_show(). Signed-off-by: Tomasz Unger <tomasz.unger(a)yahoo.pl> --- Verified with checkpatch.pl - no errors or warnings. Compiled the gb-light module successfully with CONFIG_GREYBUS_LIGHT=m and CONFIG_LEDS_CLASS_FLASH=m (both previously disabled). greybus.ko, led-class-flash.ko and gb-light.ko all load without errors in a QEMU environment (verified via insmod and lsmod, dmesg shows no errors). This confirms the modules load cleanly but does not exercise the changed sysfs show() code paths, which would require an actual Greybus light device bound to the driver. --- drivers/staging/greybus/light.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index cab02b5da867..2689f9a7524a 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -173,7 +173,7 @@ static ssize_t fade_##__dir##_show(struct device *dev, \ struct led_classdev *cdev = dev_get_drvdata(dev); \ struct gb_channel *channel = get_channel_from_cdev(cdev); \ \ - return sprintf(buf, "%u\n", channel->fade_##__dir); \ + return sysfs_emit(buf, "%u\n", channel->fade_##__dir); \ } \ \ static ssize_t fade_##__dir##_store(struct device *dev, \ @@ -220,7 +220,7 @@ static ssize_t color_show(struct device *dev, struct device_attribute *attr, struct led_classdev *cdev = dev_get_drvdata(dev); struct gb_channel *channel = get_channel_from_cdev(cdev); - return sprintf(buf, "0x%08x\n", channel->color); + return sysfs_emit(buf, "0x%08x\n", channel->color); } static ssize_t color_store(struct device *dev, struct device_attribute *attr, --- base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f change-id: 20260819-greybus-light-sysfs-emit-4b8beab74fcc Best regards, -- Tomasz Unger <tomasz.unger(a)yahoo.pl>

1 month, 2 weeks

[PATCH] staging: greybus: use sysfs_emit instead of sprintf in gbphy.c

by Tomasz Unger

Per Documentation/filesystems/sysfs.rst, new implementations of show() methods should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space, since it is aware of the sysfs PAGE_SIZE buffer and includes sanity checks that sprintf() lacks. Signed-off-by: Tomasz Unger <tomasz.unger(a)yahoo.pl> --- Verified with checkpatch.pl - no errors or warnings. Compiled the gb-gbphy module successfully with CONFIG_GREYBUS=m and CONFIG_GREYBUS_BRIDGED_PHY=m (both previously disabled). Both greybus.ko and gb-gbphy.ko load without errors in a QEMU environment (verified via insmod and lsmod). This confirms the modules load cleanly but does not exercise the changed sysfs show() code path, which would require an actual Greybus device (or a userspace simulator such as gbsim) bound to the driver. --- drivers/staging/greybus/gbphy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c index bdb0f5164a6f..bb9a5b538e6e 100644 --- a/drivers/staging/greybus/gbphy.c +++ b/drivers/staging/greybus/gbphy.c @@ -31,7 +31,7 @@ static ssize_t protocol_id_show(struct device *dev, { struct gbphy_device *gbphy_dev = to_gbphy_dev(dev); - return sprintf(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); + return sysfs_emit(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); } static DEVICE_ATTR_RO(protocol_id); --- base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f change-id: 20260818-greybus-gbphy-sysfs-emit-69739912458e Best regards, -- Tomasz Unger <tomasz.unger(a)yahoo.pl>

1 month, 2 weeks

[PATCH] staging: greybus: audio_manager_module: add missing newlines to sysfs_emit() calls

by Avhi M.

sysfs attributes are expected to be terminated with a newline. Add the missing '\n' to the sysfs_emit() format strings in the module attribute show functions, fixing the checkpatch --strict warning: WARNING: return sysfs_emit(...) formats should include a terminating newline Signed-off-by: Avhi M. <dev(a)avhi.in> --- 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 dc90cc2d2..5737f2a32 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.43.0

1 month, 2 weeks

[PATCH] staging: greybus: gbphy: use sysfs_emit() instead of sprintf()

by Mohit Mishra

protocol_id_show() uses sprintf() to format sysfs output into the page buffer. Convert it to sysfs_emit(), which is the preferred helper for sysfs show() callbacks as it enforces page boundary checks. Similar conversions have already been made elsewhere in this subsystem (e.g. loopback.c, arche-platform.c). Signed-off-by: Mohit Mishra <mishraloopmohit(a)gmail.com> --- drivers/staging/greybus/gbphy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c index bdb0f5164a6f..bb9a5b538e6e 100644 --- a/drivers/staging/greybus/gbphy.c +++ b/drivers/staging/greybus/gbphy.c @@ -31,7 +31,7 @@ static ssize_t protocol_id_show(struct device *dev, { struct gbphy_device *gbphy_dev = to_gbphy_dev(dev); - return sprintf(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); + return sysfs_emit(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id); } static DEVICE_ATTR_RO(protocol_id); -- 2.43.0

1 month, 2 weeks

[PATCH] staging: greybus: loopback: Fix argument alignment

by Noah Techoueyres

Align function arguments to match the open parenthesis per the kernel coding style guidelines. Signed-off-by: Noah Techoueyres <noahtechoueyres(a)gmail.com> --- drivers/staging/greybus/loopback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index ea57b1f5d156..c33b8aa5871c 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -679,7 +679,7 @@ static int gb_loopback_request_handler(struct gb_operation *operation) } if (!gb_operation_response_alloc(operation, - len + sizeof(*response), GFP_KERNEL)) { + len + sizeof(*response), GFP_KERNEL)) { dev_err(dev, "error allocating response\n"); return -ENOMEM; } -- 2.43.0

1 month, 2 weeks

[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

1 month, 2 weeks

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

1 month, 2 weeks

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

1 month, 2 weeks

[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

1 month, 2 weeks

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

1 month, 2 weeks

← Newer
1
...
4
5
6
7
8
9
10
...
89
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev