6.12.51-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 6.12.51-rc1 review
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 6.12.51-rc1
Srinivas Kandagatla <[email protected]>
ASoC: qcom: audioreach: fix potential null pointer dereference
Matvey Kovalev <[email protected]>
wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()
Charan Teja Kalla <[email protected]>
mm: swap: check for stable address space before operating on the VMA
Thadeu Lima de Souza Cascardo <[email protected]>
media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID
Larshin Sergey <[email protected]>
media: rc: fix races with imon_disconnect()
Duoming Zhou <[email protected]>
media: tuner: xc5000: Fix use-after-free in xc5000_release
Duoming Zhou <[email protected]>
media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove
Wang Haoran <[email protected]>
scsi: target: target_core_configfs: Add length check to avoid buffer overflow
Kees Cook <[email protected]>
gcc-plugins: Remove TODO_verify_il for GCC >= 16
Breno Leitao <[email protected]>
crypto: sha256 - fix crash at kexec
-------------
Diffstat:
Makefile | 4 +- drivers/media/pci/b2c2/flexcop-pci.c | 2 +- drivers/media/rc/imon.c | 27 +++++++++---- drivers/media/tuners/xc5000.c | 2 +- drivers/media/usb/uvc/uvc_driver.c | 73 ++++++++++++++++++++++------------- drivers/media/usb/uvc/uvcvideo.h | 2 + drivers/net/wireless/ath/ath11k/qmi.c | 2 +- drivers/target/target_core_configfs.c | 2 +- include/crypto/sha256_base.h | 2 +- mm/swapfile.c | 3 ++ scripts/gcc-plugins/gcc-common.h | 7 ++++ sound/soc/qcom/qdsp6/topology.c | 4 +- 12 files changed, 87 insertions(+), 43 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/10 crypto: sha256 - fix crash at kexec
6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
Loading a large (~2.1G) files with kexec crashes the host with when running:
# kexec --load kernel --initrd initrd_with_2G_or_more
UBSAN: signed-integer-overflow in ./include/crypto/sha256_base.h:64:19 34152083 * 64 cannot be represented in type 'int' ... BUG: unable to handle page fault for address: ff9fffff83b624c0 sha256_update (lib/crypto/sha256.c:137) crypto_sha256_update (crypto/sha256_generic.c:40) kexec_calculate_store_digests (kernel/kexec_file.c:769) __se_sys_kexec_file_load (kernel/kexec_file.c:397 kernel/kexec_file.c:332) ...
(Line numbers based on commit da274362a7bd9 ("Linux 6.12.49")
This started happening after commit f4da7afe07523f ("kexec_file: increase maximum file size to 4G") that landed in v6.0, which increased the file size for kexec.
This is not happening upstream (v6.16+), given that block type was upgraded from "int" to "size_t" in commit 74a43a2cf5e8 ("crypto:
lib/sha256 - Move partial block handling out")
Upgrade the block type similar to the commit above, avoiding hitting the overflow.
This patch is only suitable for the stable tree, and before 6.16, which got commit 74a43a2cf5e8 ("crypto: lib/sha256 - Move partial block handling out"). This is not required before f4da7afe07523f ("kexec_file:
increase maximum file size to 4G"). In other words, this fix is required between versions v6.0 and v6.16.
--- include/crypto/sha256_base.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/crypto/sha256_base.h +1 -1
@@ -44,7 +44,7 @@ static inline int lib_sha256_base_do_upd sctx->count += len;if (unlikely ((partial + len) >=SHA256_BLOCK_SIZE )) { -int blocks; +unsigned int blocks;if (partial) {int p =SHA256_BLOCK_SIZE - partial;
Greg Kroah-Hartman
maintainerPATCH 2/10 gcc-plugins: Remove TODO_verify_il for GCC >= 16
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit a40282dd3c484e6c882e93f4680e0a3ef3814453 upstream.
GCC now runs TODO_verify_il automatically[1], so it is no longer exposed to plugins. Only use the flag on GCC < 16.
--- scripts/gcc-plugins/gcc-common.h | 7 +++++++ 1 file changed, 7 insertions(+)
scripts/gcc-plugins/gcc-common.h +7 -0
@@ -191,10 +191,17 @@ inline bool is_a_helper<const gassign *> }#endif +#if BUILDING_GCC_VERSION <16000 #define TODO_verify_ssa TODO_verify_il#define TODO_verify_flow TODO_verify_il#define TODO_verify_stmts TODO_verify_il#define TODO_verify_rtl_sharing TODO_verify_il +#else +#define TODO_verify_ssa 0 +#define TODO_verify_flow 0 +#define TODO_verify_stmts 0 +#define TODO_verify_rtl_sharing 0 +#endif #define INSN_DELETED_P (insn) (insn)->deleted()
Greg Kroah-Hartman
maintainerPATCH 3/10 scsi: target: target_core_configfs: Add length check to avoid buffer overflow
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Haoran <[email protected]>
commit 27e06650a5eafe832a90fd2604f0c5e920857fae upstream.
A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes).
snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes.
Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error.
An additional check of the return value of snprintf() can avoid this buffer overflow.
--- drivers/target/target_core_configfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/target/target_core_configfs.c +1 -1
@@ -2776,7 +2776,7 @@ static ssize_t target_lu_gp_members_show config_item_name(&dev->dev_group.cg_item)); cur_len++;/* Extra byte for NULL terminator */ -if ((cur_len + len) >PAGE_SIZE ) { +if ((cur_len + len) >PAGE_SIZE || cur_len >LU_GROUP_NAME_BUF ) {pr_warn ("Ran out of lu_gp_show_attr" "_members buffer\n" );break ;
Greg Kroah-Hartman
maintainerPATCH 4/10 media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit 01e03fb7db419d39e18d6090d4873c1bff103914 upstream.
The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device.
A typical race condition is illustrated below:
CPU 0 (remove) | CPU 1 (delayed work callback)
flexcop_pci_remove() | flexcop_pci_irq_check_work()
cancel_delayed_work() |
flexcop_device_kfree(fc_pci->fc_dev) |
| fc = fc_pci->fc_dev; // UAFThis is confirmed by a KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ>
...
Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated.
This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.
--- drivers/media/pci/b2c2/flexcop-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/pci/b2c2/flexcop-pci.c +1 -1
@@ -411,7 +411,7 @@ static void flexcop_pci_remove(struct pcstruct flexcop_pci *fc_pci =pci_get_drvdata (pdev);if (irq_chk_intv >0 ) -cancel_delayed_work (&fc_pci->irq_check_work); +cancel_delayed_work_sync (&fc_pci->irq_check_work);flexcop_pci_dma_exit (fc_pci);flexcop_device_exit (fc_pci->fc_dev);
Greg Kroah-Hartman
maintainerPATCH 5/10 media: tuner: xc5000: Fix use-after-free in xc5000_release
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit 40b7a19f321e65789612ebaca966472055dab48c upstream.
The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback)
xc5000_release() | xc5000_do_timer_sleep()
cancel_delayed_work() |
hybrid_tuner_release_state(priv) |
kfree(priv) |
| priv = container_of() // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
--- drivers/media/tuners/xc5000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/tuners/xc5000.c +1 -1
@@ -1304,7 +1304,7 @@ static void xc5000_release(struct dvb_frmutex_lock (&xc5000_list_mutex);if (priv) { -cancel_delayed_work (&priv->timer_sleep); +cancel_delayed_work_sync (&priv->timer_sleep);hybrid_tuner_release_state (priv); }
Greg Kroah-Hartman
maintainerPATCH 6/10 media: rc: fix races with imon_disconnect()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larshin Sergey <[email protected]>
commit fa0f61cc1d828178aa921475a9b786e7fbb65ccb upstream.
Syzbot reports a KASAN issue as below:
BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465 CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.
Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.
As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.
Thread 1 vfd_write Thread 2 imon_disconnect
...
if
usb_put_dev(ictx->usbdev_intf0)
else
usb_put_dev(ictx->usbdev_intf1)
...
while
send_packet
if
pipe = usb_sndintpipe(
ictx->usbdev_intf0) UAF
else
pipe = usb_sndctrlpipe(
ictx->usbdev_intf0, 0) UAFGuard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.
Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.
Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
--- drivers/media/rc/imon.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-)
drivers/media/rc/imon.c +20 -7
@@ -536,7 +536,9 @@ static int display_open(struct inode *inmutex_lock (&ictx->lock); -if (!ictx->display_supported) { +if (ictx->disconnected) { + retval = -ENODEV ; + }else if (!ictx->display_supported) {pr_err ("display not supported by device\n" ); retval = -ENODEV ; }else if (ictx->display_isopen) {
@@ -598,6 +600,9 @@ static int send_packet(struct imon_conteint retval =0 ;struct usb_ctrlrequest *control_req =NULL ; +if (ictx->disconnected) +return -ENODEV ; +/* Check if we need to use control or interrupt urb */ if (!ictx->tx_control) { pipe = usb_sndintpipe(ictx->usbdev_intf0,
@@ -949,12 +954,14 @@ static ssize_t vfd_write(struct file *fistatic const unsigned char vfd_packet6[] = {0x01 ,0x00 ,0x00 ,0x00 ,0x00 ,0xFF ,0xFF }; -if (ictx->disconnected) -return -ENODEV ; -if (mutex_lock_interruptible (&ictx->lock))return -ERESTARTSYS ; +if (ictx->disconnected) { + retval = -ENODEV ; + goto exit; + } +if (!ictx->dev_present_intf0) {pr_err_ratelimited ("no iMON device present\n" ); retval = -ENODEV ;
@@ -1029,11 +1036,13 @@ static ssize_t lcd_write(struct file *fiint retval =0 ;struct imon_context *ictx = file->private_data; -if (ictx->disconnected) -return -ENODEV ; -mutex_lock (&ictx->lock); +if (ictx->disconnected) { + retval = -ENODEV ; + goto exit; + } +if (!ictx->display_supported) {pr_err_ratelimited ("no iMON display present\n" ); retval = -ENODEV ;
@@ -2499,7 +2508,11 @@ static void imon_disconnect(struct usb_iint ifnum; ictx =usb_get_intfdata (interface); + +mutex_lock (&ictx->lock); ictx->disconnected = true; +mutex_unlock (&ictx->lock); + dev = ictx->dev; ifnum = interface->cur_altsetting->desc.bInterfaceNumber;
Greg Kroah-Hartman
maintainerPATCH 7/10 media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thadeu Lima de Souza Cascardo <[email protected]>
commit 0e2ee70291e64a30fe36960c85294726d34a103e upstream.
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.
``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ```
If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID.
In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time.
This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.
In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.
Here is a sample stack trace for one of those cases.
[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dynamic_id+0x1b/0x70 [ 21.057811] ? find_held_lock+0x33/0xa0 [ 21.058047] ? usb_match_dynamic_id+0x55/0x70 [ 21.058330] ? lock_release+0x124/0x260 [ 21.058657] ? usb_match_one_id_intf+0xa2/0x100 [ 21.058997] usb_probe_interface+0x1ba/0x330 [ 21.059399] really_probe+0x1ba/0x4c0 [ 21.059662] __driver_probe_device+0xb2/0x180 [ 21.059944] driver_probe_device+0x5a/0x100 [ 21.060170] __device_attach_driver+0xe9/0x160 [ 21.060427] ? __pfx___device_attach_driver+0x10/0x10 [ 21.060872] bus_for_each_drv+0xa9/0x100 [ 21.061312] __device_attach+0xed/0x190 [ 21.061812] device_initial_probe+0xe/0x20 [ 21.062229] bus_probe_device+0x4d/0xd0 [ 21.062590] device_add+0x308/0x590 [ 21.062912] usb_set_configuration+0x7b6/0xaf0 [ 21.063403] usb_generic_driver_probe+0x36/0x80 [ 21.063714] usb_probe_device+0x7b/0x130 [ 21.063936] really_probe+0x1ba/0x4c0 [ 21.064111] __driver_probe_device+0xb2/0x180 [ 21.064577] driver_probe_device+0x5a/0x100 [ 21.065019] __device_attach_driver+0xe9/0x160 [ 21.065403] ? __pfx___device_attach_driver+0x10/0x10 [ 21.065820] bus_for_each_drv+0xa9/0x100 [ 21.066094] __device_attach+0xed/0x190 [ 21.066535] device_initial_probe+0xe/0x20 [ 21.066992] bus_probe_device+0x4d/0xd0 [ 21.067250] device_add+0x308/0x590 [ 21.067501] usb_new_device+0x347/0x610 [ 21.067817] hub_event+0x156b/0x1e30 [ 21.068060] ? process_scheduled_works+0x48b/0xaf0 [ 21.068337] process_scheduled_works+0x5a3/0xaf0 [ 21.068668] worker_thread+0x3cf/0x560 [ 21.068932] ? kthread+0x109/0x1b0 [ 21.069133] kthread+0x197/0x1b0 [ 21.069343] ? __pfx_worker_thread+0x10/0x10 [ 21.069598] ? __pfx_kthread+0x10/0x10 [ 21.069908] ret_from_fork+0x32/0x40 [ 21.070169] ? __pfx_kthread+0x10/0x10 [ 21.070424] ret_from_fork_asm+0x1a/0x30 [ 21.070737] </TASK>
--- drivers/media/usb/uvc/uvc_driver.c | 73 +++++++++++++++++++++++-------------- drivers/media/usb/uvc/uvcvideo.h | 2 + 2 files changed, 48 insertions(+), 27 deletions(-)
drivers/media/usb/uvc/uvc_driver.c +46 -27
@@ -135,6 +135,9 @@ struct uvc_entity *uvc_entity_by_id(stru {struct uvc_entity *entity; +if (id ==UVC_INVALID_ENTITY_ID ) +return NULL ; +list_for_each_entry (entity, &dev->entities, list) {if (entity->id == id)return entity;
@@ -778,14 +781,27 @@ static const u8 uvc_media_transport_inpuUVC_GUID_UVC_MEDIA_TRANSPORT_INPUT ;static const u8 uvc_processing_guid[16 ] =UVC_GUID_UVC_PROCESSING ; -static struct uvc_entity *uvc_alloc_entity (u16 type,u16 id, -unsigned int num_pads,unsigned int extra_size) +static struct uvc_entity *uvc_alloc_new_entity (struct uvc_device *dev,u16 type, +u16 id,unsigned int num_pads, +unsigned int extra_size) {struct uvc_entity *entity;unsigned int num_inputs;unsigned int size;unsigned int i; +/* Per UVC 1.1+ spec 3.7.2, the ID should be non-zero. */ +if (id ==0 ) { +dev_err (&dev->intf->dev,"Found Unit with invalid ID 0\n" ); + id =UVC_INVALID_ENTITY_ID ; + } + +/* Per UVC 1.1+ spec 3.7.2, the ID is unique. */ +if (uvc_entity_by_id (dev, id)) { +dev_err (&dev->intf->dev,"Found multiple Units with ID %u\n" , id); + id =UVC_INVALID_ENTITY_ID ; + } + extra_size =roundup (extra_size,sizeof (*entity->pads));if (num_pads) num_inputs = type &UVC_TERM_OUTPUT ? num_pads : num_pads -1 ;
@@ -795,7 +811,7 @@ static struct uvc_entity *uvc_alloc_enti + num_inputs; entity =kzalloc (size,GFP_KERNEL );if (entity ==NULL ) -return NULL ; +return ERR_PTR (-ENOMEM ); entity->id = id; entity->type = type;
@@ -907,10 +923,10 @@ static int uvc_parse_vendor_control(strubreak ; } - unit =uvc_alloc_entity (UVC_VC_EXTENSION_UNIT , buffer[3 ], - p +1 ,2 *n); -if (unit ==NULL ) -return -ENOMEM ; + unit =uvc_alloc_new_entity (dev,UVC_VC_EXTENSION_UNIT , + buffer[3 ], p +1 ,2 * n); +if (IS_ERR (unit)) +return PTR_ERR (unit);memcpy (unit->guid, &buffer[4 ],16 ); unit->extension.bNumControls = buffer[20 ];
@@ -1019,10 +1035,10 @@ static int uvc_parse_standard_control(streturn -EINVAL ; } - term =uvc_alloc_entity (type |UVC_TERM_INPUT , buffer[3 ], -1 , n + p); -if (term ==NULL ) -return -ENOMEM ; + term =uvc_alloc_new_entity (dev, type |UVC_TERM_INPUT , + buffer[3 ],1 , n + p); +if (IS_ERR (term)) +return PTR_ERR (term);if (UVC_ENTITY_TYPE (term) ==UVC_ITT_CAMERA ) { term->camera.bControlSize = n;
@@ -1078,10 +1094,10 @@ static int uvc_parse_standard_control(streturn 0 ; } - term =uvc_alloc_entity (type |UVC_TERM_OUTPUT , buffer[3 ], -1 ,0 ); -if (term ==NULL ) -return -ENOMEM ; + term =uvc_alloc_new_entity (dev, type |UVC_TERM_OUTPUT , + buffer[3 ],1 ,0 ); +if (IS_ERR (term)) +return PTR_ERR (term);memcpy (term->baSourceID, &buffer[7 ],1 );
@@ -1100,9 +1116,10 @@ static int uvc_parse_standard_control(streturn -EINVAL ; } - unit =uvc_alloc_entity (buffer[2 ], buffer[3 ], p +1 ,0 ); -if (unit ==NULL ) -return -ENOMEM ; + unit =uvc_alloc_new_entity (dev, buffer[2 ], buffer[3 ], + p +1 ,0 ); +if (IS_ERR (unit)) +return PTR_ERR (unit);memcpy (unit->baSourceID, &buffer[5 ], p);
@@ -1122,9 +1139,9 @@ static int uvc_parse_standard_control(streturn -EINVAL ; } - unit =uvc_alloc_entity (buffer[2 ], buffer[3 ],2 , n); -if (unit ==NULL ) -return -ENOMEM ; + unit =uvc_alloc_new_entity (dev, buffer[2 ], buffer[3 ],2 , n); +if (IS_ERR (unit)) +return PTR_ERR (unit);memcpy (unit->baSourceID, &buffer[4 ],1 ); unit->processing.wMaxMultiplier =
@@ -1151,9 +1168,10 @@ static int uvc_parse_standard_control(streturn -EINVAL ; } - unit =uvc_alloc_entity (buffer[2 ], buffer[3 ], p +1 , n); -if (unit ==NULL ) -return -ENOMEM ; + unit =uvc_alloc_new_entity (dev, buffer[2 ], buffer[3 ], + p +1 , n); +if (IS_ERR (unit)) +return PTR_ERR (unit);memcpy (unit->guid, &buffer[4 ],16 ); unit->extension.bNumControls = buffer[20 ];
@@ -1293,9 +1311,10 @@ static int uvc_gpio_parse(struct uvc_devreturn dev_err_probe (&dev->intf->dev, irq,"No IRQ for privacy GPIO\n" ); - unit =uvc_alloc_entity (UVC_EXT_GPIO_UNIT ,UVC_EXT_GPIO_UNIT_ID ,0 ,1 ); -if (!unit) -return -ENOMEM ; + unit =uvc_alloc_new_entity (dev,UVC_EXT_GPIO_UNIT , +UVC_EXT_GPIO_UNIT_ID ,0 ,1 ); +if (IS_ERR (unit)) +return PTR_ERR (unit); unit->gpio.gpio_privacy = gpio_privacy; unit->gpio.irq = irq;
drivers/media/usb/uvc/uvcvideo.h +2 -0
@@ -41,6 +41,8 @@#define UVC_EXT_GPIO_UNIT 0x7ffe#define UVC_EXT_GPIO_UNIT_ID 0x100 +#define UVC_INVALID_ENTITY_ID 0xffff +/* ------------------------------------------------------------------------ * Driver specific constants. */
Greg Kroah-Hartman
maintainerPATCH 8/10 mm: swap: check for stable address space before operating on the VMA
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charan Teja Kalla <[email protected]>
commit 1367da7eb875d01102d2ed18654b24d261ff5393 upstream.
It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address.
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
The issue is manifested from the below race between the fork() on a process and swapoff:
fork(dup_mmap()) swapoff(unuse_mm)
--------------- -----------------
1) Identical mtree is built using
__mt_dup().
2) copy_pte_range()-->
copy_nonpresent_pte():
The dst mm is added into the
mmlist to be visible to the
swapoff operation.
3) Fatal signal is sent to the parent
process(which is the current during the
fork) thus skip the duplication of the
vmas and mark the vma range withXA_ZERO_ENTRY as a marker for this process
that helps during exit_mmap().
4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2.
5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops.
The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap().
Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.
--- mm/swapfile.c | 3 +++ 1 file changed, 3 insertions(+)
mm/swapfile.c +3 -0
@@ -2337,6 +2337,8 @@ static int unuse_mm(struct mm_struct *mmVMA_ITERATOR (vmi, mm,0 );mmap_read_lock (mm); +if (check_stable_address_space (mm)) + goto unlock;for_each_vma (vmi, vma) {if (vma->anon_vma && !is_vm_hugetlb_page (vma)) { ret =unuse_vma (vma, type);
@@ -2346,6 +2348,7 @@ static int unuse_mm(struct mm_struct *mmcond_resched (); } +unlock:mmap_read_unlock (mm);return ret; }
Greg Kroah-Hartman
maintainerPATCH 9/10 wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matvey Kovalev <[email protected]>
commit 3fd2ef2ae2b5c955584a3bee8e83ae7d7a98f782 upstream.
If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function.
Replace fw->size by m3_len.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/net/wireless/ath/ath11k/qmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath11k/qmi.c +1 -1
@@ -2550,7 +2550,7 @@ static int ath11k_qmi_m3_load(struct ath GFP_KERNEL);if (!m3_mem->vaddr) {ath11k_err (ab,"failed to allocate memory for M3 with size %zu\n" , - fw->size); + m3_len); ret = -ENOMEM ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 10/10 ASoC: qcom: audioreach: fix potential null pointer dereference
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit 8318e04ab2526b155773313b66a1542476ce1106 upstream.
It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it.
--- sound/soc/qcom/qdsp6/topology.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/qcom/qdsp6/topology.c +2 -2
@@ -587,8 +587,8 @@ static int audioreach_widget_load_modulereturn PTR_ERR (cont); mod =audioreach_parse_common_tokens (apm, cont, &tplg_w->priv, w); -if (IS_ERR (mod)) -return PTR_ERR (mod); +if (IS_ERR_OR_NULL (mod)) +return mod ?PTR_ERR (mod) : -ENODEV ; dobj = &w->dobj; dobj->private = mod;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Builds successfully. Boots and works on qemu and Dell XPS 15 9520 w/ Intel Core i7-12600H
Thanks,
Brett
# Librecast Test Results
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.12.51-rc1-g791ab27b9c00 #100 SMP PREEMPT_DYNAMIC Sat Oct 4 11:29:24 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.12.51-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 791ab27b9c005e9996ed4ff5785a84890ea86f8b
* git describe: v6.12.50-11-g791ab27b9c00
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.50-11-g791ab27b9c00
## Test Regressions (compared to v6.12.49-90-g8e6ad214c7b3)
## Metric Regressions (compared to v6.12.49-90-g8e6ad214c7b3)
## Test Fixes (compared to v6.12.49-90-g8e6ad214c7b3)
## Metric Fixes (compared to v6.12.49-90-g8e6ad214c7b3)
## Test result summary
total: 156220, pass: 132956, fail: 4989, skip: 17711, xfail: 564
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 137 passed, 2 failed
* arm64: 57 total, 51 passed, 6 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 39 passed, 1 failed
* riscv: 25 total, 24 passed, 1 failed
* s390: 22 total, 21 passed, 1 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 46 passed, 3 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.12.51-rc1-g791ab27b9c00
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Am 03.10.2025 um 18:05 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 05 Oct 2025 16:02:25 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.51 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.12.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany