Conversation
The field has been removed, but the kerneldoc not. Let's take care of this. This patch fixes the following warning: Warning: drivers/media/i2c/ov9282.c:223 Excess struct member 'mutex' description in 'ov9282' Fixes: 0c69a96 ("media: i2c: ov9282: Switch to using the sub-device state lock") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
The variable has been previously removed but not its kerneldoc. Also remove the leftover reference to state in the description of qlock. This patch fixes the following warning: Warning: drivers/media/platform/renesas/rzg2l-cru/rzg2l-cru.h:164 Excess struct member 'state' description in 'rzg2l_cru_dev' Fixes: 85d8820 ("media: rzg2l-cru: Remove the 'state' variable") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
The argument args is not documented, and the latest kernel version complains about that. This fixes the following warning: Warning: include/media/media-entity.h:1394 function parameter 'args' not described in 'media_entity_call' Fixes: 48a7c4b ("[media] docs-rst: improve the kAPI documentation for the mediactl") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds. Fixes: b4e3e59 ("[media] rc: add sunxi-ir driver") Cc: [email protected] Co-developed-by: Ijae Kim <[email protected]> Signed-off-by: Ijae Kim <[email protected]> Signed-off-by: Myeonghun Pak <[email protected]> Signed-off-by: Sean Young <[email protected]>
Explicitly assigning .driver_data in drivers that don't use this member is silly and a bit irritating. Drop it. Also simplify the list terminator entry to be just empty to match what most other device_id tables do. While touching these arrays convert them to use named initializers, empty list terminators and no comma after the terminator. There is no changed semantic, not even a change in the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) <[email protected]> Signed-off-by: Sean Young <[email protected]>
Instead of using magic constants define an enum that that makes it easier to keep .driver_data and the array of different types in sync. While touching the pnp_device_id array simplify the list terminator and use named initializers which better show which struct members are actually assigned to. Signed-off-by: Uwe Kleine-König (The Capable Hub) <[email protected]> Signed-off-by: Sean Young <[email protected]>
…ugfs clash The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become "<dev>.cec" and "<dev>.cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c4 ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: [email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
The commit dccc0c3 ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3 ("media: rc: fix race between unregister and urb/irq callbacks") Cc: [email protected] Signed-off-by: Jonas Karlman <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL. Fixes: d69ae57 ("[media] cec: add STM32 cec driver") Cc: [email protected] Signed-off-by: Weigang He <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
Add check to prevent overflowing msg.msg[] in case the incoming data is malformed. Signed-off-by: Hans Verkuil <[email protected]> Reviewed-by: Sean Young <[email protected]> Fixes: 056f282 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: [email protected]
cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled. Fixes: 490d84f ("media: cec: forgot to cancel delayed work") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=051024d603432b4ab395 Suggested-by: Hillf Danton <[email protected]> Cc: [email protected] Signed-off-by: Biren Pandya <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC and updating the logical address registers. The wait result is ignored, so a timeout can still be reported as a successful logical address update. Return the polling error before touching the address registers. Compute the address mask only for valid logical addresses so the invalid-address path does not evaluate a shift based on CEC_LOG_ADDR_INVALID. Signed-off-by: Pengpeng Hou <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
cec_pin_update() fills work_pin_events[] and work_pin_ts[], then increments work_pin_num_events. cec_pin_thread_func() uses that counter to decide when to read the FIFO entries. Do not let the counter update be observed without the event update. Also do not let a freed slot be reused before the thread has finished reading it. Use release operations when publishing an entry and releasing a slot, and acquire operations when consuming those counter updates. Leave the other work_pin_num_events users as they do not participate in this FIFO publication path. Fixes: ea5c8ef ("media: cec-pin: add low-level pin hardware support") Signed-off-by: Gui-Dong Han <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
Since commit 2062410 ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap"), the rc-rc5-tv keymap is no longer in the tree. Fixes: 2062410 ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap") Signed-off-by: Sean Young <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]>
Since commit af86ce7 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map"), the RC_MAP_HAUPPAUGE_NEW define is no longer used. Fixes: af86ce7 ("[media] remove the old RC_MAP_HAUPPAUGE_NEW RC map") Signed-off-by: Sean Young <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]>
When loading a rc keymap, rc_map_get() attempts to load the kernel module using the keymap name. The rc_map RC_MAP_VIDEOMATE_K100 is defined to "rc-videomate-k100" but the module is called rc-videomate-m1f.ko, so therefore automagic loading of the keymap will fail. Rename the module to match. Signed-off-by: Sean Young <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]>
The list is out of sync, so add missing entries, remove obsolete entries and sort. Signed-off-by: Sean Young <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]>
…eration This series came about as we had a customer ask about using imx355, so I had a look at what was going on. There was significant duplication between the various mode register lists, unused parameters around, and no support for advertising the crop rectangles through get_selection. It also wasn't using V4L2_CCI so had all the boilerplate for writing registers. The customer also wanted to run the sensor over only 2 CSI2 data lanes which required some rework of the clock setup so that the MIPI link frequency could be run at 445MHz instead of the 360MHz used for 4 lane mode. V2 has some fairly substantial differences to V1 as I obtained a datasheet. Whilst some things worked perfectly, the datasheet declared them as prohibited. This was largely using dual PLL mode in 2 lane mode, and LLP is restricted to specific values. Link frequencies are therefore now derived from the PLL configuration, and pixel rate is computed from that. Being able to refer against the datasheet, I've pulled an updated version of David Heidelberg's patch for 24MHz clock support into this series. I've tried to keep it that the earlier patches are largely cleanups or minor improvements, and then we get adding 2 lane support, and converting to using subdev state as they are larger patches. To: Sakari Ailus <[email protected]> To: Mauro Carvalho Chehab <[email protected]> To: Rob Herring <[email protected]> To: Krzysztof Kozlowski <[email protected]> To: Conor Dooley <[email protected]> To: Richard Acayan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: David Heidelberg <[email protected]> Cc: Jacopo Mondi <[email protected]> Cc: [email protected] --- Changes in v4: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v3: https://lore.kernel.org/r/[email protected] Changes in v3: - Fixed a number of issues picked up by sashiko-bot - Unintentionally dropped writing reg 0x030b, which is at the default value anyway. - Swapped len and val in intermediate patches adding imx355_write_reg before converting to cci_write - Initialise colorspace in _open for try_fmt. - IMX355_REG_TEST_PATTERN is a 16 bit register, but was defined as 8 bit. - Call pm_runtime_dont_use_autosuspend on remove / probe error - Missed subdev_lock in set_stream. - Not addressed the pre-existing issues of double power_off in _probe error path, nor potential for VBLANK update on mode change not calling s_ctrl if the new value happens to be the same and therefore exposure range being incorrect. I'll look at them as separate fixes. - Variable definition for format and state in imx355_set_ctrl got pushed into the wrong patch - Collected Krzysztof's R-b tag for the binding patch. - Link to v2: https://lore.kernel.org/r/[email protected] Changes in v2: - Collected Jacopo's R-b tags and implement his review comments. - Add patches to switch to using the subdev state, clean up colorspace (sets RAW), use a define for the exposure offset. - Added DT binding update to permit 2 CSI2 data lanes. - Link to v1: https://lore.kernel.org/r/[email protected] --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 4, "change-id": "20260506-media-imx355-a30f5be3deda", "prefixes": [], "prerequisites": [ "base-commit: 254f496" ], "history": { "v1": [ "[email protected]" ], "v2": [ "[email protected]" ], "v3": [ "[email protected]" ] } } }
The IMX355 sensor supports multiple external clock frequencies, including 19.2 MHz and 24 MHz. The driver currently supports only fixed 19.2 MHz input clock. Refactor the clock handling to make the PLL configuration dependent on the external clock frequency and add support for 24 MHz. Introduce a table of clock parameter sets and program the corresponding EXTCLK frequency and PLL multipliers to maintain consistent internal VCO frequencies across supported inputs. The PLL settings are adjusted so that OP VCO remains at 720 MHz This preserves existing timing characteristics while allowing systems using a 24 MHz clock to operate correctly. No functional change for existing 19.2 MHz users. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: David Heidelberg <[email protected]> Signed-off-by: Dave Stevenson <[email protected]>
The sensor supports output over either 2 or 4 CSI2 data lanes. The binding only permitted the 4 lane configuration. Add the 2 lane configuration as an option. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
A large number of registers are identical within all the modes. Move those to imx355_global_regs. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
Registers 0x0340 and 0x0341 (FRM_LENGTH_LINES) are already written from the set_ctrl(V4L2_CID_VBLANK) handler, so don't write them from the mode register list. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
Currently the cropping is set via register entries in the per mode register lists. Add the crop information to the mode structure as a v4l2_rect, and set the registers programmatically. Signed-off-by: Dave Stevenson <[email protected]>
The driver already has the LLP value stored in the mode structure, but also had the same value set via register writes in the mode's register list. Remove this duplication. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
Compute the binning registers based on the difference between the mode width/height vs the crop width/height. Signed-off-by: Dave Stevenson <[email protected]>
The link_freq_index value in imx355_mode is unused, so remove it. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
The pixel rate is always the same, so there is no need to try and recompute it in imx355_set_pad_format, and then no need to have the pointer to it stored. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
fll_min (Frame Length Lines) is set to the same value as fll_def for all modes, which makes it redundant. The actual value is also erroneous as the sensor works in all the defined modes with FLL set at the mode height + 20 lines, so set the vblank control minimum to 20 rather than varying it. This also improves the maximum frame rate achievable. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
Provide all the cropping information via get_selection. Signed-off-by: Dave Stevenson <[email protected]>
Avoid powering the sensor up and down unnecessarily by using pm_runtime's autosuspend_delay feature. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]>
Use the new comon CCI register access helpers to replace the private register access helpers in the imx355 driver. Signed-off-by: Dave Stevenson <[email protected]>
The colorspace fields were left set to 0 when they should be set appropriately for a raw image sensor. Add those values. Signed-off-by: Dave Stevenson <[email protected]>
The difference between frame length and max exposure time in lines is 10. That had been used as a bare value in calculations. Move it to a define, and use that define. Signed-off-by: Dave Stevenson <[email protected]>
This avoids the set_ctrl handler being called under any circumstances, as it will return an error for the unhandled ctrl. Signed-off-by: Dave Stevenson <[email protected]>
In preparation for additional options in the PLL setup, compute the link frequency rather than using a hardcoded value. Signed-off-by: Dave Stevenson <[email protected]>
The sensor supports 2 or 4 lane readout, but the driver only allowed for 4 lanes. Add 2 lane support. The clock tree only supports single PLL mode to feed both IOP (MIPI) and IVT (Pixel array). 2 lane mode supports a MIPI link frequency of up to 445MHz (890Mbit/s) cf 360MHz (720Mbit/s) for 4lane. Update clock setup and pixel rates to match. Signed-off-by: Dave Stevenson <[email protected]>
The subdev state is now preferred rather than handling crop and format within the driver state, so switch the driver to using it. Signed-off-by: Dave Stevenson <[email protected]>
All the information for the mode is now stored within the subdev state, so configure the sensor based on that. Signed-off-by: Dave Stevenson <[email protected]>
6by9
pushed a commit
that referenced
this pull request
Aug 3, 2026
[ Upstream commit b23705e ] strset_add_str_mem() might reallocate the strset data buffer in order to accommodate the provided string 's'. However, if 's' points to a string already present in the buffer, it becomes dangling after the realloc. This leads to a use-after-free when attempting to memcpy() the string into the new buffer. One scenario that triggers this problematic path is when resolve_btfids attempts to patch kfunc prototypes using existing BTF parameter names: | resolve_btfids: function bpf_list_push_back_impl already exists in BTF | Segmentation fault (core dumped) Compiling resolve_btfids with fsanitize=address generates a detailed report of the UAF: | ================================================================= | ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 | ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818 | READ of size 5 at 0x7f4c4a500bd4 thread T0 | #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7) | #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2 | #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8 | #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14 | #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9 | #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9 | #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6 | #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 | #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3 | raspberrypi#9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860) | | 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8) | freed by thread T0 here: | #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700) | #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9 | #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13 | | previously allocated by thread T0 here: | #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3) | #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20 While resolve_btfids could be refactored to avoid this call path, let's instead fix this issue at the source in strset__add_str() and avoid similar scenarios. Let's check if set->strs_data was reallocated and whether 's' points to an internal string within the old strset buffer. In such case, 's' is reconstructed to point to the new buffer. While already here, also fix strset__find_str() which suffers from the same problem by factoring out the common operations into a new helper function strset_str_append(). Fixes: 90d76d3 ("libbpf: Extract internal set-of-strings datastructure APIs") Suggested-by: Andrii Nakryiko <[email protected]> Suggested-by: Mykyta Yatsenko <[email protected]> Signed-off-by: Carlos Llamas <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
6by9
pushed a commit
that referenced
this pull request
Aug 3, 2026
[ Upstream commit 0f8a5dc ] sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 but task is already holding lock: ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244 -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}: check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300 __sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640 sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408 __fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450 __fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535 __do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline] __se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline] __x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539 do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline] do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: e672077 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn") Acked-by: Dave Tian <[email protected]> Signed-off-by: Sungwoo Kim <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
6by9
pushed a commit
that referenced
this pull request
Sep 2, 2026
commit 9154286 upstream. In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that hold an ERR_PTR. rb_threads[] is static, so unassigned slots are NULL. But when kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free. That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall self-test. crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception Cc: [email protected] Fixes: 64ed3a0 ("ring-buffer: make use of the helper function kthread_run_on_cpu()") Link: https://patch.msgid.link/[email protected] Signed-off-by: Hui Su <[email protected]> Reviewed-by: Vincent Donnefort <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.