This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.13.1-rc1
Jack Greiner jack@emoss.org Input: xpad - add support for wooting two he (arm)
Matheos Mattsson matheos.mattsson@gmail.com Input: xpad - add support for Nacon Evol-X Xbox One Controller
Leonardo Brondani Schenkel leonardo@schenkel.net Input: xpad - improve name of 8BitDo controller 2dc8:3106
Pierre-Loup A. Griffais pgriffais@valvesoftware.com Input: xpad - add QH Electronics VID/PID
Nilton Perim Neto niltonperimneto@gmail.com Input: xpad - add unofficial Xbox 360 wireless receiver clone
Mark Pearson mpearson-lenovo@squebb.ca Input: atkbd - map F23 key to support default copilot shortcut
Nicolas Nobelis nicolas@nobelis.eu Input: xpad - add support for Nacon Pro Compact
Jann Horn jannh@google.com io_uring/rsrc: require cloned buffers to share accounting contexts
Jason Gerecke jason.gerecke@wacom.com HID: wacom: Initialize brightness of LED trigger
Hans de Goede hdegoede@redhat.com wifi: rtl8xxxu: add more missing rtl8192cu USB IDs
Lianqin Hu hulianqin@vivo.com ALSA: usb-audio: Add delay quirk for USB Audio Device
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null"
Qasim Ijaz qasdev00@gmail.com USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
Easwar Hariharan eahariha@linux.microsoft.com scsi: storvsc: Ratelimit warning logs to prevent VM denial of service
Alex Williamson alex.williamson@redhat.com vfio/platform: check the bounds of read/write syscalls
Linus Torvalds torvalds@linux-foundation.org cachestat: fix page cache statistics permission checking
Jiri Kosina jikos@kernel.org Revert "HID: multitouch: Add support for lenovo Y9000P Touchpad"
Jamal Hadi Salim jhs@mojatatu.com net: sched: fix ets qdisc OOB Indexing
Paulo Alcantara pc@manguebit.com smb: client: handle lack of EA support in smb2_query_path_info()
Chuck Lever chuck.lever@oracle.com libfs: Use d_children list to iterate simple_offset directories
Chuck Lever chuck.lever@oracle.com libfs: Replace simple_offset end-of-directory detection
Chuck Lever chuck.lever@oracle.com Revert "libfs: fix infinite directory reads for offset dir"
Chuck Lever chuck.lever@oracle.com Revert "libfs: Add simple_offset_empty()"
Chuck Lever chuck.lever@oracle.com libfs: Return ENOSPC when the directory offset range is exhausted
Andreas Gruenbacher agruenba@redhat.com gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
-------------
Diffstat:
Makefile | 4 +- drivers/hid/hid-ids.h | 1 - drivers/hid/hid-multitouch.c | 8 +- drivers/hid/wacom_sys.c | 24 ++-- drivers/input/joystick/xpad.c | 9 +- drivers/input/keyboard/atkbd.c | 2 +- drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 ++++ drivers/scsi/storvsc_drv.c | 8 +- drivers/usb/gadget/function/u_serial.c | 8 +- drivers/usb/serial/quatech2.c | 2 +- drivers/vfio/platform/vfio_platform_common.c | 10 ++ fs/gfs2/file.c | 1 + fs/libfs.c | 162 +++++++++++++-------------- fs/smb/client/smb2inode.c | 104 ++++++++++++----- include/linux/fs.h | 1 - io_uring/rsrc.c | 7 ++ mm/filemap.c | 17 +++ mm/shmem.c | 4 +- net/sched/sch_ets.c | 2 + sound/usb/quirks.c | 2 + 20 files changed, 251 insertions(+), 145 deletions(-)
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Gruenbacher agruenba@redhat.com
commit 7c9d9223802fbed4dee1ae301661bf346964c9d2 upstream.
Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag: depending on that flag, the pages in the address space will either use buffer heads or iomap_folio_state structs, and we cannot mix the two.
Reported-by: Kun Hu huk23@m.fudan.edu.cn, Jiaji Qin jjtan24@m.fudan.edu.cn Signed-off-by: Andreas Gruenbacher agruenba@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/gfs2/file.c | 1 + 1 file changed, 1 insertion(+)
--- a/fs/gfs2/file.c +++ b/fs/gfs2/file.c @@ -251,6 +251,7 @@ static int do_gfs2_set_flags(struct inod error = filemap_fdatawait(inode->i_mapping); if (error) goto out; + truncate_inode_pages(inode->i_mapping, 0); if (new_flags & GFS2_DIF_JDATA) gfs2_ordered_del_inode(ip); }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever chuck.lever@oracle.com
commit 903dc9c43a155e0893280c7472d4a9a3a83d75a6 upstream.
Testing shows that the EBUSY error return from mtree_alloc_cyclic() leaks into user space. The ERRORS section of "man creat(2)" says:
EBUSY O_EXCL was specified in flags and pathname refers to a block device that is in use by the system (e.g., it is mounted).
ENOSPC is closer to what applications expect in this situation.
Note that the normal range of simple directory offset values is 2..2^63, so hitting this error is going to be rare to impossible.
Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") Cc: stable@vger.kernel.org # v6.9+ Reviewed-by: Jeff Layton jlayton@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-2-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/libfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/libfs.c +++ b/fs/libfs.c @@ -292,8 +292,8 @@ int simple_offset_add(struct offset_ctx
ret = mtree_alloc_cyclic(&octx->mt, &offset, dentry, DIR_OFFSET_MIN, LONG_MAX, &octx->next_offset, GFP_KERNEL); - if (ret < 0) - return ret; + if (unlikely(ret < 0)) + return ret == -EBUSY ? -ENOSPC : ret;
offset_set(dentry, offset); return 0;
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever chuck.lever@oracle.com
commit d7bde4f27ceef3dc6d72010a20d4da23db835a32 upstream.
simple_empty() and simple_offset_empty() perform the same task. The latter's use as a canary to find bugs has not found any new issues. A subsequent patch will remove the use of the mtree for iterating directory contents, so revert back to using a similar mechanism for determining whether a directory is indeed empty.
Only one such mechanism is ever needed.
Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-3-cel@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/libfs.c | 32 -------------------------------- include/linux/fs.h | 1 - mm/shmem.c | 4 ++-- 3 files changed, 2 insertions(+), 35 deletions(-)
--- a/fs/libfs.c +++ b/fs/libfs.c @@ -330,38 +330,6 @@ void simple_offset_remove(struct offset_ }
/** - * simple_offset_empty - Check if a dentry can be unlinked - * @dentry: dentry to be tested - * - * Returns 0 if @dentry is a non-empty directory; otherwise returns 1. - */ -int simple_offset_empty(struct dentry *dentry) -{ - struct inode *inode = d_inode(dentry); - struct offset_ctx *octx; - struct dentry *child; - unsigned long index; - int ret = 1; - - if (!inode || !S_ISDIR(inode->i_mode)) - return ret; - - index = DIR_OFFSET_MIN; - octx = inode->i_op->get_offset_ctx(inode); - mt_for_each(&octx->mt, child, index, LONG_MAX) { - spin_lock(&child->d_lock); - if (simple_positive(child)) { - spin_unlock(&child->d_lock); - ret = 0; - break; - } - spin_unlock(&child->d_lock); - } - - return ret; -} - -/** * simple_offset_rename - handle directory offsets for rename * @old_dir: parent directory of source entry * @old_dentry: dentry of source entry --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3468,7 +3468,6 @@ struct offset_ctx { void simple_offset_init(struct offset_ctx *octx); int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry); void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry); -int simple_offset_empty(struct dentry *dentry); int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, struct inode *new_dir, struct dentry *new_dentry); int simple_offset_rename_exchange(struct inode *old_dir, --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3821,7 +3821,7 @@ static int shmem_unlink(struct inode *di
static int shmem_rmdir(struct inode *dir, struct dentry *dentry) { - if (!simple_offset_empty(dentry)) + if (!simple_empty(dentry)) return -ENOTEMPTY;
drop_nlink(d_inode(dentry)); @@ -3878,7 +3878,7 @@ static int shmem_rename2(struct mnt_idma return simple_offset_rename_exchange(old_dir, old_dentry, new_dir, new_dentry);
- if (!simple_offset_empty(new_dentry)) + if (!simple_empty(new_dentry)) return -ENOTEMPTY;
if (flags & RENAME_WHITEOUT) {
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever chuck.lever@oracle.com
commit b662d858131da9a8a14e68661656989b14dbf113 upstream.
The current directory offset allocator (based on mtree_alloc_cyclic) stores the next offset value to return in octx->next_offset. This mechanism typically returns values that increase monotonically over time. Eventually, though, the newly allocated offset value wraps back to a low number (say, 2) which is smaller than other already- allocated offset values.
Yu Kuai yukuai3@huawei.com reports that, after commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir"), if a directory's offset allocator wraps, existing entries are no longer visible via readdir/getdents because offset_readdir() stops listing entries once an entry's offset is larger than octx->next_offset. These entries vanish persistently -- they can be looked up, but will never again appear in readdir(3) output.
The reason for this is that the commit treats directory offsets as monotonically increasing integer values rather than opaque cookies, and introduces this comparison:
if (dentry2offset(dentry) >= last_index) {
On 64-bit platforms, the directory offset value upper bound is 2^63 - 1. Directory offsets will monotonically increase for millions of years without wrapping.
On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator can wrap after only a few weeks (at worst).
Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir") to prepare for a fix that can work properly on 32-bit systems and might apply to recent LTS kernels where shmem employs the simple_offset mechanism.
Reported-by: Yu Kuai yukuai3@huawei.com Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-4-cel@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/libfs.c | 35 +++++++++++------------------------ 1 file changed, 11 insertions(+), 24 deletions(-)
--- a/fs/libfs.c +++ b/fs/libfs.c @@ -422,14 +422,6 @@ void simple_offset_destroy(struct offset mtree_destroy(&octx->mt); }
-static int offset_dir_open(struct inode *inode, struct file *file) -{ - struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode); - - file->private_data = (void *)ctx->next_offset; - return 0; -} - /** * offset_dir_llseek - Advance the read position of a directory descriptor * @file: an open directory whose position is to be updated @@ -443,9 +435,6 @@ static int offset_dir_open(struct inode */ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) { - struct inode *inode = file->f_inode; - struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode); - switch (whence) { case SEEK_CUR: offset += file->f_pos; @@ -459,8 +448,7 @@ static loff_t offset_dir_llseek(struct f }
/* In this case, ->private_data is protected by f_pos_lock */ - if (!offset) - file->private_data = (void *)ctx->next_offset; + file->private_data = NULL; return vfs_setpos(file, offset, LONG_MAX); }
@@ -491,7 +479,7 @@ static bool offset_dir_emit(struct dir_c inode->i_ino, fs_umode_to_dtype(inode->i_mode)); }
-static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, long last_index) +static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) { struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *dentry; @@ -499,21 +487,17 @@ static void offset_iterate_dir(struct in while (true) { dentry = offset_find_next(octx, ctx->pos); if (!dentry) - return; - - if (dentry2offset(dentry) >= last_index) { - dput(dentry); - return; - } + return ERR_PTR(-ENOENT);
if (!offset_dir_emit(ctx, dentry)) { dput(dentry); - return; + break; }
ctx->pos = dentry2offset(dentry) + 1; dput(dentry); } + return NULL; }
/** @@ -540,19 +524,22 @@ static void offset_iterate_dir(struct in static int offset_readdir(struct file *file, struct dir_context *ctx) { struct dentry *dir = file->f_path.dentry; - long last_index = (long)file->private_data;
lockdep_assert_held(&d_inode(dir)->i_rwsem);
if (!dir_emit_dots(file, ctx)) return 0;
- offset_iterate_dir(d_inode(dir), ctx, last_index); + /* In this case, ->private_data is protected by f_pos_lock */ + if (ctx->pos == DIR_OFFSET_MIN) + file->private_data = NULL; + else if (file->private_data == ERR_PTR(-ENOENT)) + return 0; + file->private_data = offset_iterate_dir(d_inode(dir), ctx); return 0; }
const struct file_operations simple_offset_dir_operations = { - .open = offset_dir_open, .llseek = offset_dir_llseek, .iterate_shared = offset_readdir, .read = generic_read_dir,
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever chuck.lever@oracle.com
commit 68a3a65003145644efcbb651e91db249ccd96281 upstream.
According to getdents(3), the d_off field in each returned directory entry points to the next entry in the directory. The d_off field in the last returned entry in the readdir buffer must contain a valid offset value, but if it points to an actual directory entry, then readdir/getdents can loop.
This patch introduces a specific fixed offset value that is placed in the d_off field of the last entry in a directory. Some user space applications assume that the EOD offset value is larger than the offsets of real directory entries, so the largest valid offset value is reserved for this purpose. This new value is never allocated by simple_offset_add().
When ->iterate_dir() returns, getdents{64} inserts the ctx->pos value into the d_off field of the last valid entry in the readdir buffer. When it hits EOD, offset_readdir() sets ctx->pos to the EOD offset value so the last entry is updated to point to the EOD marker.
When trying to read the entry at the EOD offset, offset_readdir() terminates immediately.
It is worth noting that using a Maple tree for directory offset value allocation does not guarantee a 63-bit range of values -- on platforms where "long" is a 32-bit type, the directory offset value range is still 0..(2^31 - 1). For broad compatibility with 32-bit user space, the largest tmpfs directory cookie value is now S32_MAX.
Fixes: 796432efab1e ("libfs: getdents() should return 0 after reaching EOD") Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-5-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/libfs.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-)
--- a/fs/libfs.c +++ b/fs/libfs.c @@ -245,9 +245,15 @@ const struct inode_operations simple_dir }; EXPORT_SYMBOL(simple_dir_inode_operations);
-/* 0 is '.', 1 is '..', so always start with offset 2 or more */ +/* simple_offset_add() never assigns these to a dentry */ enum { - DIR_OFFSET_MIN = 2, + DIR_OFFSET_EOD = S32_MAX, +}; + +/* simple_offset_add() allocation range */ +enum { + DIR_OFFSET_MIN = 2, + DIR_OFFSET_MAX = DIR_OFFSET_EOD - 1, };
static void offset_set(struct dentry *dentry, long offset) @@ -291,7 +297,8 @@ int simple_offset_add(struct offset_ctx return -EBUSY;
ret = mtree_alloc_cyclic(&octx->mt, &offset, dentry, DIR_OFFSET_MIN, - LONG_MAX, &octx->next_offset, GFP_KERNEL); + DIR_OFFSET_MAX, &octx->next_offset, + GFP_KERNEL); if (unlikely(ret < 0)) return ret == -EBUSY ? -ENOSPC : ret;
@@ -447,8 +454,6 @@ static loff_t offset_dir_llseek(struct f return -EINVAL; }
- /* In this case, ->private_data is protected by f_pos_lock */ - file->private_data = NULL; return vfs_setpos(file, offset, LONG_MAX); }
@@ -458,7 +463,7 @@ static struct dentry *offset_find_next(s struct dentry *child, *found = NULL;
rcu_read_lock(); - child = mas_find(&mas, LONG_MAX); + child = mas_find(&mas, DIR_OFFSET_MAX); if (!child) goto out; spin_lock(&child->d_lock); @@ -479,7 +484,7 @@ static bool offset_dir_emit(struct dir_c inode->i_ino, fs_umode_to_dtype(inode->i_mode)); }
-static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) +static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) { struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *dentry; @@ -487,7 +492,7 @@ static void *offset_iterate_dir(struct i while (true) { dentry = offset_find_next(octx, ctx->pos); if (!dentry) - return ERR_PTR(-ENOENT); + goto out_eod;
if (!offset_dir_emit(ctx, dentry)) { dput(dentry); @@ -497,7 +502,10 @@ static void *offset_iterate_dir(struct i ctx->pos = dentry2offset(dentry) + 1; dput(dentry); } - return NULL; + return; + +out_eod: + ctx->pos = DIR_OFFSET_EOD; }
/** @@ -517,6 +525,8 @@ static void *offset_iterate_dir(struct i * * On return, @ctx->pos contains an offset that will read the next entry * in this directory when offset_readdir() is called again with @ctx. + * Caller places this value in the d_off field of the last entry in the + * user's buffer. * * Return values: * %0 - Complete @@ -529,13 +539,8 @@ static int offset_readdir(struct file *f
if (!dir_emit_dots(file, ctx)) return 0; - - /* In this case, ->private_data is protected by f_pos_lock */ - if (ctx->pos == DIR_OFFSET_MIN) - file->private_data = NULL; - else if (file->private_data == ERR_PTR(-ENOENT)) - return 0; - file->private_data = offset_iterate_dir(d_inode(dir), ctx); + if (ctx->pos != DIR_OFFSET_EOD) + offset_iterate_dir(d_inode(dir), ctx); return 0; }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever chuck.lever@oracle.com
commit b9b588f22a0c049a14885399e27625635ae6ef91 upstream.
The mtree mechanism has been effective at creating directory offsets that are stable over multiple opendir instances. However, it has not been able to handle the subtleties of renames that are concurrent with readdir.
Instead of using the mtree to emit entries in the order of their offset values, use it only to map incoming ctx->pos to a starting entry. Then use the directory's d_children list, which is already maintained properly by the dcache, to find the next child to emit.
One of the sneaky things about this is that when the mtree-allocated offset value wraps (which is very rare), looking up ctx->pos++ is not going to find the next entry; it will return NULL. Instead, by following the d_children list, the offset values can appear in any order but all of the entries in the directory will be visited eventually.
Note also that the readdir() is guaranteed to reach the tail of this list. Entries are added only at the head of d_children, and readdir walks from its current position in that list towards its tail.
Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/libfs.c | 84 ++++++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 58 insertions(+), 26 deletions(-)
--- a/fs/libfs.c +++ b/fs/libfs.c @@ -247,12 +247,13 @@ EXPORT_SYMBOL(simple_dir_inode_operation
/* simple_offset_add() never assigns these to a dentry */ enum { + DIR_OFFSET_FIRST = 2, /* Find first real entry */ DIR_OFFSET_EOD = S32_MAX, };
/* simple_offset_add() allocation range */ enum { - DIR_OFFSET_MIN = 2, + DIR_OFFSET_MIN = DIR_OFFSET_FIRST + 1, DIR_OFFSET_MAX = DIR_OFFSET_EOD - 1, };
@@ -457,51 +458,82 @@ static loff_t offset_dir_llseek(struct f return vfs_setpos(file, offset, LONG_MAX); }
-static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset) +static struct dentry *find_positive_dentry(struct dentry *parent, + struct dentry *dentry, + bool next) +{ + struct dentry *found = NULL; + + spin_lock(&parent->d_lock); + if (next) + dentry = d_next_sibling(dentry); + else if (!dentry) + dentry = d_first_child(parent); + hlist_for_each_entry_from(dentry, d_sib) { + if (!simple_positive(dentry)) + continue; + spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); + if (simple_positive(dentry)) + found = dget_dlock(dentry); + spin_unlock(&dentry->d_lock); + if (likely(found)) + break; + } + spin_unlock(&parent->d_lock); + return found; +} + +static noinline_for_stack struct dentry * +offset_dir_lookup(struct dentry *parent, loff_t offset) { - MA_STATE(mas, &octx->mt, offset, offset); + struct inode *inode = d_inode(parent); + struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *child, *found = NULL;
- rcu_read_lock(); - child = mas_find(&mas, DIR_OFFSET_MAX); - if (!child) - goto out; - spin_lock(&child->d_lock); - if (simple_positive(child)) - found = dget_dlock(child); - spin_unlock(&child->d_lock); -out: - rcu_read_unlock(); + MA_STATE(mas, &octx->mt, offset, offset); + + if (offset == DIR_OFFSET_FIRST) + found = find_positive_dentry(parent, NULL, false); + else { + rcu_read_lock(); + child = mas_find(&mas, DIR_OFFSET_MAX); + found = find_positive_dentry(parent, child, false); + rcu_read_unlock(); + } return found; }
static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) { struct inode *inode = d_inode(dentry); - long offset = dentry2offset(dentry);
- return ctx->actor(ctx, dentry->d_name.name, dentry->d_name.len, offset, - inode->i_ino, fs_umode_to_dtype(inode->i_mode)); + return dir_emit(ctx, dentry->d_name.name, dentry->d_name.len, + inode->i_ino, fs_umode_to_dtype(inode->i_mode)); }
-static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) +static void offset_iterate_dir(struct file *file, struct dir_context *ctx) { - struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); + struct dentry *dir = file->f_path.dentry; struct dentry *dentry;
+ dentry = offset_dir_lookup(dir, ctx->pos); + if (!dentry) + goto out_eod; while (true) { - dentry = offset_find_next(octx, ctx->pos); - if (!dentry) - goto out_eod; + struct dentry *next;
- if (!offset_dir_emit(ctx, dentry)) { - dput(dentry); + ctx->pos = dentry2offset(dentry); + if (!offset_dir_emit(ctx, dentry)) break; - }
- ctx->pos = dentry2offset(dentry) + 1; + next = find_positive_dentry(dir, dentry, true); dput(dentry); + + if (!next) + goto out_eod; + dentry = next; } + dput(dentry); return;
out_eod: @@ -540,7 +572,7 @@ static int offset_readdir(struct file *f if (!dir_emit_dots(file, ctx)) return 0; if (ctx->pos != DIR_OFFSET_EOD) - offset_iterate_dir(d_inode(dir), ctx); + offset_iterate_dir(file, ctx); return 0; }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Alcantara pc@manguebit.com
commit 3681c74d342db75b0d641ba60de27bf73e16e66b upstream.
If the server doesn't support both EAs and reparse point in a file, the SMB2_QUERY_INFO request will fail with either STATUS_NO_EAS_ON_FILE or STATUS_EAS_NOT_SUPPORT in the compound chain, so ignore it as long as reparse point isn't IO_REPARSE_TAG_LX_(CHR|BLK), which would require the EAs to know about major/minor numbers.
Reported-by: Pali Rohár pali@kernel.org Signed-off-by: Paulo Alcantara (Red Hat) pc@manguebit.com Signed-off-by: Steve French stfrench@microsoft.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/smb/client/smb2inode.c | 92 ++++++++++++++++++++++++++++++++++------------ 1 file changed, 69 insertions(+), 23 deletions(-)
--- a/fs/smb/client/smb2inode.c +++ b/fs/smb/client/smb2inode.c @@ -176,27 +176,27 @@ static int smb2_compound_op(const unsign struct kvec *out_iov, int *out_buftype, struct dentry *dentry) {
- struct reparse_data_buffer *rbuf; + struct smb2_query_info_rsp *qi_rsp = NULL; struct smb2_compound_vars *vars = NULL; - struct kvec *rsp_iov, *iov; - struct smb_rqst *rqst; - int rc; - __le16 *utf16_path = NULL; __u8 oplock = SMB2_OPLOCK_LEVEL_NONE; - struct cifs_fid fid; + struct cifs_open_info_data *idata; struct cifs_ses *ses = tcon->ses; + struct reparse_data_buffer *rbuf; struct TCP_Server_Info *server; - int num_rqst = 0, i; int resp_buftype[MAX_COMPOUND]; - struct smb2_query_info_rsp *qi_rsp = NULL; - struct cifs_open_info_data *idata; + int retries = 0, cur_sleep = 1; + __u8 delete_pending[8] = {1,}; + struct kvec *rsp_iov, *iov; struct inode *inode = NULL; - int flags = 0; - __u8 delete_pending[8] = {1, 0, 0, 0, 0, 0, 0, 0}; + __le16 *utf16_path = NULL; + struct smb_rqst *rqst; unsigned int size[2]; - void *data[2]; + struct cifs_fid fid; + int num_rqst = 0, i; unsigned int len; - int retries = 0, cur_sleep = 1; + int tmp_rc, rc; + int flags = 0; + void *data[2];
replay_again: /* reinitialize for possible replay */ @@ -637,7 +637,14 @@ finished: tcon->need_reconnect = true; }
+ tmp_rc = rc; for (i = 0; i < num_cmds; i++) { + char *buf = rsp_iov[i + i].iov_base; + + if (buf && resp_buftype[i + 1] != CIFS_NO_BUFFER) + rc = server->ops->map_error(buf, false); + else + rc = tmp_rc; switch (cmds[i]) { case SMB2_OP_QUERY_INFO: idata = in_iov[i].iov_base; @@ -803,6 +810,7 @@ finished: } } SMB2_close_free(&rqst[num_rqst]); + rc = tmp_rc;
num_cmds += 2; if (out_iov && out_buftype) { @@ -858,22 +866,52 @@ static int parse_create_response(struct return rc; }
+/* Check only if SMB2_OP_QUERY_WSL_EA command failed in the compound chain */ +static bool ea_unsupported(int *cmds, int num_cmds, + struct kvec *out_iov, int *out_buftype) +{ + int i; + + if (cmds[num_cmds - 1] != SMB2_OP_QUERY_WSL_EA) + return false; + + for (i = 1; i < num_cmds - 1; i++) { + struct smb2_hdr *hdr = out_iov[i].iov_base; + + if (out_buftype[i] == CIFS_NO_BUFFER || !hdr || + hdr->Status != STATUS_SUCCESS) + return false; + } + return true; +} + +static inline void free_rsp_iov(struct kvec *iovs, int *buftype, int count) +{ + int i; + + for (i = 0; i < count; i++) { + free_rsp_buf(buftype[i], iovs[i].iov_base); + memset(&iovs[i], 0, sizeof(*iovs)); + buftype[i] = CIFS_NO_BUFFER; + } +} + int smb2_query_path_info(const unsigned int xid, struct cifs_tcon *tcon, struct cifs_sb_info *cifs_sb, const char *full_path, struct cifs_open_info_data *data) { + struct kvec in_iov[3], out_iov[5] = {}; + struct cached_fid *cfid = NULL; struct cifs_open_parms oparms; - __u32 create_options = 0; struct cifsFileInfo *cfile; - struct cached_fid *cfid = NULL; + __u32 create_options = 0; + int out_buftype[5] = {}; struct smb2_hdr *hdr; - struct kvec in_iov[3], out_iov[3] = {}; - int out_buftype[3] = {}; + int num_cmds = 0; int cmds[3]; bool islink; - int i, num_cmds = 0; int rc, rc2;
data->adjust_tz = false; @@ -943,14 +981,14 @@ int smb2_query_path_info(const unsigned if (rc || !data->reparse_point) goto out;
- if (!tcon->posix_extensions) - cmds[num_cmds++] = SMB2_OP_QUERY_WSL_EA; /* * Skip SMB2_OP_GET_REPARSE if symlink already parsed in create * response. */ if (data->reparse.tag != IO_REPARSE_TAG_SYMLINK) cmds[num_cmds++] = SMB2_OP_GET_REPARSE; + if (!tcon->posix_extensions) + cmds[num_cmds++] = SMB2_OP_QUERY_WSL_EA;
oparms = CIFS_OPARMS(cifs_sb, tcon, full_path, FILE_READ_ATTRIBUTES | @@ -958,9 +996,18 @@ int smb2_query_path_info(const unsigned FILE_OPEN, create_options | OPEN_REPARSE_POINT, ACL_NO_MODE); cifs_get_readable_path(tcon, full_path, &cfile); + free_rsp_iov(out_iov, out_buftype, ARRAY_SIZE(out_iov)); rc = smb2_compound_op(xid, tcon, cifs_sb, full_path, &oparms, in_iov, cmds, num_cmds, - cfile, NULL, NULL, NULL); + cfile, out_iov, out_buftype, NULL); + if (rc && ea_unsupported(cmds, num_cmds, + out_iov, out_buftype)) { + if (data->reparse.tag != IO_REPARSE_TAG_LX_BLK && + data->reparse.tag != IO_REPARSE_TAG_LX_CHR) + rc = 0; + else + rc = -EOPNOTSUPP; + } break; case -EREMOTE: break; @@ -978,8 +1025,7 @@ int smb2_query_path_info(const unsigned }
out: - for (i = 0; i < ARRAY_SIZE(out_buftype); i++) - free_rsp_buf(out_buftype[i], out_iov[i].iov_base); + free_rsp_iov(out_iov, out_buftype, ARRAY_SIZE(out_iov)); return rc; }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jamal Hadi Salim jhs@mojatatu.com
commit d62b04fca4340a0d468d7853bd66e511935a18cb upstream.
Haowei Yan g1042620637@gmail.com found that ets_class_from_arg() can index an Out-Of-Bound class in ets_class_from_arg() when passed clid of 0. The overflow may cause local privilege escalation.
[ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dump_stack_lvl+0xc2/0xf0 [ 18.859607] dump_stack+0x10/0x20 [ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0 [ 18.864022] ets_class_change+0x3d6/0x3f0 [ 18.864322] tc_ctl_tclass+0x251/0x910 [ 18.864587] ? lock_acquire+0x5e/0x140 [ 18.865113] ? __mutex_lock+0x9c/0xe70 [ 18.866009] ? __mutex_lock+0xa34/0xe70 [ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0 [ 18.866806] ? __lock_acquire+0x578/0xc10 [ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 18.867503] netlink_rcv_skb+0x59/0x110 [ 18.867776] rtnetlink_rcv+0x15/0x30 [ 18.868159] netlink_unicast+0x1c3/0x2b0 [ 18.868440] netlink_sendmsg+0x239/0x4b0 [ 18.868721] ____sys_sendmsg+0x3e2/0x410 [ 18.869012] ___sys_sendmsg+0x88/0xe0 [ 18.869276] ? rseq_ip_fixup+0x198/0x260 [ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190 [ 18.869900] ? trace_hardirqs_off+0x5a/0xd0 [ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220 [ 18.870547] ? do_syscall_64+0x93/0x150 [ 18.870821] ? __memcg_slab_free_hook+0x69/0x290 [ 18.871157] __sys_sendmsg+0x69/0xd0 [ 18.871416] __x64_sys_sendmsg+0x1d/0x30 [ 18.871699] x64_sys_call+0x9e2/0x2670 [ 18.871979] do_syscall_64+0x87/0x150 [ 18.873280] ? do_syscall_64+0x93/0x150 [ 18.874742] ? lock_release+0x7b/0x160 [ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0 [ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210 [ 18.879608] ? irqentry_exit+0x77/0xb0 [ 18.879808] ? clear_bhb_loop+0x15/0x70 [ 18.880023] ? clear_bhb_loop+0x15/0x70 [ 18.880223] ? clear_bhb_loop+0x15/0x70 [ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]---
Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Reported-by: Haowei Yan g1042620637@gmail.com Suggested-by: Haowei Yan g1042620637@gmail.com Signed-off-by: Jamal Hadi Salim jhs@mojatatu.com Reviewed-by: Eric Dumazet edumazet@google.com Reviewed-by: Petr Machata petrm@nvidia.com Link: https://patch.msgid.link/20250111145740.74755-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/sched/sch_ets.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/net/sched/sch_ets.c +++ b/net/sched/sch_ets.c @@ -91,6 +91,8 @@ ets_class_from_arg(struct Qdisc *sch, un { struct ets_sched *q = qdisc_priv(sch);
+ if (arg == 0 || arg > q->nbands) + return NULL; return &q->classes[arg - 1]; }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina jkosina@suse.com
commit 3d88ba86ba6f35a0467f25a88c38aa5639190d04 upstream.
This reverts commit 251efae73bd46b097deec4f9986d926813aed744.
Quoting Wang Yuli:
"The 27C6:01E0 touchpad doesn't require the workaround and applying it would actually break functionality.
The initial report came from a BBS forum, but we suspect the information provided by the forum user may be incorrect which could happen sometimes. [1]
Further investigation showed that the Lenovo Y9000P 2024 doesn't even use a Goodix touchpad. [2]
For the broader issue of 27c6:01e0 being unusable on some devices, it just need to address it with a libinput quirk.
In conclusion, we should revert this commit, which is the best solution."
Reported-by: Ulrich Müller ulm@gentoo.org Reported-by: WangYuli wangyuli@uniontech.com Link: https://lore.kernel.org/all/uikt4wwpw@gentoo.org/ Signed-off-by: Jiri Kosina jkosina@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/hid/hid-ids.h | 1 - drivers/hid/hid-multitouch.c | 8 ++------ 2 files changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -506,7 +506,6 @@ #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
#define I2C_VENDOR_ID_GOODIX 0x27c6 -#define I2C_DEVICE_ID_GOODIX_01E0 0x01e0 #define I2C_DEVICE_ID_GOODIX_01E8 0x01e8 #define I2C_DEVICE_ID_GOODIX_01E9 0x01e9 #define I2C_DEVICE_ID_GOODIX_01F0 0x01f0 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -1460,8 +1460,7 @@ static const __u8 *mt_report_fixup(struc { if (hdev->vendor == I2C_VENDOR_ID_GOODIX && (hdev->product == I2C_DEVICE_ID_GOODIX_01E8 || - hdev->product == I2C_DEVICE_ID_GOODIX_01E9 || - hdev->product == I2C_DEVICE_ID_GOODIX_01E0)) { + hdev->product == I2C_DEVICE_ID_GOODIX_01E9)) { if (rdesc[607] == 0x15) { rdesc[607] = 0x25; dev_info( @@ -2085,10 +2084,7 @@ static const struct hid_device_id mt_dev I2C_DEVICE_ID_GOODIX_01E8) }, { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU, HID_DEVICE(BUS_I2C, HID_GROUP_ANY, I2C_VENDOR_ID_GOODIX, - I2C_DEVICE_ID_GOODIX_01E9) }, - { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU, - HID_DEVICE(BUS_I2C, HID_GROUP_ANY, I2C_VENDOR_ID_GOODIX, - I2C_DEVICE_ID_GOODIX_01E0) }, + I2C_DEVICE_ID_GOODIX_01E8) },
/* GoodTouch panels */ { .driver_data = MT_CLS_NSMU,
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds torvalds@linux-foundation.org
commit 5f537664e705b0bf8b7e329861f20128534f6a83 upstream.
When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.
But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").
This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).
Reported-by: Sudheendra Raghav Neela sneela@tugraz.at Fixes: cf264e1329fb ("cachestat: implement cachestat syscall") Tested-by: Johannes Weiner hannes@cmpxchg.org Acked-by: Johannes Weiner hannes@cmpxchg.org Acked-by: Nhat Pham nphamcs@gmail.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- mm/filemap.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
--- a/mm/filemap.c +++ b/mm/filemap.c @@ -4376,6 +4376,20 @@ resched: }
/* + * See mincore: reveal pagecache information only for files + * that the calling process has write access to, or could (if + * tried) open for writing. + */ +static inline bool can_do_cachestat(struct file *f) +{ + if (f->f_mode & FMODE_WRITE) + return true; + if (inode_owner_or_capable(file_mnt_idmap(f), file_inode(f))) + return true; + return file_permission(f, MAY_WRITE) == 0; +} + +/* * The cachestat(2) system call. * * cachestat() returns the page cache statistics of a file in the @@ -4430,6 +4444,9 @@ SYSCALL_DEFINE4(cachestat, unsigned int, if (is_file_hugepages(fd_file(f))) return -EOPNOTSUPP;
+ if (!can_do_cachestat(fd_file(f))) + return -EPERM; + if (flags != 0) return -EINVAL;
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson alex.williamson@redhat.com
commit ce9ff21ea89d191e477a02ad7eabf4f996b80a69 upstream.
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.
Fixes: 6e3f26456009 (“vfio/platform: read and write support for the device fd”) Cc: stable@vger.kernel.org Reported-by: Mostafa Saleh smostafa@google.com Reviewed-by: Eric Auger eric.auger@redhat.com Reviewed-by: Mostafa Saleh smostafa@google.com Tested-by: Mostafa Saleh smostafa@google.com Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/vfio/platform/vfio_platform_common.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
--- a/drivers/vfio/platform/vfio_platform_common.c +++ b/drivers/vfio/platform/vfio_platform_common.c @@ -388,6 +388,11 @@ static ssize_t vfio_platform_read_mmio(s { unsigned int done = 0;
+ if (off >= reg->size) + return -EINVAL; + + count = min_t(size_t, count, reg->size - off); + if (!reg->ioaddr) { reg->ioaddr = ioremap(reg->addr, reg->size); @@ -467,6 +472,11 @@ static ssize_t vfio_platform_write_mmio( { unsigned int done = 0;
+ if (off >= reg->size) + return -EINVAL; + + count = min_t(size_t, count, reg->size - off); + if (!reg->ioaddr) { reg->ioaddr = ioremap(reg->addr, reg->size);
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Easwar Hariharan eahariha@linux.microsoft.com
commit d2138eab8cde61e0e6f62d0713e45202e8457d6d upstream.
If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM.
Closes: https://github.com/microsoft/WSL/issues/9173 Signed-off-by: Easwar Hariharan eahariha@linux.microsoft.com Link: https://lore.kernel.org/r/20250107-eahariha-ratelimit-storvsc-v1-1-7fc193d1f... Reviewed-by: Michael Kelley mhklinux@outlook.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/scsi/storvsc_drv.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -171,6 +171,12 @@ do { \ dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \ } while (0)
+#define storvsc_log_ratelimited(dev, level, fmt, ...) \ +do { \ + if (do_logging(level)) \ + dev_warn_ratelimited(&(dev)->device, fmt, ##__VA_ARGS__); \ +} while (0) + struct vmscsi_request { u16 length; u8 srb_status; @@ -1177,7 +1183,7 @@ static void storvsc_on_io_completion(str int loglevel = (stor_pkt->vm_srb.cdb[0] == TEST_UNIT_READY) ? STORVSC_LOGGING_WARN : STORVSC_LOGGING_ERROR;
- storvsc_log(device, loglevel, + storvsc_log_ratelimited(device, loglevel, "tag#%d cmd 0x%x status: scsi 0x%x srb 0x%x hv 0x%x\n", scsi_cmd_to_rq(request->cmd)->tag, stor_pkt->vm_srb.cdb[0],
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz qasdev00@gmail.com
commit 575a5adf48b06a2980c9eeffedf699ed5534fade upstream.
This patch addresses a null-ptr-deref in qt2_process_read_urb() due to an incorrect bounds check in the following:
if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }
The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->num_ports - 1. When newport is equal to serial->num_ports, the assignment of "port" in the following code is out-of-bounds and NULL:
serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];
The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds.
Reported-by: syzbot syzbot+506479ebf12fe435d01a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=506479ebf12fe435d01a Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable@vger.kernel.org # 3.5 Signed-off-by: Qasim Ijaz qasdev00@gmail.com Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/serial/quatech2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/quatech2.c +++ b/drivers/usb/serial/quatech2.c @@ -503,7 +503,7 @@ static void qt2_process_read_urb(struct
newport = *(ch + 3);
- if (newport > serial->num_ports) { + if (newport >= serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport);
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman gregkh@linuxfoundation.org
commit 086fd062bc3883ae1ce4166cff5355db315ad879 upstream.
This reverts commit 13014969cbf07f18d62ceea40bd8ca8ec9d36cec.
It is reported to cause crashes on Tegra systems, so revert it for now.
Link: https://lore.kernel.org/r/1037c1ad-9230-4181-b9c3-167dbaa47644@nvidia.com Reported-by: Jon Hunter jonathanh@nvidia.com Cc: stable stable@kernel.org Cc: Lianqin Hu hulianqin@vivo.com Link: https://lore.kernel.org/r/2025011711-yippee-fever-a737@gregkh Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/gadget/function/u_serial.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/u_serial.c +++ b/drivers/usb/gadget/function/u_serial.c @@ -1420,10 +1420,6 @@ void gserial_disconnect(struct gserial * /* REVISIT as above: how best to track this? */ port->port_line_coding = gser->port_line_coding;
- /* disable endpoints, aborting down any active I/O */ - usb_ep_disable(gser->out); - usb_ep_disable(gser->in); - port->port_usb = NULL; gser->ioport = NULL; if (port->port.count > 0) { @@ -1435,6 +1431,10 @@ void gserial_disconnect(struct gserial * spin_unlock(&port->port_lock); spin_unlock_irqrestore(&serial_port_lock, flags);
+ /* disable endpoints, aborting down any active I/O */ + usb_ep_disable(gser->out); + usb_ep_disable(gser->in); + /* finally, free any unused/unusable I/O buffers */ spin_lock_irqsave(&port->port_lock, flags); if (port->port.count == 0)
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lianqin Hu hulianqin@vivo.com
commit ad5b205f9e022b407d91f952faddd05718be2866 upstream.
Audio control requests that sets sampling frequency sometimes fail on this card. Adding delay between control messages eliminates that problem.
usb 1-1: New USB device found, idVendor=0d8c, idProduct=0014 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: USB Audio Device usb 1-1: Manufacturer: C-Media Electronics Inc.
Signed-off-by: Lianqin Hu hulianqin@vivo.com Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de Link: https://patch.msgid.link/TYUPR06MB6217E94D922B9BF422A73F32D2192@TYUPR06MB621... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- sound/usb/quirks.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -2239,6 +2239,8 @@ static const struct usb_audio_quirk_flag QUIRK_FLAG_CTL_MSG_DELAY_1M), DEVICE_FLG(0x0c45, 0x6340, /* Sonix HD USB Camera */ QUIRK_FLAG_GET_SAMPLE_RATE), + DEVICE_FLG(0x0d8c, 0x0014, /* USB Audio Device */ + QUIRK_FLAG_CTL_MSG_DELAY_1M), DEVICE_FLG(0x0ecb, 0x205c, /* JBL Quantum610 Wireless */ QUIRK_FLAG_FIXED_RATE), DEVICE_FLG(0x0ecb, 0x2069, /* JBL Quantum810 Wireless */
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede hdegoede@redhat.com
commit 31be3175bd7be89e39c82b3973c9d4ff55a17583 upstream.
The rtl8xxxu has all the rtl8192cu USB IDs from rtlwifi/rtl8192cu/sw.c except for the following 10, add these to the untested section so they can be used with the rtl8xxxu as the rtl8192cu are well supported.
This fixes these wifi modules not working on distributions which have disabled CONFIG_RTL8192CU replacing it with CONFIG_RTL8XXXU_UNTESTED, like Fedora.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2321540 Cc: stable@vger.kernel.org Cc: Peter Robinson pbrobinson@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com Reviewed-by: Peter Robinson pbrobinson@gmail.com Signed-off-by: Ping-Ke Shih pkshih@realtek.com Link: https://patch.msgid.link/20241107140833.274986-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c @@ -8147,6 +8147,8 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x817e, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8186, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x818a, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x317f, 0xff, 0xff, 0xff), @@ -8157,12 +8159,18 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x050d, 0x1102, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x050d, 0x11f2, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x06f8, 0xe033, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x07b8, 0x8188, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x07b8, 0x8189, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9041, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9043, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0b05, 0x17ba, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x1e1e, 0xff, 0xff, 0xff), @@ -8179,6 +8187,10 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x13d3, 0x3357, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x13d3, 0x3358, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x13d3, 0x3359, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x330b, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x2019, 0x4902, 0xff, 0xff, 0xff), @@ -8193,6 +8205,8 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x4856, 0x0091, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x9846, 0x9041, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0xcdab, 0x8010, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x04f2, 0xaff7, 0xff, 0xff, 0xff), @@ -8218,6 +8232,8 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0586, 0x341f, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x06f8, 0xe033, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x06f8, 0xe035, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0b05, 0x17ab, 0xff, 0xff, 0xff), @@ -8226,6 +8242,8 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0df6, 0x0070, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x0df6, 0x0077, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x0789, 0x016d, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x07aa, 0x0056, 0xff, 0xff, 0xff), @@ -8248,6 +8266,8 @@ static const struct usb_device_id dev_ta .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x330a, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, +{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x330d, 0xff, 0xff, 0xff), + .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x2019, 0xab2b, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192cu_fops}, {USB_DEVICE_AND_INTERFACE_INFO(0x20f4, 0x624d, 0xff, 0xff, 0xff),
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gerecke jason.gerecke@wacom.com
commit 88006b8eca63467cf1b28fed839f4954c578eeff upstream.
If an LED has a default_trigger set prior to being registered with the subsystem, that trigger will be executed with a brightness value defined by `trigger->brightness`. Our driver was not setting this value, which was causing problems. It would cause the selected LED to be turned off, as well as corrupt the hlv/llv values assigned to other LEDs (since calling `wacom_led_brightness_set` will overite these values).
This patch sets the value of `trigger->brightness` to an appropriate value. We use `wacom_leds_brightness_get` to transform the llv/hlv values into a brightness that is understood by the rest of the LED subsystem.
Fixes: 822c91e72eac ("leds: trigger: Store brightness set by led_trigger_event()") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Jason Gerecke jason.gerecke@wacom.com Signed-off-by: Jiri Kosina jkosina@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/hid/wacom_sys.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -1370,17 +1370,6 @@ static int wacom_led_register_one(struct if (!name) return -ENOMEM;
- if (!read_only) { - led->trigger.name = name; - error = devm_led_trigger_register(dev, &led->trigger); - if (error) { - hid_err(wacom->hdev, - "failed to register LED trigger %s: %d\n", - led->cdev.name, error); - return error; - } - } - led->group = group; led->id = id; led->wacom = wacom; @@ -1397,6 +1386,19 @@ static int wacom_led_register_one(struct led->cdev.brightness_set = wacom_led_readonly_brightness_set; }
+ if (!read_only) { + led->trigger.name = name; + if (id == wacom->led.groups[group].select) + led->trigger.brightness = wacom_leds_brightness_get(led); + error = devm_led_trigger_register(dev, &led->trigger); + if (error) { + hid_err(wacom->hdev, + "failed to register LED trigger %s: %d\n", + led->cdev.name, error); + return error; + } + } + error = devm_led_classdev_register(dev, &led->cdev); if (error) { hid_err(wacom->hdev,
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn jannh@google.com
commit 19d340a2988d4f3e673cded9dde405d727d7e248 upstream.
When IORING_REGISTER_CLONE_BUFFERS is used to clone buffers from uring instance A to uring instance B, where A and B use different MMs for accounting, the accounting can go wrong: If uring instance A is closed before uring instance B, the pinned memory counters for uring instance B will be decremented, even though the pinned memory was originally accounted through uring instance A; so the MM of uring instance B can end up with negative locked memory.
Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/r/CAG48ez1zez4bdhmeGLEFxtbFADY4Czn3CV0u9d_TMcbvRA01b... Fixes: 7cc2a6eadcd7 ("io_uring: add IORING_REGISTER_COPY_BUFFERS method") Signed-off-by: Jann Horn jannh@google.com Link: https://lore.kernel.org/r/20250114-uring-check-accounting-v1-1-42e4145aa743@... Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- io_uring/rsrc.c | 7 +++++++ 1 file changed, 7 insertions(+)
--- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -931,6 +931,13 @@ static int io_clone_buffers(struct io_ri int i, ret, off, nr; unsigned int nbufs;
+ /* + * Accounting state is shared between the two rings; that only works if + * both rings are accounted towards the same counters. + */ + if (ctx->user != src_ctx->user || ctx->mm_account != src_ctx->mm_account) + return -EINVAL; + /* if offsets are given, must have nr specified too */ if (!arg->nr && (arg->dst_off || arg->src_off)) return -EINVAL;
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Nobelis nicolas@nobelis.eu
commit 1bba29603a2812e7b3dbb4ec1558ecb626ee933e upstream.
Add Nacon Pro Compact to the list of supported devices. These are the ids of the "Colorlight" variant. The buttons, sticks and vibrations work. The decorative LEDs on the other hand do not (they stay turned off).
Signed-off-by: Nicolas Nobelis nicolas@nobelis.eu Link: https://lore.kernel.org/r/20241116182419.33833-1-nicolas@nobelis.eu Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -383,6 +383,7 @@ static const struct xpad_device { { 0x31e3, 0x1300, "Wooting 60HE (AVR)", 0, XTYPE_XBOX360 }, { 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 }, { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 }, + { 0x3285, 0x0646, "Nacon Pro Compact", 0, XTYPE_XBOXONE }, { 0x3537, 0x1004, "GameSir T4 Kaleid", 0, XTYPE_XBOX360 }, { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX }, { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Pearson mpearson-lenovo@squebb.ca
commit 907bc9268a5a9f823ffa751957a5c1dd59f83f42 upstream.
Microsoft defined Meta+Shift+F23 as the Copilot shortcut instead of a dedicated keycode, and multiple vendors have their keyboards emit this sequence in response to users pressing a dedicated "Copilot" key. Unfortunately the default keymap table in atkbd does not map scancode 0x6e (F23) and so the key combination does not work even if userspace is ready to handle it.
Because this behavior is common between multiple vendors and the scancode is currently unused map 0x6e to keycode 193 (KEY_F23) so that key sequence is generated properly.
MS documentation for the scan code: https://learn.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-inpu... Confirmed on Lenovo, HP and Dell machines by Canonical. Tested on Lenovo T14s G6 AMD.
Signed-off-by: Mark Pearson mpearson-lenovo@squebb.ca Link: https://lore.kernel.org/r/20250107034554.25843-1-mpearson-lenovo@squebb.ca Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/keyboard/atkbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/keyboard/atkbd.c +++ b/drivers/input/keyboard/atkbd.c @@ -89,7 +89,7 @@ static const unsigned short atkbd_set2_k 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183, 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185, 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0, - 0, 89, 40, 0, 26, 13, 0, 0, 58, 54, 28, 27, 0, 43, 0, 85, + 0, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0, 85, 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0, 82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nilton Perim Neto niltonperimneto@gmail.com
commit e4940fe6322c851659c17852b671c6e7b1aa9f56 upstream.
Although it mimics the Microsoft's VendorID, it is in fact a clone. Taking into account that the original Microsoft Receiver is not being manufactured anymore, this drive can solve dpad issues encontered by those who still use the original 360 Wireless controller but are using a receiver clone.
Signed-off-by: Nilton Perim Neto niltonperimneto@gmail.com Signed-off-by: Pavel Rojtberg rojtberg@gmail.com Link: https://lore.kernel.org/r/20250107192830.414709-12-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -150,6 +150,7 @@ static const struct xpad_device { { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 }, { 0x045e, 0x028f, "Microsoft X-Box 360 pad v2", 0, XTYPE_XBOX360 }, { 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W }, + { 0x045e, 0x02a9, "Xbox 360 Wireless Receiver (Unofficial)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W }, { 0x045e, 0x02d1, "Microsoft X-Box One pad", 0, XTYPE_XBOXONE }, { 0x045e, 0x02dd, "Microsoft X-Box One pad (Firmware 2015)", 0, XTYPE_XBOXONE }, { 0x045e, 0x02e3, "Microsoft X-Box One Elite pad", MAP_PADDLES, XTYPE_XBOXONE },
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre-Loup A. Griffais pgriffais@valvesoftware.com
commit 92600f3295ff571890c981d886c6544030cc05f3 upstream.
Add support for QH Electronics Xbox 360-compatible controller
Signed-off-by: Pierre-Loup A. Griffais pgriffais@valvesoftware.com Signed-off-by: Vicki Pfau vi@endrift.com Link: https://lore.kernel.org/r/20250116012518.3476735-1-vi@endrift.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -306,6 +306,7 @@ static const struct xpad_device { { 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 }, { 0x17ef, 0x6182, "Lenovo Legion Controller for Windows", 0, XTYPE_XBOX360 }, { 0x1949, 0x041a, "Amazon Game Controller", 0, XTYPE_XBOX360 }, + { 0x1a86, 0xe310, "QH Electronics Controller", 0, XTYPE_XBOX360 }, { 0x1bad, 0x0002, "Harmonix Rock Band Guitar", 0, XTYPE_XBOX360 }, { 0x1bad, 0x0003, "Harmonix Rock Band Drumkit", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 }, { 0x1bad, 0x0130, "Ion Drum Rocker", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 }, @@ -516,6 +517,7 @@ static const struct usb_device_id xpad_t XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */ XPAD_XBOX360_VENDOR(0x17ef), /* Lenovo */ XPAD_XBOX360_VENDOR(0x1949), /* Amazon controllers */ + XPAD_XBOX360_VENDOR(0x1a86), /* QH Electronics */ XPAD_XBOX360_VENDOR(0x1bad), /* Harmonix Rock Band guitar and drums */ XPAD_XBOX360_VENDOR(0x20d6), /* PowerA controllers */ XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA controllers */
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leonardo Brondani Schenkel leonardo@schenkel.net
commit 66372fa9936088bf29c4f47907efeff03c51a2c8 upstream.
8BitDo Pro 2 Wired Controller shares the same USB identifier (2dc8:3106) as a different device, so amend name to reflect that and reduce confusion as the user might think the controller was misdetected.
Because Pro 2 Wired will not work in XTYPE_XBOXONE mode (button presses won't register), tagging it as XTYPE_XBOX360 remains appropriate.
Signed-off-by: Leonardo Brondani Schenkel leonardo@schenkel.net Signed-off-by: Pavel Rojtberg rojtberg@gmail.com Link: https://lore.kernel.org/r/20250107192830.414709-2-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -375,7 +375,7 @@ static const struct xpad_device { { 0x294b, 0x3303, "Snakebyte GAMEPAD BASE X", 0, XTYPE_XBOXONE }, { 0x294b, 0x3404, "Snakebyte GAMEPAD RGB X", 0, XTYPE_XBOXONE }, { 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE }, - { 0x2dc8, 0x3106, "8BitDo Pro 2 Wired Controller", 0, XTYPE_XBOX360 }, + { 0x2dc8, 0x3106, "8BitDo Ultimate Wireless / Pro 2 Wired Controller", 0, XTYPE_XBOX360 }, { 0x2dc8, 0x310a, "8BitDo Ultimate 2C Wireless Controller", 0, XTYPE_XBOX360 }, { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE }, { 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matheos Mattsson matheos.mattsson@gmail.com
commit 3a6e5ed2372bcb2a3c554fda32419efd91ff9b0c upstream.
Add Nacon Evol-X Xbox One to the list of supported devices.
Signed-off-by: Matheos Mattsson matheos.mattsson@gmail.com Signed-off-by: Pavel Rojtberg rojtberg@gmail.com Link: https://lore.kernel.org/r/20250107192830.414709-9-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -386,6 +386,7 @@ static const struct xpad_device { { 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 }, { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 }, { 0x3285, 0x0646, "Nacon Pro Compact", 0, XTYPE_XBOXONE }, + { 0x3285, 0x0663, "Nacon Evol-X", 0, XTYPE_XBOXONE }, { 0x3537, 0x1004, "GameSir T4 Kaleid", 0, XTYPE_XBOX360 }, { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX }, { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX }, @@ -534,6 +535,7 @@ static const struct usb_device_id xpad_t XPAD_XBOX360_VENDOR(0x2f24), /* GameSir controllers */ XPAD_XBOX360_VENDOR(0x31e3), /* Wooting Keyboards */ XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */ + XPAD_XBOXONE_VENDOR(0x3285), /* Nacon Evol-X */ XPAD_XBOX360_VENDOR(0x3537), /* GameSir Controllers */ XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */ { }
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jack Greiner jack@emoss.org
commit 222f3390c15c4452a9f7e26f5b7d9138e75d00d5 upstream.
Add Wooting Two HE (ARM) to the list of supported devices.
Signed-off-by: Jack Greiner jack@emoss.org Signed-off-by: Pavel Rojtberg rojtberg@gmail.com Link: https://lore.kernel.org/r/20250107192830.414709-3-rojtberg@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -382,6 +382,7 @@ static const struct xpad_device { { 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 }, { 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 }, { 0x31e3, 0x1220, "Wooting Two HE", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1230, "Wooting Two HE (ARM)", 0, XTYPE_XBOX360 }, { 0x31e3, 0x1300, "Wooting 60HE (AVR)", 0, XTYPE_XBOX360 }, { 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 }, { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 },
Tested-by: Luna Jernberg droidbittin@gmail.com
AMD Ryzen 5 5600 6-Core Processor: https://www.inet.se/produkt/5304697/amd-ryzen-5-5600-3-5-ghz-35mb on a https://www.gigabyte.com/Motherboard/B550-AORUS-ELITE-V2-rev-12 https://www.inet.se/produkt/1903406/gigabyte-b550-aorus-elite-v2 motherboard :)
running Arch Linux with the testing repos enabled: https://archlinux.org/ https://archboot.com/ https://wiki.archlinux.org/title/Arch_Testing_Team
Den tors 30 jan. 2025 kl 14:59 skrev Greg Kroah-Hartman gregkh@linuxfoundation.org:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.13.1-rc1
Jack Greiner jack@emoss.org Input: xpad - add support for wooting two he (arm)
Matheos Mattsson matheos.mattsson@gmail.com Input: xpad - add support for Nacon Evol-X Xbox One Controller
Leonardo Brondani Schenkel leonardo@schenkel.net Input: xpad - improve name of 8BitDo controller 2dc8:3106
Pierre-Loup A. Griffais pgriffais@valvesoftware.com Input: xpad - add QH Electronics VID/PID
Nilton Perim Neto niltonperimneto@gmail.com Input: xpad - add unofficial Xbox 360 wireless receiver clone
Mark Pearson mpearson-lenovo@squebb.ca Input: atkbd - map F23 key to support default copilot shortcut
Nicolas Nobelis nicolas@nobelis.eu Input: xpad - add support for Nacon Pro Compact
Jann Horn jannh@google.com io_uring/rsrc: require cloned buffers to share accounting contexts
Jason Gerecke jason.gerecke@wacom.com HID: wacom: Initialize brightness of LED trigger
Hans de Goede hdegoede@redhat.com wifi: rtl8xxxu: add more missing rtl8192cu USB IDs
Lianqin Hu hulianqin@vivo.com ALSA: usb-audio: Add delay quirk for USB Audio Device
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null"
Qasim Ijaz qasdev00@gmail.com USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()
Easwar Hariharan eahariha@linux.microsoft.com scsi: storvsc: Ratelimit warning logs to prevent VM denial of service
Alex Williamson alex.williamson@redhat.com vfio/platform: check the bounds of read/write syscalls
Linus Torvalds torvalds@linux-foundation.org cachestat: fix page cache statistics permission checking
Jiri Kosina jikos@kernel.org Revert "HID: multitouch: Add support for lenovo Y9000P Touchpad"
Jamal Hadi Salim jhs@mojatatu.com net: sched: fix ets qdisc OOB Indexing
Paulo Alcantara pc@manguebit.com smb: client: handle lack of EA support in smb2_query_path_info()
Chuck Lever chuck.lever@oracle.com libfs: Use d_children list to iterate simple_offset directories
Chuck Lever chuck.lever@oracle.com libfs: Replace simple_offset end-of-directory detection
Chuck Lever chuck.lever@oracle.com Revert "libfs: fix infinite directory reads for offset dir"
Chuck Lever chuck.lever@oracle.com Revert "libfs: Add simple_offset_empty()"
Chuck Lever chuck.lever@oracle.com libfs: Return ENOSPC when the directory offset range is exhausted
Andreas Gruenbacher agruenba@redhat.com gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
Diffstat:
Makefile | 4 +- drivers/hid/hid-ids.h | 1 - drivers/hid/hid-multitouch.c | 8 +- drivers/hid/wacom_sys.c | 24 ++-- drivers/input/joystick/xpad.c | 9 +- drivers/input/keyboard/atkbd.c | 2 +- drivers/net/wireless/realtek/rtl8xxxu/core.c | 20 ++++ drivers/scsi/storvsc_drv.c | 8 +- drivers/usb/gadget/function/u_serial.c | 8 +- drivers/usb/serial/quatech2.c | 2 +- drivers/vfio/platform/vfio_platform_common.c | 10 ++ fs/gfs2/file.c | 1 + fs/libfs.c | 162 +++++++++++++-------------- fs/smb/client/smb2inode.c | 104 ++++++++++++----- include/linux/fs.h | 1 - io_uring/rsrc.c | 7 ++ mm/filemap.c | 17 +++ mm/shmem.c | 4 +- net/sched/sch_ets.c | 2 + sound/usb/quirks.c | 2 + 20 files changed, 251 insertions(+), 145 deletions(-)
On 1/30/25 05:58, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
cpupower does not build on 6.13 because this fix made it too late:
3075476a7af666de3ec10b4f35d8e62db8fd5b6d ("pm: cpupower: Makefile: Fix cross compilation")
Do you mind picking it up so 6.13.1 builds without any special configuration required on my side?
Thanks!
On Thu, Jan 30, 2025 at 02:06:17PM -0800, Florian Fainelli wrote:
On 1/30/25 05:58, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
cpupower does not build on 6.13 because this fix made it too late:
3075476a7af666de3ec10b4f35d8e62db8fd5b6d ("pm: cpupower: Makefile: Fix cross compilation")
Do you mind picking it up so 6.13.1 builds without any special configuration required on my side?
Sure, now picked up, thanks.
greg k-h
On 1/30/25 05:58, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.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:
Tested-by: Florian Fainelli florian.fainelli@broadcom.com
On Thu, 30 Jan 2025 14:58:46 +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.13: 10 builds: 10 pass, 0 fail 26 boots: 26 pass, 0 fail 116 tests: 116 pass, 0 fail
Linux version: 6.13.1-rc1-g65a3016a79e2 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On 25/01/30 02:58PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +0000. Anything received after that time might be too late.
Tested-by: Christian Heusel christian@heusel.eu
Tested on a ThinkPad E14 Gen 3 with a AMD Ryzen 5 5500U CPU and on the Steam Deck (LCD variant)
On 1/30/25 05:58, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos re@w6rz.net
On Thu, Jan 30, 2025 at 02:58:46PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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.
Tested-by: Mark Brown broonie@kernel.org
On Thu, Jan 30, 2025 at 02:58:46PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Tested-by: Justin M. Forbes jforbes@fedoraproject.org
On Thu, 30 Jan 2025 at 19:29, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.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.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
## Build * kernel: 6.13.1-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git commit: 65a3016a79e2da6e613c74c51e580ff1b3ad1225 * git describe: v6.13-26-g65a3016a79e2 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.13.y/build/v6.13-...
## Test Regressions (compared to v6.13)
## Metric Regressions (compared to v6.13)
## Test Fixes (compared to v6.13)
## Metric Fixes (compared to v6.13)
## Test result summary total: 142397, pass: 92519, fail: 31182, skip: 18696, xfail: 0
## Build Summary * arc: 6 total, 5 passed, 1 failed * arm: 143 total, 132 passed, 11 failed * arm64: 58 total, 56 passed, 2 failed * i386: 22 total, 19 passed, 3 failed * mips: 38 total, 33 passed, 5 failed * parisc: 5 total, 3 passed, 2 failed * powerpc: 44 total, 41 passed, 3 failed * riscv: 27 total, 24 passed, 3 failed * s390: 26 total, 23 passed, 3 failed * sh: 6 total, 5 passed, 1 failed * sparc: 5 total, 3 passed, 2 failed * x86_64: 50 total, 49 passed, 1 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-mqueue * kselftest-net * kselftest-net-mptcp * kselftest-openat2 * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-rust * 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 * 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-filecaps * ltp-fs * ltp-fs_bind * ltp-fs_perms_simple * ltp-hugetlb * ltp-ipc * ltp-math * ltp-mm * ltp-np[ * ltp-nptl * ltp-pty * ltp-sched * ltp-smoke * ltp-syscalls * ltp-tracing * perf * rcutorture
-- Linaro LKFT https://lkft.linaro.org
On 1/30/25 6:58 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
OVERVIEW
Builds: 11 passed, 0 failed
Boot tests: 0 passed, 0 failed
CI systems: broonie
REVISION
Commit name: v6.13-26-g65a3016a79e2 hash: 65a3016a79e2da6e613c74c51e580ff1b3ad1225 Checked out from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
BUILDS
No build failures found
BOOT TESTS
No boot failures found
See complete and up-to-date report at:
https://kcidb.kernelci.org/d/revision/revision?orgId=1&var-git_commit_ha...
Tested-by: kernelci.org bot bot@kernelci.org
Thanks, KernelCI team
On 1/30/2025 9:58 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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 Sat, 01 Feb 2025 13:34:42 +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.13.1-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.13.y and the diffstat can be found below.
thanks,
greg k-h
Building passed on amd64, arm64, loongarch64, mips64el, ppc64el, and riscv64. Smoke testing passed on 3 amd64, 2 arm64, and 2 loongarch64 test systems.
Tested-by: Kexy Biscuit kexybiscuit@aosc.io
https://github.com/AOSC-Dev/aosc-os-abbs/pull/9522
Am 30.01.2025 um 14:58 schrieb Greg Kroah-Hartman:
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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.
Tested-by: Peter Schneider pschneider1968@googlemail.com
Beste Grüße, Peter Schneider
Hi!
This is the start of the stable review cycle for the 6.13.1 release. There are 25 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... https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
linux-stable-mirror@lists.linaro.org