5.10.248-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 124/451 NFS: Avoid changing nlink when file removes and attribute updates race
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit bd4928ec799b31c492eb63f9f4a0c1e0bb4bb3f7 ]
If a file removal races with another operation that updates its attributes, then skip the change to nlink, and just mark the attributes as being stale.
--- fs/nfs/dir.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-)
fs/nfs/dir.c +13 -6
@@ -1499,13 +1499,15 @@ static int nfs_dentry_delete(const struct dentry *dentry) }/* Ensure that we revalidate inode->i_nlink */ -static void nfs_drop_nlink (struct inode *inode) +static void nfs_drop_nlink (struct inode *inode,unsigned long gencount) { +struct nfs_inode *nfsi =NFS_I (inode); +spin_lock (&inode->i_lock);/* drop the inode if we're reasonably sure this is the last link */ -if (inode->i_nlink >0 ) +if (inode->i_nlink >0 && gencount == nfsi->attr_gencount)drop_nlink (inode); -NFS_I (inode)->attr_gencount =nfs_inc_attr_generation_counter (); + nfsi->attr_gencount =nfs_inc_attr_generation_counter ();nfs_set_cache_invalid ( inode,NFS_INO_INVALID_CHANGE |NFS_INO_INVALID_CTIME |NFS_INO_INVALID_OTHER |NFS_INO_REVAL_FORCED );
@@ -1523,8 +1525,9 @@ static void nfs_dentry_iput(struct dentry *dentry, struct inode *inode)nfs_set_cache_invalid (inode,NFS_INO_INVALID_DATA );if (dentry->d_flags &DCACHE_NFSFS_RENAMED ) { +unsigned long gencount =READ_ONCE (NFS_I (inode)->attr_gencount);nfs_complete_unlink (dentry, inode); -nfs_drop_nlink (inode); +nfs_drop_nlink (inode, gencount); }iput (inode); }
@@ -2064,9 +2067,11 @@ static int nfs_safe_remove(struct dentry *dentry)trace_nfs_remove_enter (dir, dentry);if (inode !=NULL ) { +unsigned long gencount =READ_ONCE (NFS_I (inode)->attr_gencount); + error =NFS_PROTO (dir)->remove (dir, dentry);if (error ==0 ) -nfs_drop_nlink (inode); +nfs_drop_nlink (inode, gencount); }else error =NFS_PROTO (dir)->remove (dir, dentry);if (error == -ENOENT )
@@ -2257,6 +2262,7 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry, {struct inode *old_inode =d_inode (old_dentry);struct inode *new_inode =d_inode (new_dentry); +unsigned long new_gencount =0 ;struct dentry *dentry =NULL ;struct rpc_task *task;bool must_unblock = false;
@@ -2314,6 +2320,7 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry, }else { new_dentry->d_fsdata =NFS_FSDATA_BLOCKED ; must_unblock = true; + new_gencount =NFS_I (new_inode)->attr_gencount;spin_unlock (&new_dentry->d_lock); }
@@ -2350,7 +2357,7 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry, new_dir, new_dentry, error);if (!error) {if (new_inode !=NULL ) -nfs_drop_nlink (new_inode); +nfs_drop_nlink (new_inode, new_gencount);/* * The d_move() should be here instead of in an async RPC completion * handler because we need the proper locks to move the dentry. If
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 125/451 fs/nls: Fix utf16 to utf8 conversion
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit 25524b6190295577e4918c689644451365e6466d ]
Currently the function responsible for converting between utf16 and utf8 strings will ignore any characters that cannot be converted. This however also includes multi-byte characters that do not fit into the provided string buffer.
This can cause problems if such a multi-byte character is followed by a single-byte character. In such a case the multi-byte character might be ignored when the provided string buffer is too small, but the single-byte character might fit and is thus still copied into the resulting string.
Fix this by stop filling the provided string buffer once a character does not fit. In order to be able to do this extend utf32_to_utf8() to return useful errno codes instead of -1.
--- fs/nls/nls_base.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
fs/nls/nls_base.c +12 -4
@@ -94,7 +94,7 @@ int utf32_to_utf8(unicode_t u, u8 *s, int maxout) l = u;if (l >UNICODE_MAX || (l &SURROGATE_MASK ) ==SURROGATE_PAIR ) -return -1 ; +return -EILSEQ ; nc =0 ;for (t = utf8_table; t->cmask && maxout; t++, maxout--) {
@@ -110,7 +110,7 @@ int utf32_to_utf8(unicode_t u, u8 *s, int maxout)return nc; } } -return -1 ; +return -EOVERFLOW ; }EXPORT_SYMBOL (utf32_to_utf8);
@@ -217,8 +217,16 @@ int utf16s_to_utf8s(const wchar_t *pwcs, int inlen, enum utf16_endian endian, inlen--; } size =utf32_to_utf8 (u, op, maxout); -if (size ==-1 ) { -/* Ignore character and move on */ +if (size <0 ) { +if (size == -EILSEQ ) { +/* Ignore character and move on */ +continue ; + } +/* +* Stop filling the buffer with data once a character +* does not fit anymore. +*/ +break ; }else { op += size; maxout -= size;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 126/451 NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Curley <[email protected]>
[ Upstream commit e0f8058f2cb56de0b7572f51cd563ca5debce746 ]
Fixes a crash when layout is null during this call stack:
write_inode
-> nfs4_write_inode
-> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.
--- fs/nfs/pnfs.c | 1 + 1 file changed, 1 insertion(+)
fs/nfs/pnfs.c +1 -0
@@ -465,6 +465,7 @@ pnfs_mark_layout_stateid_invalid(struct pnfs_layout_hdr *lo,struct pnfs_layout_segment *lseg, *next;set_bit (NFS_LAYOUT_INVALID_STID , &lo->plh_flags); +clear_bit (NFS_INO_LAYOUTCOMMIT , &NFS_I (lo->plh_inode)->flags);list_for_each_entry_safe (lseg, next, &lo->plh_segs, pls_list)pnfs_clear_lseg_state (lseg, lseg_list);pnfs_clear_layoutreturn_info (lo);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 127/451 Revert "nfs: ignore SB_RDONLY when remounting nfs"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit 400fa37afbb11a601c204b72af0f0e5bc2db695c ]
This reverts commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a.
Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions.
--- fs/nfs/super.c | 10 ---------- 1 file changed, 10 deletions(-)
fs/nfs/super.c +0 -10
@@ -1000,16 +1000,6 @@ int nfs_reconfigure(struct fs_context *fc)sync_filesystem (sb); -/* -* The SB_RDONLY flag has been removed from the superblock during -* mounts to prevent interference between different filesystems. -* Similarly, it is also necessary to ignore the SB_RDONLY flag -* during reconfiguration; otherwise, it may also result in the -* creation of redundant superblocks when mounting a directory with -* different rw and ro flags multiple times. -*/ - fc->sb_flags_mask &= ~SB_RDONLY ; -/* * Userspace mount programs that send binary options generally send * them populated with default values. We have no way to know which
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 128/451 Revert "nfs: clear SB_RDONLY before getting superblock"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit d216b698d44e33417ad4cc796cb04ccddbb8c0ee ]
This reverts commit 8cd9b785943c57a136536250da80ba1eb6f8eb18.
Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions.
--- fs/nfs/super.c | 9 --------- 1 file changed, 9 deletions(-)
fs/nfs/super.c +0 -9
@@ -1248,17 +1248,8 @@ int nfs_get_tree_common(struct fs_context *fc)if (IS_ERR (server))return PTR_ERR (server); -/* -* When NFS_MOUNT_UNSHARED is not set, NFS forces the sharing of a -* superblock among each filesystem that mounts sub-directories -* belonging to a single exported root path. -* To prevent interference between different filesystems, the -* SB_RDONLY flag should be removed from the superblock. -*/ if (server->flags &NFS_MOUNT_UNSHARED ) compare_super =NULL ; -else - fc->sb_flags &= ~SB_RDONLY ;/* -o noac implies -o sync */ if (server->flags &NFS_MOUNT_NOAC )
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 129/451 Revert "nfs: ignore SB_RDONLY when mounting nfs"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit d4a26d34f1946142f9d32e540490e4926ae9a46b ]
This reverts commit 52cb7f8f177878b4f22397b9c4d2c8f743766be3.
Silently ignoring the "ro" and "rw" mount options causes user confusion, and regressions.
--- fs/nfs/internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/internal.h +1 -1
@@ -11,7 +11,7 @@#include <linux/nfs_page.h> #include <linux/wait_bit.h> -#define NFS_SB_MASK (SB_NOSUID|SB_NODEV|SB_NOEXEC|SB_SYNCHRONOUS) +#define NFS_SB_MASK (SB_RDONLY|SB_NOSUID|SB_NODEV|SB_NOEXEC|SB_SYNCHRONOUS)extern const struct export_operations nfs_export_ops;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 130/451 fs_context: drop the unused lsm_flags member
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ondrej Mosnacek <[email protected]>
[ Upstream commit 4e04143c869c5b6d499fbd5083caa860d5c942c3 ]
This isn't ever used by VFS now, and it couldn't even work. Any FS that uses the SECURITY_LSM_NATIVE_LABELS flag needs to also process the value returned back from the LSM, so it needs to do its security_sb_set_mnt_opts() call on its own anyway.
Stable-dep-of: 8675c69816e4 ("NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags")
--- Documentation/filesystems/mount_api.rst | 1 - fs/nfs/super.c | 3 --- include/linux/fs_context.h | 1 - include/linux/security.h | 2 +- 4 files changed, 1 insertion(+), 6 deletions(-)
Documentation/filesystems/mount_api.rst +0 -1
@@ -79,7 +79,6 @@ context. This is represented by the fs_context structure:: unsigned int sb_flags; unsigned int sb_flags_mask; unsigned int s_iflags; - unsigned int lsm_flags; enum fs_context_purpose purpose:8; ... };
fs/nfs/super.c +0 -3
@@ -1259,9 +1259,6 @@ int nfs_get_tree_common(struct fs_context *fc)if (ctx->clone_data.sb->s_flags &SB_SYNCHRONOUS ) fc->sb_flags |=SB_SYNCHRONOUS ; -if (server->caps &NFS_CAP_SECURITY_LABEL ) - fc->lsm_flags |=SECURITY_LSM_NATIVE_LABELS ; -/* Get a superblock - note that we may end up sharing one that already exists */ fc->s_fs_info = server; s =sget_fc (fc, compare_super, nfs_set_super);
include/linux/fs_context.h +0 -1
@@ -104,7 +104,6 @@ struct fs_context {unsigned int sb_flags;/* Proposed superblock flags (SB_*) */ unsigned int sb_flags_mask;/* Superblock flags that were changed */ unsigned int s_iflags;/* OR'd with sb->s_iflags */ -unsigned int lsm_flags;/* Information flags from the fs to the LSM */ enum fs_context_purpose purpose:8; enum fs_context_phase phase:8; /* The phase the context is in */ bool need_free:1; /* Need to call ops->free() */
include/linux/security.h +1 -1
@@ -68,7 +68,7 @@ struct watch_notification;/* If capable is being called by a setid function */ #define CAP_OPT_INSETID BIT(2) -/* LSM Agnostic defines for fs_context::lsm_flags */ +/* LSM Agnostic defines for security_sb_set_mnt_opts() flags */ #define SECURITY_LSM_NATIVE_LABELS 1struct ctl_table ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 131/451 NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit 8675c69816e4276b979ff475ee5fac4688f80125 ]
When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.
--- fs/nfs/namespace.c | 6 ++++++ fs/nfs/super.c | 4 ---- 2 files changed, 6 insertions(+), 4 deletions(-)
fs/nfs/namespace.c +6 -0
@@ -149,6 +149,7 @@ struct vfsmount *nfs_d_automount(struct path *path)struct vfsmount *mnt =ERR_PTR (-ENOMEM );struct nfs_server *server =NFS_SB (path->dentry->d_sb);struct nfs_client *client = server->nfs_client; +unsigned long s_flags = path->dentry->d_sb->s_flags;int timeout =READ_ONCE (nfs_mountpoint_expiry_timeout);int ret;
@@ -174,6 +175,11 @@ struct vfsmount *nfs_d_automount(struct path *path) fc->net_ns =get_net (client->cl_net); } +/* Inherit the flags covered by NFS_SB_MASK */ + fc->sb_flags_mask |=NFS_SB_MASK ; + fc->sb_flags &= ~NFS_SB_MASK ; + fc->sb_flags |= s_flags &NFS_SB_MASK ; +/* for submounts we want the same server; referrals will reassign */ memcpy (&ctx->nfs_server.address, &client->cl_addr, client->cl_addrlen); ctx->nfs_server.addrlen = client->cl_addrlen;
fs/nfs/super.c +0 -4
@@ -1255,10 +1255,6 @@ int nfs_get_tree_common(struct fs_context *fc)if (server->flags &NFS_MOUNT_NOAC ) fc->sb_flags |=SB_SYNCHRONOUS ; -if (ctx->clone_data.sb) -if (ctx->clone_data.sb->s_flags &SB_SYNCHRONOUS ) - fc->sb_flags |=SB_SYNCHRONOUS ; -/* Get a superblock - note that we may end up sharing one that already exists */ fc->s_fs_info = server; s =sget_fc (fc, compare_super, nfs_set_super);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 132/451 fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit c36f9d7b2869a003a2f7d6ff2c6bac9e62fd7d68 ]
After commit 25524b619029 ("fs/nls: Fix utf16 to utf8 conversion"), the return values of utf8_to_utf32() and utf32_to_utf8() are inconsistent when encountering an error: utf8_to_utf32() returns -1, while utf32_to_utf8() returns errno codes. Fix this inconsistency by modifying utf8_to_utf32() to return errno codes as well.
--- fs/nls/nls_base.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
fs/nls/nls_base.c +7 -4
@@ -67,19 +67,22 @@ int utf8_to_utf32(const u8 *s, int inlen, unicode_t *pu) l &= t->lmask;if (l < t->lval || l >UNICODE_MAX || (l &SURROGATE_MASK ) ==SURROGATE_PAIR ) -return -1 ; +return -EILSEQ ; + *pu = (unicode_t ) l;return nc; }if (inlen <= nc) -return -1 ; +return -EOVERFLOW ; + s++; c = (*s ^0x80 ) &0xFF ;if (c &0xC0 ) -return -1 ; +return -EILSEQ ; + l = (l <<6 ) | c; } -return -1 ; +return -EILSEQ ; }EXPORT_SYMBOL (utf8_to_utf32);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 133/451 platform/x86: asus-wmi: use brightness_set_blocking() for kbd led
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Khirnov <[email protected]>
[ Upstream commit ccb61a328321ba3f8567e350664c9ca7a42b6c70 ]
kbd_led_set() can sleep, and so may not be used as the brightness_set() callback.
Otherwise using this led with a trigger leads to system hangs accompanied by:
BUG: scheduling while atomic: acpi_fakekeyd/2588/0x00000003 CPU: 4 UID: 0 PID: 2588 Comm: acpi_fakekeyd Not tainted 6.17.9+deb14-amd64 #1 PREEMPT(lazy) Debian 6.17.9-1 Hardware name: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B9403CVAR/B9403CVAR, BIOS B9403CVAR.311 12/24/2024 Call Trace: <TASK> [...] schedule_timeout+0xbd/0x100 __down_common+0x175/0x290 down_timeout+0x67/0x70 acpi_os_wait_semaphore+0x57/0x90 [...] asus_wmi_evaluate_method3+0x87/0x190 [asus_wmi] led_trigger_event+0x3f/0x60 [...]
--- drivers/platform/x86/asus-wmi.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/platform/x86/asus-wmi.c +4 -4
@@ -721,14 +721,14 @@ static void do_kbd_led_set(struct led_classdev *led_cdev, int value)kbd_led_update (asus); } -static void kbd_led_set (struct led_classdev *led_cdev, -enum led_brightness value) +static int kbd_led_set (struct led_classdev *led_cdev,enum led_brightness value) {/* Prevent disabling keyboard backlight on module unregister */ if (led_cdev->flags &LED_UNREGISTERING ) -return ; +return 0 ;do_kbd_led_set (led_cdev, value); +return 0 ; }static void kbd_led_set_by_kbd (struct asus_wmi *asus,enum led_brightness value)
@@ -865,7 +865,7 @@ static int asus_wmi_led_init(struct asus_wmi *asus) asus->kbd_led_wk = led_val; asus->kbd_led.name ="asus::kbd_backlight" ; asus->kbd_led.flags =LED_BRIGHT_HW_CHANGED ; - asus->kbd_led.brightness_set = kbd_led_set; + asus->kbd_led.brightness_set_blocking = kbd_led_set; asus->kbd_led.brightness_get = kbd_led_get; asus->kbd_led.max_brightness =3 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 134/451 ASoC: bcm: bcm63xx-pcm-whistler: Check return value of of_dma_configure()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
[ Upstream commit 0ebbd45c33d0049ebf5a22c1434567f0c420b333 ]
bcm63xx_soc_pcm_new() does not check the return value of of_dma_configure(), which may fail with -EPROBE_DEFER or other errors, allowing PCM setup to continue with incomplete DMA configuration.
Add error checking for of_dma_configure() and return on failure.
--- sound/soc/bcm/bcm63xx-pcm-whistler.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
sound/soc/bcm/bcm63xx-pcm-whistler.c +3 -1
@@ -390,7 +390,9 @@ static int bcm63xx_soc_pcm_new(struct snd_soc_component *component, i2s_priv =dev_get_drvdata (asoc_rtd_to_cpu (rtd,0 )->dev); -of_dma_configure (pcm->card->dev, pcm->card->dev->of_node,1 ); + ret =of_dma_configure (pcm->card->dev, pcm->card->dev->of_node,1 ); +if (ret) +return ret; ret =dma_coerce_mask_and_coherent (pcm->card->dev,DMA_BIT_MASK (32 ));if (ret)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 135/451 ASoC: ak4458: Disable regulator when error happens
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shengjiu Wang <[email protected]>
[ Upstream commit ae585fabb9713a43e358cf606451386757225c95 ]
Disable regulator in runtime resume when error happens to balance the reference count of regulator.
--- sound/soc/codecs/ak4458.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
sound/soc/codecs/ak4458.c +9 -1
@@ -683,7 +683,15 @@ static int __maybe_unused ak4458_runtime_resume(struct device *dev)regcache_cache_only (ak4458->regmap, false);regcache_mark_dirty (ak4458->regmap); - return regcache_sync(ak4458->regmap); + ret =regcache_sync (ak4458->regmap); +if (ret) + goto err; + +return 0 ; +err: +regcache_cache_only (ak4458->regmap, true); +regulator_bulk_disable (ARRAY_SIZE (ak4458->supplies), ak4458->supplies); + return ret; }#endif /* CONFIG_PM */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 136/451 ASoC: ak5558: Disable regulator when error happens
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shengjiu Wang <[email protected]>
[ Upstream commit 1f8f726a2a29c28f65b30880335a1610c5e63594 ]
Disable regulator in runtime resume when error happens to balance the reference count of regulator.
--- sound/soc/codecs/ak5558.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
sound/soc/codecs/ak5558.c +9 -1
@@ -330,7 +330,15 @@ static int __maybe_unused ak5558_runtime_resume(struct device *dev)regcache_cache_only (ak5558->regmap, false);regcache_mark_dirty (ak5558->regmap); -return regcache_sync (ak5558->regmap); + ret =regcache_sync (ak5558->regmap); +if (ret) + goto err; + +return 0 ; +err: +regcache_cache_only (ak5558->regmap, true); +regulator_bulk_disable (ARRAY_SIZE (ak5558->supplies), ak5558->supplies); +return ret; }static const struct dev_pm_ops ak5558_pm = {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 137/451 blk-mq: Abort suspend when wakeup events are pending
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Zhang <[email protected]>
[ Upstream commit c196bf43d706592d8801a7513603765080e495fb ]
During system suspend, wakeup capable IRQs for block device can be delayed, which can cause blk_mq_hctx_notify_offline() to hang indefinitely while waiting for pending request to complete. Skip the request waiting loop and abort suspend when wakeup events are pending to prevent the deadlock.
--- block/blk-mq.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
block/blk-mq.c +16 -2
@@ -23,6 +23,7 @@#include <linux/sched/sysctl.h> #include <linux/sched/topology.h> #include <linux/sched/signal.h> +#include <linux/suspend.h> #include <linux/delay.h> #include <linux/crash_dump.h> #include <linux/prefetch.h>
@@ -2548,6 +2549,7 @@ static int blk_mq_hctx_notify_offline(unsigned int cpu, struct hlist_node *node) {struct blk_mq_hw_ctx *hctx =hlist_entry_safe (node, struct blk_mq_hw_ctx, cpuhp_online); +int ret =0 ;if (!cpumask_test_cpu (cpu, hctx->cpumask) || !blk_mq_last_cpu_in_hctx (cpu, hctx))
@@ -2569,12 +2571,24 @@ static int blk_mq_hctx_notify_offline(unsigned int cpu, struct hlist_node *node)* frozen and there are no requests. */ if (percpu_ref_tryget (&hctx->queue->q_usage_counter)) { -while (blk_mq_hctx_has_requests (hctx)) +while (blk_mq_hctx_has_requests (hctx)) { +/* +* The wakeup capable IRQ handler of block device is +* not called during suspend. Skip the loop by checking +* pm_wakeup_pending to prevent the deadlock and improve +* suspend latency. +*/ +if (pm_wakeup_pending ()) { +clear_bit (BLK_MQ_S_INACTIVE , &hctx->state); + ret = -EBUSY ; +break ; + }msleep (5 ); + }percpu_ref_put (&hctx->queue->q_usage_counter); } -return 0 ; +return ret; }static int blk_mq_hctx_notify_online (unsigned int cpu,struct hlist_node *node)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 138/451 block: fix comment for op_is_zone_mgmt() to include RESET_ALL
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: shechenglong <[email protected]>
[ Upstream commit 8a32282175c964eb15638e8dfe199fc13c060f67 ]
REQ_OP_ZONE_RESET_ALL is a zone management request, and op_is_zone_mgmt() has returned true for it.
Update the comment to remove the misleading exception note so the documentation matches the implementation.
--- include/linux/blk_types.h | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
include/linux/blk_types.h +1 -4
@@ -487,10 +487,7 @@ static inline bool op_is_discard(unsigned int op) }/* -* Check if a bio or request operation is a zone management operation, with -* the exception of REQ_OP_ZONE_RESET_ALL which is treated as a special case -* due to its different handling in the block layer and device response in -* case of command failure. +* Check if a bio or request operation is a zone management operation. */ static inline bool op_is_zone_mgmt (enum req_opf op) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 139/451 dma/pool: eliminate alloc_pages warning in atomic_pool_expand
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Kleikamp <[email protected]>
[ Upstream commit 463d439becb81383f3a5a5d840800131f265a09c ]
atomic_pool_expand iteratively tries the allocation while decrementing the page order. There is no need to issue a warning if an attempted allocation fails.
--- kernel/dma/pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/dma/pool.c +1 -1
@@ -96,7 +96,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size, page =dma_alloc_from_contiguous (NULL ,1 << order, order, false);if (!page) - page =alloc_pages (gfp, order); + page =alloc_pages (gfp | __GFP_NOWARN, order); }while (!page && order-- >0 );if (!page) goto out;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 140/451 ALSA: uapi: Fix typo in asound.h comment
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andres J Rosa <[email protected]>
[ Upstream commit 9a97857db0c5655b8932f86b5d18bb959079b0ee ]
Fix 'level-shit' to 'level-shift' in struct snd_cea_861_aud_if comment.
--- include/uapi/sound/asound.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/uapi/sound/asound.h +1 -1
@@ -74,7 +74,7 @@ struct snd_cea_861_aud_if {unsigned char db2_sf_ss;/* sample frequency and size */ unsigned char db3;/* not used, all zeros */ unsigned char db4_ca;/* channel allocation code */ -unsigned char db5_dminh_lsv;/* downmix inhibit & level-shit values */ +unsigned char db5_dminh_lsv;/* downmix inhibit & level-shift values */ };/****************************************************************************
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 141/451 ARM: 9464/1: fix input-only operand modification in load_unaligned_zeropad()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liyuan Pang <[email protected]>
[ Upstream commit edb924a7211c9aa7a4a415e03caee4d875e46b8e ]
In the inline assembly inside load_unaligned_zeropad(), the "addr" is
constrained as input-only operand. The compiler assumes that on exit
from the asm statement these operands contain the same values as they
had before executing the statement, but when kernel page fault happened, the assembly fixup code "bic %2 %2, #0x3" modify the value of "addr", which may lead to an unexpected behavior.
Use a temporary variable "tmp" to handle it, instead of modifying the input-only operand, just like what arm64's load_unaligned_zeropad() does.
--- arch/arm/include/asm/word-at-a-time.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm/include/asm/word-at-a-time.h +5 -5
@@ -66,7 +66,7 @@ static inline unsigned long find_zero(unsigned long mask)*/ static inline unsigned long load_unaligned_zeropad (const void *addr) { -unsigned long ret, offset; +unsigned long ret, tmp;/* Load word from unaligned pointer addr */ asm(
@@ -74,9 +74,9 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)"2:\n" " .pushsection .text.fixup,\"ax\"\n" " .align 2\n" -"3: and %1, %2, #0x3\n" -" bic %2, %2, #0x3\n" -" ldr %0, [%2]\n" +"3: bic %1, %2, #0x3\n" +" ldr %0, [%1]\n" +" and %1, %2, #0x3\n" " lsl %1, %1, #0x3\n" #ifndef __ARMEB__" lsr %0, %0, %1\n"
@@ -89,7 +89,7 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)" .align 3\n" " .long 1b, 3b\n" " .popsection" - : "=&r" (ret), "=&r" (offset) + : "=&r" (ret), "=&r" (tmp) : "r" (addr), "Qo" (*(unsigned long *)addr)); return ret;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 142/451 dm-raid: fix possible NULL dereference with undefined raid type
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Simakov <[email protected]>
[ Upstream commit 2f6cfd6d7cb165a7af8877b838a9f6aab4159324 ]
rs->raid_type is assigned from get_raid_type_by_ll(), which may return NULL. This NULL value could be dereferenced later in the condition 'if (!(rs_is_raid10(rs) && rt_is_raid0(rs->raid_type)))'.
Add a fail-fast check to return early with an error if raid_type is NULL, similar to other uses of this function.
Found by Linux Verification Center (linuxtesting.org) with Svace.
--- drivers/md/dm-raid.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/md/dm-raid.c +2 -0
@@ -2259,6 +2259,8 @@ static int super_init_validation(struct raid_set *rs, struct md_rdev *rdev) mddev->reshape_position =le64_to_cpu (sb->reshape_position); rs->raid_type =get_raid_type_by_ll (mddev->level, mddev->layout); +if (!rs->raid_type) +return -EINVAL ; } }else {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 143/451 dm log-writes: Add missing set_freezable() for freezable kthread
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
[ Upstream commit ab08f9c8b363297cafaf45475b08f78bf19b88ef ]
The log_writes_kthread() calls try_to_freeze() but lacks set_freezable(), rendering the freeze attempt ineffective since kernel threads are non-freezable by default. This prevents proper thread suspension during system suspend/hibernate.
Add set_freezable() to explicitly mark the thread as freezable.
--- drivers/md/dm-log-writes.c | 1 + 1 file changed, 1 insertion(+)
drivers/md/dm-log-writes.c +1 -0
@@ -454,6 +454,7 @@ static int log_writes_kthread(void *arg)struct log_writes_c *lc = (struct log_writes_c *)arg;sector_t sector =0 ; +set_freezable ();while (!kthread_should_stop ()) {bool super = false;bool logging_enabled;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 144/451 efi/cper: Add a new helper function to print bitmasks
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit a976d790f49499ccaa0f991788ad8ebf92e7fd5c ]
Add a helper function to print a string with names associated to each bit field.
A typical example is:
const char * const bits[] = {
"bit 3 name",
"bit 4 name",
"bit 5 name",
};
char str[120];
unsigned int bitmask = BIT(3) | BIT(5);
#define MASK GENMASK(5,3)
cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask),
bits, ARRAY_SIZE(bits));The above code fills string "str" with "bit 3 name|bit 5 name".
--- drivers/firmware/efi/cper.c | 60 +++++++++++++++++++++++++++++++++++++ include/linux/cper.h | 2 ++ 2 files changed, 62 insertions(+)
drivers/firmware/efi/cper.c +60 -0
@@ -12,6 +12,7 @@* Specification version 2.4. */ +#include <linux/bitmap.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/time.h>
@@ -105,6 +106,65 @@ void cper_print_bits(const char *pfx, unsigned int bits,printk ("%s\n" , buf); } +/** +* cper_bits_to_str - return a string for set bits +* @buf: buffer to store the output string +* @buf_size: size of the output string buffer +* @bits: bit mask +* @strs: string array, indexed by bit position +* @strs_size: size of the string array: @strs +* +* Add to @buf the bitmask in hexadecimal. Then, for each set bit in @bits, +* add the corresponding string describing the bit in @strs to @buf. +* +* A typical example is:: +* +* const char * const bits[] = { +* "bit 3 name", +* "bit 4 name", +* "bit 5 name", +* }; +* char str[120]; +* unsigned int bitmask = BIT(3) | BIT(5); +* #define MASK GENMASK(5,3) +* +* cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask), +* bits, ARRAY_SIZE(bits)); +* +* The above code fills the string ``str`` with ``bit 3 name|bit 5 name``. +* +* Return: number of bytes stored or an error code if lower than zero. +*/ +int cper_bits_to_str (char *buf,int buf_size,unsigned long bits, +const char *const strs[],unsigned int strs_size) +{ +int len = buf_size; +char *str = buf; +int i, size; + + *buf ='\0' ; + +for_each_set_bit (i, &bits, strs_size) { +if (!(bits &BIT_ULL (i))) +continue ; + +if (*buf && len >0 ) { + *str ='|' ; + len--; + str++; + } + + size =strscpy (str, strs[i], len); +if (size <0 ) +return size; + + len -= size; + str += size; + } +return len - buf_size; +} +EXPORT_SYMBOL_GPL (cper_bits_to_str); +static const char *const proc_type_strs[] = {"IA32/X64" ,"IA64" ,
include/linux/cper.h +2 -0
@@ -560,6 +560,8 @@ const char *cper_severity_str(unsigned int);const char *cper_mem_err_type_str (unsigned int );void cper_print_bits (const char *prefix,unsigned int bits,const char *const strs[],unsigned int strs_size); +int cper_bits_to_str (char *buf,int buf_size,unsigned long bits, +const char *const strs[],unsigned int strs_size);void cper_mem_err_pack (const struct cper_sec_mem_err *,struct cper_mem_err_compact *); const char *cper_mem_err_unpack(struct trace_seq *,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 145/451 efi/cper: Adjust infopfx size to accept an extra space
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit 8ad2c72e21efb3dc76c5b14089fa7984cdd87898 ]
Compiling with W=1 with werror enabled produces an error:
drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’:drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
| ^drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64
298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning.
--- drivers/firmware/efi/cper-arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/cper-arm.c +1 -1
@@ -241,7 +241,7 @@ void cper_print_proc_arm(const char *pfx,int i, len, max_ctx_type;struct cper_arm_err_info *err_info;struct cper_arm_ctx_info *ctx_info; -char newpfx[64 ], infopfx[64 ]; +char newpfx[64 ], infopfx[ARRAY_SIZE (newpfx) +1 ];printk ("%sMIDR: 0x%016llx\n" , pfx, proc->midr);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 146/451 efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit 96b010536ee020e716d28d9b359a4bcd18800aeb ]
Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as:
Type at byte offset 4:
- Cache error
- TLB Error
- Bus Error
- Micro-architectural Error
All other values are reserved
Yet, there was no information about how this would be encoded.
Spec 2.9A errata corrected it by defining:
- Bit 1 - Cache Error
- Bit 2 - TLB Error
- Bit 3 - Bus Error
- Bit 4 - Micro-architectural Error
All other values are reserved
That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section.
Spec 2.10 also preserve the same encoding as 2.9A.
Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding.
--- drivers/acpi/apei/ghes.c | 16 +++++++---- drivers/firmware/efi/cper-arm.c | 50 ++++++++++++++++----------------- include/linux/cper.h | 10 +++---- 3 files changed, 39 insertions(+), 37 deletions(-)
drivers/acpi/apei/ghes.c +10 -6
@@ -22,6 +22,7 @@#include <linux/moduleparam.h> #include <linux/init.h> #include <linux/acpi.h> +#include <linux/bitfield.h> #include <linux/io.h> #include <linux/interrupt.h> #include <linux/timer.h>
@@ -500,6 +501,7 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, {struct cper_sec_proc_arm *err =acpi_hest_get_payload (gdata);int flags = sync ?MF_ACTION_REQUIRED :0 ; +char error_type[120 ];bool queued = false;int sec_sev, i;char *p;
@@ -513,9 +515,8 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, p = (char *)(err +1 );for (i =0 ; i < err->err_info_num; i++) {struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; -bool is_cache = (err_info->type ==CPER_ARM_CACHE_ERROR ); +bool is_cache = err_info->type &CPER_ARM_CACHE_ERROR ;bool has_pa = (err_info->validation_bits &CPER_ARM_INFO_VALID_PHYSICAL_ADDR ); -const char *error_type ="unknown error" ;/* * The field (err_info->error_info & BIT(26)) is fixed to set to
@@ -529,12 +530,15 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,continue ; } -if (err_info->type <ARRAY_SIZE (cper_proc_error_type_strs)) - error_type = cper_proc_error_type_strs[err_info->type]; +cper_bits_to_str (error_type,sizeof (error_type), +FIELD_GET (CPER_ARM_ERR_TYPE_MASK , err_info->type), + cper_proc_error_type_strs, +ARRAY_SIZE (cper_proc_error_type_strs)); pr_warn_ratelimited(FW_WARN GHES_PFX -"Unhandled processor error type: %s\n" , - error_type); +"Unhandled processor error type 0x%02x: %s%s\n" , + err_info->type, error_type, + (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : ""); p += err_info->length; }
drivers/firmware/efi/cper-arm.c +24 -26
97 lines not on this page · raw message
include/linux/cper.h +5 -5
@@ -270,11 +270,11 @@ enum {#define CPER_ARM_INFO_FLAGS_PROPAGATED BIT(2)#define CPER_ARM_INFO_FLAGS_OVERFLOW BIT(3) -#define CPER_ARM_CACHE_ERROR 0 -#define CPER_ARM_TLB_ERROR 1 -#define CPER_ARM_BUS_ERROR 2 -#define CPER_ARM_VENDOR_ERROR 3 -#define CPER_ARM_MAX_TYPE CPER_ARM_VENDOR_ERROR +#define CPER_ARM_ERR_TYPE_MASK GENMASK(4,1) +#define CPER_ARM_CACHE_ERROR BIT(1) +#define CPER_ARM_TLB_ERROR BIT(2) +#define CPER_ARM_BUS_ERROR BIT(3) +#define CPER_ARM_VENDOR_ERROR BIT(4)#define CPER_ARM_ERR_VALID_TRANSACTION_TYPE BIT(0)#define CPER_ARM_ERR_VALID_OPERATION_TYPE BIT(1)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 147/451 ocfs2: fix memory leak in ocfs2_merge_rec_left()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Antipov <[email protected]>
[ Upstream commit 2214ec4bf89d0fd27717322d3983a2f3b469c7f3 ]
In 'ocfs2_merge_rec_left()', do not reset 'left_path' to NULL after move, thus allowing 'ocfs2_free_path()' to free it before return.
--- fs/ocfs2/alloc.c | 1 - 1 file changed, 1 deletion(-)
fs/ocfs2/alloc.c +0 -1
@@ -3649,7 +3649,6 @@ static int ocfs2_merge_rec_left(struct ocfs2_path *right_path,* So we use the new rightmost path. */ ocfs2_mv_path (right_path, left_path); - left_path =NULL ; }else ocfs2_complete_edge_insert (handle, left_path, right_path, subtree_index);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 148/451 usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotien Hsu <[email protected]>
commit 2585973c7f9ee31d21e5848c996fab2521fd383d upstream.
The driver previously skipped handling ClearFeature(ENDPOINT_HALT) when the endpoint was already not halted. This prevented the controller from resetting the data sequence number and reinitializing the endpoint state.
According to USB 3.2 specification Rev. 1.1, section 9.4.5, ClearFeature(ENDPOINT_HALT) must always reset the data sequence and set the stream state machine to Disabled, regardless of whether the endpoint was halted.
Remove the early return so that ClearFeature(ENDPOINT_HALT) always resets the endpoint sequence state as required by the specification.
--- drivers/usb/gadget/udc/tegra-xudc.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/usb/gadget/udc/tegra-xudc.c +0 -6
@@ -1542,12 +1542,6 @@ static int __tegra_xudc_ep_set_halt(strureturn -ENOTSUPP ; } -if (!!(xudc_readl (xudc,EP_HALT ) &BIT (ep->index)) == halt) { -dev_dbg (xudc->dev,"EP %u already %s\n" , ep->index, - halt ?"halted" :"not halted" ); -return 0 ; - } -if (halt) {ep_halt (xudc, ep->index); }else {
Greg Kroah-Hartman
maintainerPATCH 149/451 usb: phy: Initialize struct usb_phy list_head
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Diogo Ivo <[email protected]>
commit c69ff68b097b0f53333114f1b2c3dc128f389596 upstream.
As part of the registration of a new 'struct usb_phy' with the USB PHY core via either usb_add_phy(struct usb_phy *x, ...) or usb_add_phy_dev(struct usb_phy *x) these functions call list_add_tail(&x->head, phy_list) in order for the new instance x to be stored in phy_list, a static list kept internally by the core.
After 7d21114dc6a2 ("usb: phy: Introduce one extcon device into usb phy") when executing either of the registration functions above it is possible that usb_add_extcon() fails, leading to either function returning before the call to list_add_tail(), leaving x->head uninitialized.
Then, when a driver tries to undo the failed registration by calling usb_remove_phy(struct usb_phy *x) there will be an unconditional call to list_del(&x->head) acting on an uninitialized variable, and thus a possible NULL pointer dereference.
Fix this by initializing x->head before usb_add_extcon() has a chance to fail. Note that this was not needed before 7d21114dc6a2 since list_add_phy() was executed unconditionally and it guaranteed that x->head was initialized.
--- drivers/usb/phy/phy.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/phy/phy.c +4 -0
@@ -634,6 +634,8 @@ int usb_add_phy(struct usb_phy *x, enumreturn -EINVAL ; } +INIT_LIST_HEAD (&x->head); +usb_charger_init (x); ret =usb_add_extcon (x);if (ret)
@@ -679,6 +681,8 @@ int usb_add_phy_dev(struct usb_phy *x)return -EINVAL ; } +INIT_LIST_HEAD (&x->head); +usb_charger_init (x); ret =usb_add_extcon (x);if (ret)
Greg Kroah-Hartman
maintainerPATCH 150/451 ALSA: dice: fix buffer overflow in detect_stream_formats()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
commit 324f3e03e8a85931ce0880654e3c3eb38b0f0bba upstream.
The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS.
Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().
--- sound/firewire/dice/dice-extension.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/firewire/dice/dice-extension.c +2 -2
@@ -116,7 +116,7 @@ static int detect_stream_formats(structbreak ; base_offset +=EXT_APP_STREAM_ENTRIES ; - stream_count =be32_to_cpu (reg[0 ]); + stream_count = min_t(unsigned int, be32_to_cpu(reg[0]), MAX_STREAMS); err = read_stream_entries(dice, section_addr, base_offset, stream_count, mode, dice->tx_pcm_chs,
@@ -125,7 +125,7 @@ static int detect_stream_formats(structbreak ; base_offset += stream_count *EXT_APP_STREAM_ENTRY_SIZE ; - stream_count =be32_to_cpu (reg[1 ]); + stream_count = min_t(unsigned int, be32_to_cpu(reg[1]), MAX_STREAMS); err = read_stream_entries(dice, section_addr, base_offset, stream_count, mode, dice->rx_pcm_chs,
Greg Kroah-Hartman
maintainerPATCH 151/451 NFS: Fix missing unlock in nfs_unlink()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sun Ke <[email protected]>
commit 2067231a9e2cbbcae0a4aca6ac36ff2dd6a7b701 upstream.
Add the missing unlock before goto.
--- fs/nfs/dir.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/nfs/dir.c +3 -1
@@ -2109,8 +2109,10 @@ int nfs_unlink(struct inode *dir, struct*/ error = -ETXTBSY ;if (WARN_ON (dentry->d_flags &DCACHE_NFSFS_RENAMED ) || -WARN_ON (dentry->d_fsdata ==NFS_FSDATA_BLOCKED )) +WARN_ON (dentry->d_fsdata ==NFS_FSDATA_BLOCKED )) { +spin_unlock (&dentry->d_lock); goto out; + }if (dentry->d_fsdata)/* old devname */ kfree (dentry->d_fsdata);
Greg Kroah-Hartman
maintainerPATCH 152/451 netfilter: nf_conncount: garbage collection is not skipped when jiffies wrap around
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicklas Bo Jensen <[email protected]>
commit df08c94baafb001de6cf44bb7098bb557f36c335 upstream.
nf_conncount is supposed to skip garbage collection if it has already run garbage collection in the same jiffy. Unfortunately, this is broken when jiffies wrap around which this patch fixes.
The problem is that last_gc in the nf_conncount_list struct is an u32, but jiffies is an unsigned long which is 8 bytes on my systems. When those two are compared it only works until last_gc wraps around.
See bug report: https://bugzilla.netfilter.org/show_bug.cgi?id=1778
for more details.
--- net/netfilter/nf_conncount.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nf_conncount.c +2 -2
@@ -182,7 +182,7 @@ static int __nf_conncount_add(struct netreturn -EEXIST ; } -if (time_is_after_eq_jiffies ((unsigned long )list->last_gc)) +if ((u32 )jiffies == list->last_gc) goto add_new_node;/* check the saved connections */
@@ -288,7 +288,7 @@ bool nf_conncount_gc_list(struct net *nebool ret = false;/* don't bother if we just did GC */ -if (time_is_after_eq_jiffies ((unsigned long )READ_ONCE (list->last_gc))) +if ((u32 )jiffies ==READ_ONCE (list->last_gc))return false;/* don't bother if other cpu is already doing GC */
Greg Kroah-Hartman
maintainerPATCH 153/451 i3c: fix uninitialized variable use in i2c setup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jamie Iles <[email protected]>
commit 6cbf8b38dfe3aabe330f2c356949bc4d6a1f034f upstream.
Commit 31b9887c7258 ("i3c: remove i2c board info from i2c_dev_desc") removed the boardinfo from i2c_dev_desc to decouple device enumeration from setup but did not correctly lookup the i2c_dev_desc to store the new device, instead dereferencing an uninitialized variable.
Lookup the device that has already been registered by address to store the i2c client device.
--- drivers/i3c/master.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/i3c/master.c +6 -1
@@ -2364,8 +2364,13 @@ static int i3c_master_i2c_adapter_init(s* We silently ignore failures here. The bus should keep working * correctly even if one or more i2c devices are not registered. */ -list_for_each_entry (i2cboardinfo, &master->boardinfo.i2c, node) +list_for_each_entry (i2cboardinfo, &master->boardinfo.i2c, node) { + i2cdev =i3c_master_find_i2c_dev_by_addr (master, + i2cboardinfo->base.addr); +if (WARN_ON (!i2cdev)) +continue ; i2cdev->dev =i2c_new_client_device (adap, &i2cboardinfo->base); + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 154/451 netfilter: nft_connlimit: memleak if nf_ct_netns_get() fails
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 7d70984a1ad4c445dff08edb9aacce8906b6a222 upstream.
Check if nf_ct_netns_get() fails then release the limit object previously allocated via kmalloc().
--- net/netfilter/nft_connlimit.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
net/netfilter/nft_connlimit.c +10 -1
@@ -56,6 +56,7 @@ static int nft_connlimit_do_init(const s {bool invert = false;u32 flags, limit; +int err;if (!tb[NFTA_CONNLIMIT_COUNT ])return -EINVAL ;
@@ -78,7 +79,15 @@ static int nft_connlimit_do_init(const s priv->limit = limit; priv->invert = invert; -return nf_ct_netns_get (ctx->net, ctx->family); + err =nf_ct_netns_get (ctx->net, ctx->family); +if (err <0 ) + goto err_netns; + +return 0 ; +err_netns: +kfree (priv->list); + +return err; } static void nft_connlimit_do_destroy(const struct nft_ctx *ctx,
Greg Kroah-Hartman
maintainerPATCH 155/451 bpf, arm64: Do not audit capability check in do_jit()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ondrej Mosnacek <[email protected]>
[ Upstream commit 189e5deb944a6f9c7992355d60bffd8ec2e54a9c ]
Analogically to the x86 commit 881a9c9cb785 ("bpf: Do not audit capability check in do_jit()"), change the capable() call to ns_capable_noaudit() in order to avoid spurious SELinux denials in audit log.
The commit log from that commit applies here as well:
"""
The failure of this check only results in a security mitigation being applied, slightly affecting performance of the compiled BPF program. It doesn't result in a failed syscall, an thus auditing a failed LSM permission check for it is unwanted. For example with SELinux, it causes a denial to be reported for confined processes running as root, which tends to be flagged as a problem to be fixed in the policy. Yet dontauditing or allowing CAP_SYS_ADMIN to the domain may not be desirable, as it would allow/silence also other checks - either going against the principle of least privilege or making debugging potentially harder.
Fix it by changing it from capable() to ns_capable_noaudit(), which instructs the LSMs to not audit the resulting denials. """
--- arch/arm64/net/bpf_jit_comp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/net/bpf_jit_comp.c +1 -1
@@ -342,7 +342,7 @@ static void __maybe_unused build_bhb_mitigation(struct jit_ctx *ctx) arm64_get_spectre_v2_state() == SPECTRE_VULNERABLE)return ; -if (capable (CAP_SYS_ADMIN )) +if (ns_capable_noaudit (&init_user_ns,CAP_SYS_ADMIN ))return ;if (supports_clearbhb (SCOPE_SYSTEM )) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 156/451 btrfs: fix memory leak of fs_devices in degraded seed device path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
[ Upstream commit b57f2ddd28737db6ff0e9da8467f0ab9d707e997 ]
In open_seed_devices(), when find_fsid() fails and we're in DEGRADED mode, a new fs_devices is allocated via alloc_fs_devices() but is never added to the seed_list before returning. This contrasts with the normal path where fs_devices is properly added via list_add().
If any error occurs later in read_one_dev() or btrfs_read_chunk_tree(), the cleanup code iterates seed_list to free seed devices, but this orphaned fs_devices is never found and never freed, causing a memory leak. Any devices allocated via add_missing_dev() and attached to this fs_devices are also leaked.
Fix this by adding the newly allocated fs_devices to seed_list in the degraded path, consistent with the normal path.
--- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/volumes.c +1 -0
@@ -6899,6 +6899,7 @@ static struct btrfs_fs_devices *open_seed_devices(struct btrfs_fs_info *fs_info, fs_devices->seeding = true; fs_devices->opened =1 ; +list_add (&fs_devices->seed_list, &fs_info->fs_devices->seed_list);return fs_devices; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 157/451 x86/ptrace: Always inline trivial accessors
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
[ Upstream commit 1fe4002cf7f23d70c79bda429ca2a9423ebcfdfa ]
A KASAN build bloats these single load/store helpers such that it fails to inline them:
vmlinux.o: error: objtool: irqentry_exit+0x5e8: call to instruction_pointer_set() with UACCESS enabled
Make sure the compiler isn't allowed to do stupid.
--- arch/x86/include/asm/ptrace.h | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
arch/x86/include/asm/ptrace.h +10 -10
@@ -109,12 +109,12 @@ convert_ip_to_linear(struct task_struct *child, struct pt_regs *regs);extern void send_sigtrap (struct pt_regs *regs,int error_code,int si_code); -static inline unsigned long regs_return_value (struct pt_regs *regs) +static __always_inline unsigned long regs_return_value (struct pt_regs *regs) {return regs->ax; } -static inline void regs_set_return_value (struct pt_regs *regs,unsigned long rc) +static __always_inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc) { regs->ax = rc; }
@@ -195,34 +195,34 @@ static inline bool ip_within_syscall_gap(struct pt_regs *regs) }#endif -static inline unsigned long kernel_stack_pointer (struct pt_regs *regs) +static __always_inline unsigned long kernel_stack_pointer (struct pt_regs *regs) {return regs->sp; } -static inline unsigned long instruction_pointer (struct pt_regs *regs) +static __always_inline unsigned long instruction_pointer (struct pt_regs *regs) {return regs->ip; } -static inline void instruction_pointer_set (struct pt_regs *regs, -unsigned long val) +static __always_inline +void instruction_pointer_set(struct pt_regs *regs, unsigned long val) { regs->ip = val; } -static inline unsigned long frame_pointer (struct pt_regs *regs) +static __always_inline unsigned long frame_pointer (struct pt_regs *regs) {return regs->bp; } -static inline unsigned long user_stack_pointer (struct pt_regs *regs) +static __always_inline unsigned long user_stack_pointer (struct pt_regs *regs) {return regs->sp; } -static inline void user_stack_pointer_set (struct pt_regs *regs, -unsigned long val) +static __always_inline +void user_stack_pointer_set(struct pt_regs *regs, unsigned long val) { regs->sp = val; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 158/451 ACPICA: Avoid walking the Namespace if start_node is NULL
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cryolitia PukNgae <[email protected]>
[ Upstream commit 9d6c58dae8f6590c746ac5d0012ffe14a77539f0 ]
Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace if it is not there") fixed the situation when both start_node and acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed on Honor Magicbook 14 Pro [1].
That happens due to the access to the member of parent_node in acpi_ns_get_next_node(). The NULL pointer dereference will always happen, no matter whether or not the start_node is equal to ACPI_ROOT_OBJECT, so move the check of start_node being NULL out of the if block.
Unfortunately, all the attempts to contact Honor have failed, they refused to provide any technical support for Linux.
The bad DSDT table's dump could be found on GitHub [2].
DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025
--- drivers/acpi/acpica/nswalk.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/acpi/acpica/nswalk.c +6 -3
@@ -169,9 +169,12 @@ acpi_ns_walk_namespace(acpi_object_type type,if (start_node ==ACPI_ROOT_OBJECT ) { start_node = acpi_gbl_root_node; -if (!start_node) { -return_ACPI_STATUS (AE_NO_NAMESPACE ); - } + } + +/* Avoid walking the namespace if the StartNode is NULL */ + +if (!start_node) { +return_ACPI_STATUS (AE_NO_NAMESPACE ); }/* Null child means "get first node" */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 159/451 ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint() only
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <[email protected]>
[ Upstream commit 5d010473cdeaabf6a2d3a9e2aed2186c1b73c213 ]
Calling fwnode_get_next_child_node() in ACPI implementation of the fwnode property API is somewhat problematic as the latter is used in the impelementation of the former. Instead of using fwnode_get_next_child_node() in acpi_graph_get_next_endpoint(), call acpi_get_next_subnode() directly instead.
--- drivers/acpi/property.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/acpi/property.c +4 -4
@@ -1188,7 +1188,7 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint(if (!prev) { do { - port = fwnode_get_next_child_node(fwnode, port); + port = acpi_get_next_subnode(fwnode, port); /* * The names of the port nodes begin with "port@" * followed by the number of the port node and they also
@@ -1206,13 +1206,13 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint(if (!port)return NULL ; - endpoint =fwnode_get_next_child_node (port, prev); + endpoint =acpi_get_next_subnode (port, prev);while (!endpoint) { - port =fwnode_get_next_child_node (fwnode, port); + port =acpi_get_next_subnode (fwnode, port);if (!port)break ;if (is_acpi_graph_node (port,"port" )) - endpoint =fwnode_get_next_child_node (port,NULL ); + endpoint =acpi_get_next_subnode (port,NULL ); }/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 160/451 cpufreq: s5pv210: fix refcount leak
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuhao Fu <[email protected]>
[ Upstream commit 2de5cb96060a1664880d65b120e59485a73588a8 ]
In function s5pv210_cpu_init, a possible refcount inconsistency has been identified, causing a resource leak.
Why it is a bug:
1. For every clk_get, there should be a matching clk_put on every successive error handling path.
2. After calling clk_get(dmc1_clk), variable dmc1_clk will not be freed even if any error happens.
How it is fixed: For every failed path, an extra goto label is added to ensure dmc1_clk will be freed regardlessly.
--- drivers/cpufreq/s5pv210-cpufreq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/cpufreq/s5pv210-cpufreq.c +4 -2
@@ -518,7 +518,7 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)if (policy->cpu !=0 ) { ret = -EINVAL ; - goto out_dmc1; + goto out; }/*
@@ -530,7 +530,7 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)if ((mem_type !=LPDDR ) && (mem_type !=LPDDR2 )) {pr_err ("CPUFreq doesn't support this memory type\n" ); ret = -EINVAL ; - goto out_dmc1; + goto out; }/* Find current refresh counter and frequency each DMC */
@@ -544,6 +544,8 @@ static int s5pv210_cpu_init(struct cpufreq_policy *policy)cpufreq_generic_init (policy, s5pv210_freq_table,40000 );return 0 ; +out: +clk_put (dmc1_clk); out_dmc1:clk_put (dmc0_clk); out_dmc0:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 161/451 livepatch: Match old_sympos 0 and 1 in klp_find_func()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Song Liu <[email protected]>
[ Upstream commit 139560e8b973402140cafeb68c656c1374bd4c20 ]
When there is only one function of the same name, old_sympos of 0 and 1 are logically identical. Match them in klp_find_func().
This is to avoid a corner case with different toolchain behavior.
In this specific issue, two versions of kpatch-build were used to build livepatch for the same kernel. One assigns old_sympos == 0 for unique local functions, the other assigns old_sympos == 1 for unique local functions. Both versions work fine by themselves. (PS: This behavior change was introduced in a downstream version of kpatch-build. This change does not exist in upstream kpatch-build.)
However, during livepatch upgrade (with the replace flag set) from a patch built with one version of kpatch-build to the same fix built with the other version of kpatch-build, livepatching fails with errors like:
[ 14.218706] sysfs: cannot create duplicate filename 'xxx/somefunc,1'
...
[ 14.219466] Call Trace:
[ 14.219468] <TASK>
[ 14.219469] dump_stack_lvl+0x47/0x60
[ 14.219474] sysfs_warn_dup.cold+0x17/0x27
[ 14.219476] sysfs_create_dir_ns+0x95/0xb0
[ 14.219479] kobject_add_internal+0x9e/0x260
[ 14.219483] kobject_add+0x68/0x80
[ 14.219485] ? kstrdup+0x3c/0xa0
[ 14.219486] klp_enable_patch+0x320/0x830
[ 14.219488] patch_init+0x443/0x1000 [ccc_0_6]
[ 14.219491] ? 0xffffffffa05eb000
[ 14.219492] do_one_initcall+0x2e/0x190
[ 14.219494] do_init_module+0x67/0x270
[ 14.219496] init_module_from_file+0x75/0xa0
[ 14.219499] idempotent_init_module+0x15a/0x240
[ 14.219501] __x64_sys_finit_module+0x61/0xc0
[ 14.219503] do_syscall_64+0x5b/0x160
[ 14.219505] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 14.219507] RIP: 0033:0x7f545a4bd96d
...
[ 14.219516] kobject: kobject_add_internal failed for somefunc,1 with
-EEXIST, don't try to register things with the same name ...This happens because klp_find_func() thinks somefunc with old_sympos==0 is not the same as somefunc with old_sympos==1, and klp_add_object_nops adds another xxx/func,1 to the list of functions to patch.
--- kernel/livepatch/core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
kernel/livepatch/core.c +7 -1
@@ -89,8 +89,14 @@ static struct klp_func *klp_find_func(struct klp_object *obj,struct klp_func *func;klp_for_each_func (obj, func) { +/* +* Besides identical old_sympos, also consider old_sympos +* of 0 and 1 are identical. +*/ if ((strcmp (old_func->old_name, func->old_name) ==0 ) && - (old_func->old_sympos == func->old_sympos)) { + ((old_func->old_sympos == func->old_sympos) || + (old_func->old_sympos ==0 && func->old_sympos ==1 ) || + (old_func->old_sympos ==1 && func->old_sympos ==0 ))) {return func; } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 162/451 hfsplus: fix volume corruption issue for generic/070
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit ed490f36f439b877393c12a2113601e4145a5a56 ]
The xfstests' test-case generic/070 leaves HFS+ volume in corrupted state:
sudo ./check generic/070
FSTYP -- hfsplus
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
generic/070 _check_generic_filesystem: filesystem on /dev/loop50 is inconsistent (see xfstests-dev/results//generic/070.full for details)
Ran: generic/070
Failures: generic/070
Failed 1 of 1 tests
sudo fsck.hfsplus -d /dev/loop50
** /dev/loop50
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux).
** Checking non-journaled HFS Plus Volume.
The volume name is test
** Checking extents overflow file.
Unused node is not erased (node = 1)
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0004 CBTStat = 0x0000 CatStat = 0x00000000
** Repairing volume.
** Rechecking volume.
** Checking non-journaled HFS Plus Volume.
The volume name is test
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume test was repaired successfully.
It is possible to see that fsck.hfsplus detected not erased and unused node for the case of extents overflow file. The HFS+ logic has special method that defines if the node should be erased:
bool hfs_bnode_need_zeroout(struct hfs_btree *tree)
{
struct super_block *sb = tree->inode->i_sb;
struct hfsplus_sb_info *sbi = HFSPLUS_SB(sb);
const u32 volume_attr = be32_to_cpu(sbi->s_vhdr->attributes);
return tree->cnid == HFSPLUS_CAT_CNID &&
volume_attr & HFSPLUS_VOL_UNUSED_NODE_FIX;
}However, it is possible to see that this method works only for the case of catalog file. But debugging of the issue has shown that HFSPLUS_VOL_UNUSED_NODE_FIX attribute has been requested for the extents overflow file too:
catalog file
kernel: hfsplus: node 4, num_recs 0, flags 0x10
kernel: hfsplus: tree->cnid 4, volume_attr 0x80000800
extents overflow file
kernel: hfsplus: node 1, num_recs 0, flags 0x10
kernel: hfsplus: tree->cnid 3, volume_attr 0x80000800
This patch modifies the hfs_bnode_need_zeroout() by checking only volume_attr but not the b-tree ID because node zeroing can be requested for all HFS+ b-tree types.
sudo ./check generic/070
FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc3+ #79 SMP PREEMPT_DYNAMIC Fri Oct 31 16:07:42 PDT 2025 MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
generic/070 33s ... 34s
Ran: generic/070
Passed all 1 tests
--- fs/hfsplus/bnode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/hfsplus/bnode.c +1 -2
@@ -717,6 +717,5 @@ bool hfs_bnode_need_zeroout(struct hfs_btree *tree)struct hfsplus_sb_info *sbi =HFSPLUS_SB (sb);const u32 volume_attr =be32_to_cpu (sbi->s_vhdr->attributes); -return tree->cnid ==HFSPLUS_CAT_CNID && - volume_attr &HFSPLUS_VOL_UNUSED_NODE_FIX ; +return volume_attr &HFSPLUS_VOL_UNUSED_NODE_FIX ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 163/451 hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Chenzhi <[email protected]>
[ Upstream commit 152af114287851583cf7e0abc10129941f19466a ]
When sync() and link() are called concurrently, both threads may enter hfs_bnode_find() without finding the node in the hash table and proceed to create it.
Thread A:
hfsplus_write_inode()
-> hfsplus_write_system_inode()
-> hfs_btree_write()
-> hfs_bnode_find(tree, 0)
-> __hfs_bnode_create(tree, 0)Thread B:
hfsplus_create_cat()
-> hfs_brec_insert()
-> hfs_bnode_split()
-> hfs_bmap_alloc()
-> hfs_bnode_find(tree, 0)
-> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it. Thread B also tries to create the same bnode, notices it has already been inserted, drops its own instance, and uses the hashed one without getting the node.
```
node2 = hfs_bnode_findhash(tree, cnid);
if (!node2) { <- Thread A
hash = hfs_bnode_hash(cnid);
node->next_hash = tree->node_hash[hash];
tree->node_hash[hash] = node;
tree->node_hash_cnt++;
} else { <- Thread B
spin_unlock(&tree->hash_lock);
kfree(node);
wait_event(node2->lock_wq,
!test_bit(HFS_BNODE_NEW, &node2->flags));
return node2;
}
```However, hfs_bnode_find() requires each call to take a reference. Here both threads end up setting refcnt=1. When they later put the node, this triggers:
BUG_ON(!atomic_read(&node->refcnt))
In this scenario, Thread B in fact finds the node in the hash table rather than creating a new one, and thus must take a reference.
Fix this by calling hfs_bnode_get() when reusing a bnode newly created by another thread to ensure the refcount is updated correctly.
A similar bug was fixed in HFS long ago in commit a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create") but the same issue remained in HFS+ until now.
--- fs/hfsplus/bnode.c | 1 + 1 file changed, 1 insertion(+)
fs/hfsplus/bnode.c +1 -0
@@ -488,6 +488,7 @@ static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid) tree->node_hash[hash] = node; tree->node_hash_cnt++; }else { +hfs_bnode_get (node2);spin_unlock (&tree->hash_lock);kfree (node); wait_event(node2->lock_wq,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 164/451 hfsplus: Verify inode mode when loading from disk
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
[ Upstream commit 005d4b0d33f6b4a23d382b7930f7a96b95b01f39 ]
syzbot is reporting that S_IFMT bits of inode->i_mode can become bogus when the S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.
According to [1], the permissions field was treated as reserved in Mac OS 8 and 9. According to [2], the reserved field was explicitly initialized with 0, and that field must remain 0 as long as reserved. Therefore, when the "mode" field is not 0 (i.e. no longer reserved), the file must be S_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/ S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
--- fs/hfsplus/inode.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-)
fs/hfsplus/inode.c +28 -4
@@ -178,13 +178,29 @@ const struct dentry_operations hfsplus_dentry_operations = { .d_compare = hfsplus_compare_dentry, }; -static void hfsplus_get_perms (struct inode *inode, -struct hfsplus_perm *perms,int dir) +static int hfsplus_get_perms (struct inode *inode, +struct hfsplus_perm *perms,int dir) {struct hfsplus_sb_info *sbi =HFSPLUS_SB (inode->i_sb);u16 mode; mode =be16_to_cpu (perms->mode); +if (dir) { +if (mode && !S_ISDIR (mode)) + goto bad_type; + }else if (mode) { +switch (mode &S_IFMT ) { +case S_IFREG : +case S_IFLNK : +case S_IFCHR : +case S_IFBLK : +case S_IFIFO : +case S_IFSOCK : +break ; +default : + goto bad_type; + } + }i_uid_write (inode,be32_to_cpu (perms->owner));if ((test_bit (HFSPLUS_SB_UID , &sbi->flags)) || (!i_uid_read (inode) && !mode))
@@ -210,6 +226,10 @@ static void hfsplus_get_perms(struct inode *inode, inode->i_flags |=S_APPEND ; else inode->i_flags &= ~S_APPEND; +return 0 ; +bad_type: +pr_err ("invalid file type 0%04o for inode %lu\n" , mode, inode->i_ino); +return -EIO ; }static int hfsplus_file_open (struct inode *inode,struct file *file)
@@ -504,7 +524,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd) }hfs_bnode_read (fd->bnode, &entry, fd->entryoffset,sizeof (struct hfsplus_cat_folder )); -hfsplus_get_perms (inode, &folder->permissions,1 ); + res =hfsplus_get_perms (inode, &folder->permissions,1 ); +if (res) + goto out;set_nlink (inode,1 ); inode->i_size =2 +be32_to_cpu (folder->valence); inode->i_atime =hfsp_mt2ut (folder->access_date);
@@ -531,7 +553,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd)hfsplus_inode_read_fork (inode,HFSPLUS_IS_RSRC (inode) ? &file->rsrc_fork : &file->data_fork); -hfsplus_get_perms (inode, &file->permissions,0 ); + res =hfsplus_get_perms (inode, &file->permissions,0 ); +if (res) + goto out;set_nlink (inode,1 );if (S_ISREG (inode->i_mode)) {if (file->permissions.dev)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 165/451 hfsplus: fix volume corruption issue for generic/073
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit 24e17a29cf7537f0947f26a50f85319abd723c6c ]
The xfstests' test-case generic/073 leaves HFS+ volume in corrupted state:
sudo ./check generic/073
FSTYP -- hfsplus
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
generic/073 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/073.full for details)
Ran: generic/073
Failures: generic/073
Failed 1 of 1 tests
sudo fsck.hfsplus -d /dev/loop51
** /dev/loop51
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux).
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
Invalid directory item count
(It should be 1 instead of 0)
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00004000
** Repairing volume.
** Rechecking volume.
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume untitled was repaired successfully.
The test is doing these steps on final phase:
mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
So, we move file bar from testdir_1 into testdir_2 folder. It means that HFS+ logic decrements the number of entries in testdir_1 and increments number of entries in testdir_2. Finally, we do fsync only for testdir_1 and foo but not for testdir_2. As a result, this is the reason why fsck.hfsplus detects the volume corruption afterwards.
This patch fixes the issue by means of adding the hfsplus_cat_write_inode() call for old_dir and new_dir in hfsplus_rename() after the successful ending of hfsplus_rename_cat(). This method makes modification of in-core inode objects for old_dir and new_dir but it doesn't save these modifications in Catalog File's entries. It was expected that hfsplus_write_inode() will save these modifications afterwards. However, because generic/073 does fsync only for testdir_1 and foo then testdir_2 modification hasn't beed saved into Catalog File's entry and it was flushed without this modification. And it was detected by fsck.hfsplus. Now, hfsplus_rename() stores in Catalog File all modified entries and correct state of Catalog File will be flushed during hfsplus_file_fsync() call. Finally, it makes fsck.hfsplus happy.
sudo ./check generic/073
FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc3+ #93 SMP PREEMPT_DYNAMIC Wed Nov 12 14:37:49 PST 2025 MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
generic/073 32s ... 32s
Ran: generic/073
Passed all 1 tests
--- fs/hfsplus/dir.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/hfsplus/dir.c +6 -1
@@ -550,8 +550,13 @@ static int hfsplus_rename(struct inode *old_dir, struct dentry *old_dentry, res =hfsplus_rename_cat ((u32 )(unsigned long )old_dentry->d_fsdata, old_dir, &old_dentry->d_name, new_dir, &new_dentry->d_name); -if (!res) +if (!res) { new_dentry->d_fsdata = old_dentry->d_fsdata; + + res =hfsplus_cat_write_inode (old_dir); +if (!res) + res =hfsplus_cat_write_inode (new_dir); + }return res; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 166/451 btrfs: scrub: always update btrfs_scrub_progress::last_physical
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
[ Upstream commit 54df8b80cc63aa0f22c4590cad11542731ed43ff ]
[BUG]
When a scrub failed immediately without any byte scrubbed, the returned btrfs_scrub_progress::last_physical will always be 0, even if there is a non-zero @start passed into btrfs_scrub_dev() for resume cases.
This will reset the progress and make later scrub resume start from the beginning.
[CAUSE]
The function btrfs_scrub_dev() accepts a @progress parameter to copy its updated progress to the caller, there are cases where we either don't touch progress::last_physical at all or copy 0 into last_physical:
- last_physical not updated at all
If some error happened before scrubbing any super block or chunk, we will not copy the progress, leaving the @last_physical untouched.
E.g. failed to allocate @sctx, scrubbing a missing device or even there is already a running scrub and so on.
All those cases won't touch @progress at all, resulting the last_physical untouched and will be left as 0 for most cases.
- Error out before scrubbing any bytes
In those case we allocated @sctx, and sctx->stat.last_physical is all zero (initialized by kvzalloc()).
Unfortunately some critical errors happened during scrub_enumerate_chunks() or scrub_supers() before any stripe is really scrubbed.
In that case although we will copy sctx->stat back to @progress, since no byte is really scrubbed, last_physical will be overwritten to 0.
[FIX]
Make sure the parameter @progress always has its @last_physical member updated to @start parameter inside btrfs_scrub_dev().
At the very beginning of the function, set @progress->last_physical to @start, so that even if we error out without doing progress copying, last_physical is still at @start.
Then after we got @sctx allocated, set sctx->stat.last_physical to @start, this will make sure even if we didn't get any byte scrubbed, at the progress copying stage the @last_physical is not left as zero.
This should resolve the resume progress reset problem.
--- fs/btrfs/scrub.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/btrfs/scrub.c +5 -0
@@ -3820,6 +3820,10 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,unsigned int nofs_flag;bool need_commit = false; +/* Set the basic fallback @last_physical before we got a sctx. */ +if (progress) + progress->last_physical = start; +if (btrfs_fs_closing (fs_info))return -EAGAIN ;
@@ -3864,6 +3868,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, sctx =scrub_setup_ctx (fs_info, is_dev_replace);if (IS_ERR (sctx))return PTR_ERR (sctx); + sctx->stat.last_physical = start; ret =scrub_workers_get (fs_info, is_dev_replace);if (ret)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 167/451 Bluetooth: btusb: Add new VID/PID 13d3/3533 for RTL8821CE
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gongwei Li <[email protected]>
[ Upstream commit 525459da4bd62a81142fea3f3d52188ceb4d8907 ]
Add VID 13d3 & PID 3533 for Realtek RTL8821CE USB Bluetooth chip.
The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3533 Rev= 1.10 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/btusb.c +2 -0
@@ -396,6 +396,8 @@ static const struct usb_device_id blacklist_table[] = {/* Realtek 8821CE Bluetooth devices */ { USB_DEVICE(0x13d3, 0x3529), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3533), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, /* Realtek 8822CE Bluetooth devices */ { USB_DEVICE(0x0bda, 0xb00c), .driver_info = BTUSB_REALTEK |
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 168/451 netrom: Fix memory leak in nr_sendmsg()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Liang <[email protected]>
[ Upstream commit 613d12dd794e078be8ff3cf6b62a6b9acf7f4619 ]
syzbot reported a memory leak [1].
When function sock_alloc_send_skb() return NULL in nr_output(), the original skb is not freed, which was allocated in nr_sendmsg(). Fix this by freeing it before return.
[1]
BUG: memory leak
unreferenced object 0xffff888129f35500 (size 240):
comm "syz.0.17", pid 6119, jiffies 4294944652
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(....
backtrace (crc 1456a3e4):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4983 [inline]
slab_alloc_node mm/slub.c:5288 [inline]
kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340
__alloc_skb+0x203/0x240 net/core/skbuff.c:660
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671
sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965
sock_alloc_send_skb include/net/sock.h:1859 [inline]
nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
sock_write_iter+0x293/0x2a0 net/socket.c:1195
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x45d/0x710 fs/read_write.c:686
ksys_write+0x143/0x170 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f--- net/netrom/nr_out.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/netrom/nr_out.c +3 -1
@@ -43,8 +43,10 @@ void nr_output(struct sock *sk, struct sk_buff *skb) frontlen =skb_headroom (skb);while (skb->len >0 ) { -if ((skbn =sock_alloc_send_skb (sk, frontlen +NR_MAX_PACKET_SIZE ,0 , &err)) ==NULL ) +if ((skbn =sock_alloc_send_skb (sk, frontlen +NR_MAX_PACKET_SIZE ,0 , &err)) ==NULL ) { +kfree_skb (skb);return ; + }skb_reserve (skbn, frontlen);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 169/451 net/sched: ets: Always remove class from active list before deleting in ets_qdisc_change
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jamal Hadi Salim <[email protected]>
[ Upstream commit ce052b9402e461a9aded599f5b47e76bc727f7de ]
[email protected] says:
The vulnerability is a race condition between ets_qdisc_dequeue and ets_qdisc_change. It leads to UAF on struct Qdisc object. Attacker requires the capability to create new user and network namespace in order to trigger the bug.
See my additional commentary at the end of the analysis.
Analysis:
static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,
struct netlink_ext_ack *extack)
{
...
// (1) this lock is preventing .change handler (`ets_qdisc_change`)
//to race with .dequeue handler (`ets_qdisc_dequeue`)
sch_tree_lock(sch);
for (i = nbands; i < oldbands; i++) {
if (i >= q->nstrict && q->classes[i].qdisc->q.qlen)
list_del_init(&q->classes[i].alist);
qdisc_purge_queue(q->classes[i].qdisc);
}
WRITE_ONCE(q->nbands, nbands);
for (i = nstrict; i < q->nstrict; i++) {
if (q->classes[i].qdisc->q.qlen) {
// (2) the class is added to the q->active
list_add_tail(&q->classes[i].alist, &q->active);
q->classes[i].deficit = quanta[i];
}
}
WRITE_ONCE(q->nstrict, nstrict);
memcpy(q->prio2band, priomap, sizeof(priomap));
for (i = 0; i < q->nbands; i++)
WRITE_ONCE(q->classes[i].quantum, quanta[i]);
for (i = oldbands; i < q->nbands; i++) {
q->classes[i].qdisc = queues[i];
if (q->classes[i].qdisc != &noop_qdisc)
qdisc_hash_add(q->classes[i].qdisc, true);
}
// (3) the qdisc is unlocked, now dequeue can be called in parallel
// to the rest of .change handler
sch_tree_unlock(sch);
ets_offload_change(sch);
for (i = q->nbands; i < oldbands; i++) {
// (4) we're reducing the refcount for our class's qdisc and
// freeing it
qdisc_put(q->classes[i].qdisc);
// (5) If we call .dequeue between (4) and (5), we will have
// a strong UAF and we can control RIP
q->classes[i].qdisc = NULL;
WRITE_ONCE(q->classes[i].quantum, 0);
q->classes[i].deficit = 0;
gnet_stats_basic_sync_init(&q->classes[i].bstats);
memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats));
}
return 0;
}Comment:
This happens because some of the classes have their qdiscs assigned to NULL, but remain in the active list. This commit fixes this issue by always removing the class from the active list before deleting and freeing its associated qdisc
Reproducer Steps
(trimmed version of what was sent by [email protected])
```
DEV="${DEV:-lo}"
ROOT_HANDLE="${ROOT_HANDLE:-1:}"
BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2
PING_BYTES="${PING_BYTES:-48}"
PING_COUNT="${PING_COUNT:-200000}"
PING_DST="${PING_DST:-127.0.0.1}"
SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"
SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"
SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"
cleanup() {
tc qdisc del dev "$DEV" root 2>/dev/null
}
trap cleanup EXIT
ip link set "$DEV" up
tc qdisc del dev "$DEV" root 2>/dev/null || true
tc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2
tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \
tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"
tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2
tc -s qdisc ls dev $DEV
ping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \
>/dev/null 2>&1 &
tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0
tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2
tc -s qdisc ls dev $DEV
tc qdisc del dev "$DEV" parent 1:2 || true
tc -s qdisc ls dev $DEV
tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 1 strict 1
```KASAN report
```
==================================================================
BUG: KASAN: slab-use-after-free in ets_qdisc_dequeue+0x1071/0x11b0 kernel/net/sched/sch_ets.c:481 Read of size 8 at addr ffff8880502fc018 by task ping/12308
Quoted 1 line
CPU: 0 UID: 0 PID: 12308 Comm: ping Not tainted 6.18.0-rc4-dirty #1 PREEMPT(full) Hardware name: QEMU Ubuntu 25.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> __dump_stack kernel/lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 kernel/lib/dump_stack.c:120 print_address_description kernel/mm/kasan/report.c:378 print_report+0x156/0x4c9 kernel/mm/kasan/report.c:482 kasan_report+0xdf/0x110 kernel/mm/kasan/report.c:595 ets_qdisc_dequeue+0x1071/0x11b0 kernel/net/sched/sch_ets.c:481 dequeue_skb kernel/net/sched/sch_generic.c:294 qdisc_restart kernel/net/sched/sch_generic.c:399 __qdisc_run+0x1c9/0x1b00 kernel/net/sched/sch_generic.c:417 __dev_xmit_skb kernel/net/core/dev.c:4221 __dev_queue_xmit+0x2848/0x4410 kernel/net/core/dev.c:4729 dev_queue_xmit kernel/./include/linux/netdevice.h:3365
[...]
Allocated by task 17115: kasan_save_stack+0x30/0x50 kernel/mm/kasan/common.c:56 kasan_save_track+0x14/0x30 kernel/mm/kasan/common.c:77 poison_kmalloc_redzone kernel/mm/kasan/common.c:400 __kasan_kmalloc+0xaa/0xb0 kernel/mm/kasan/common.c:417 kasan_kmalloc kernel/./include/linux/kasan.h:262 __do_kmalloc_node kernel/mm/slub.c:5642 __kmalloc_node_noprof+0x34e/0x990 kernel/mm/slub.c:5648 kmalloc_node_noprof kernel/./include/linux/slab.h:987 qdisc_alloc+0xb8/0xc30 kernel/net/sched/sch_generic.c:950 qdisc_create_dflt+0x93/0x490 kernel/net/sched/sch_generic.c:1012 ets_class_graft+0x4fd/0x800 kernel/net/sched/sch_ets.c:261 qdisc_graft+0x3e4/0x1780 kernel/net/sched/sch_api.c:1196
[...]
Freed by task 9905: kasan_save_stack+0x30/0x50 kernel/mm/kasan/common.c:56 kasan_save_track+0x14/0x30 kernel/mm/kasan/common.c:77 __kasan_save_free_info+0x3b/0x70 kernel/mm/kasan/generic.c:587 kasan_save_free_info kernel/mm/kasan/kasan.h:406 poison_slab_object kernel/mm/kasan/common.c:252 __kasan_slab_free+0x5f/0x80 kernel/mm/kasan/common.c:284 kasan_slab_free kernel/./include/linux/kasan.h:234 slab_free_hook kernel/mm/slub.c:2539 slab_free kernel/mm/slub.c:6630 kfree+0x144/0x700 kernel/mm/slub.c:6837 rcu_do_batch kernel/kernel/rcu/tree.c:2605 rcu_core+0x7c0/0x1500 kernel/kernel/rcu/tree.c:2861 handle_softirqs+0x1ea/0x8a0 kernel/kernel/softirq.c:622 __do_softirq kernel/kernel/softirq.c:656
[...]
Commentary:
1. Maher Azzouzi working with Trend Micro Zero Day Initiative was reported as the person who found the issue. I requested to get a proper email to add to the reported-by tag but got no response. For this reason i will credit the person i exchanged emails with i.e [email protected]
2. Neither i nor Victor who did a much more thorough testing was able to reproduce a UAF with the PoC or other approaches we tried. We were both able to reproduce a null ptr deref. After exchange with [email protected] they sent a small change to be made to the code to add an extra delay which was able to simulate the UAF. i.e, this:
qdisc_put(q->classes[i].qdisc);
mdelay(90);
q->classes[i].qdisc = NULL;
I was informed by Thomas Gleixner([email protected]) that adding delays was acceptable approach for demonstrating the bug, quote:
"Adding such delays is common exploit validation practice"
The equivalent delay could happen "by virt scheduling the vCPU out, SMIs, NMIs, PREEMPT_RT enabled kernel"
3. I asked the OP to test and report back but got no response and after a few days gave up and proceeded to submit this fix.
--- net/sched/sch_ets.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/sch_ets.c +1 -1
@@ -665,7 +665,7 @@ static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,sch_tree_lock (sch);for (i = nbands; i < oldbands; i++) { -if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) +if (cl_is_active (&q->classes[i]))list_del_init (&q->classes[i].alist);qdisc_purge_queue (q->classes[i].qdisc); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 170/451 ipvlan: Ignore PACKET_LOOPBACK in handle_mode_l2()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Skorodumov <[email protected]>
[ Upstream commit 0c57ff008a11f24f7f05fa760222692a00465fec ]
Packets with pkt_type == PACKET_LOOPBACK are captured by handle_frame() function, but they don't have L2 header. We should not process them in handle_mode_l2().
This doesn't affect old L2 functionality, since handling was anyway incorrect.
Handle them the same way as in br_handle_frame():
just pass the skb.
To observe invalid behaviour, just start "ping -b" on bcast address of port-interface.
--- drivers/net/ipvlan/ipvlan_core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ipvlan/ipvlan_core.c +3 -0
@@ -726,6 +726,9 @@ static rx_handler_result_t ipvlan_handle_mode_l2(struct sk_buff **pskb,struct ethhdr *eth =eth_hdr (skb);rx_handler_result_t ret =RX_HANDLER_PASS ; +if (unlikely (skb->pkt_type ==PACKET_LOOPBACK )) +return RX_HANDLER_PASS ; +if (is_multicast_ether_addr (eth->h_dest)) {if (ipvlan_external_frame (skb, port)) {struct sk_buff *nskb =skb_clone (skb,GFP_ATOMIC );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 171/451 mlxsw: spectrum_router: Fix neighbour use-after-free
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 8b0e69763ef948fb872a7767df4be665d18f5fd4 ]
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929 CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20 Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
--- .../ethernet/mellanox/mlxsw/spectrum_router.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c +9 -8
@@ -2032,6 +2032,7 @@ mlxsw_sp_neigh_entry_alloc(struct mlxsw_sp *mlxsw_sp, struct neighbour *n,if (!neigh_entry)return NULL ; +neigh_hold (n); neigh_entry->key.n = n; neigh_entry->rif = rif;INIT_LIST_HEAD (&neigh_entry->nexthop_list);
@@ -2041,6 +2042,7 @@ mlxsw_sp_neigh_entry_alloc(struct mlxsw_sp *mlxsw_sp, struct neighbour *n,static void mlxsw_sp_neigh_entry_free (struct mlxsw_sp_neigh_entry *neigh_entry) { +neigh_release (neigh_entry->key.n);kfree (neigh_entry); }
@@ -3607,6 +3609,8 @@ mlxsw_sp_nexthop_dead_neigh_replace(struct mlxsw_sp *mlxsw_sp,if (err) goto err_neigh_entry_insert; +neigh_release (old_n); +read_lock_bh (&n->lock); nud_state = n->nud_state; dead = n->dead;
@@ -3615,14 +3619,10 @@ mlxsw_sp_nexthop_dead_neigh_replace(struct mlxsw_sp *mlxsw_sp,list_for_each_entry (nh, &neigh_entry->nexthop_list, neigh_list_node) { -neigh_release (old_n); -neigh_clone (n);__mlxsw_sp_nexthop_neigh_update (nh, !entry_connected);mlxsw_sp_nexthop_group_refresh (mlxsw_sp, nh->nh_grp); } -neigh_release (n); -return 0 ; err_neigh_entry_insert:
@@ -3711,6 +3711,11 @@ static int mlxsw_sp_nexthop_neigh_init(struct mlxsw_sp *mlxsw_sp, } } +/* Release the reference taken by neigh_lookup() / neigh_create() since +* neigh_entry already holds one. +*/ +neigh_release (n); +/* If that is the first nexthop connected to that neigh, add to * nexthop_neighs_list */
@@ -3737,11 +3742,9 @@ static void mlxsw_sp_nexthop_neigh_fini(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_nexthop *nh) {struct mlxsw_sp_neigh_entry *neigh_entry = nh->neigh_entry; -struct neighbour *n;if (!neigh_entry)return ; - n = neigh_entry->key.n;__mlxsw_sp_nexthop_neigh_update (nh, true);list_del (&nh->neigh_list_node);
@@ -3755,8 +3758,6 @@ static void mlxsw_sp_nexthop_neigh_fini(struct mlxsw_sp *mlxsw_sp,if (!neigh_entry->connected &&list_empty (&neigh_entry->nexthop_list))mlxsw_sp_neigh_entry_destroy (mlxsw_sp, neigh_entry); - -neigh_release (n); }static bool mlxsw_sp_ipip_netdev_ul_up (struct net_device *ol_dev)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 172/451 mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 8ac1dacec458f55f871f7153242ed6ab60373b90 ]
Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.
One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].
Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043 CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace: <TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
--- drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c +2 -0
@@ -440,7 +440,9 @@ int mlxsw_sp_mr_route_add(struct mlxsw_sp_mr_table *mr_table,rhashtable_remove_fast (&mr_table->route_ht, &mr_orig_route->ht_node, mlxsw_sp_mr_route_ht_params); +mutex_lock (&mr_table->route_list_lock);list_del (&mr_orig_route->node); +mutex_unlock (&mr_table->route_list_lock);mlxsw_sp_mr_route_destroy (mr_table, mr_orig_route); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 173/451 net: openvswitch: fix middle attribute validation in push_nsh() action
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Maximets <[email protected]>
[ Upstream commit 5ace7ef87f059d68b5f50837ef3e8a1a4870c36e ]
The push_nsh() action structure looks like this:
OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))
The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested() inside nsh_key_put_from_nlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data() calls - first time directly while calling validate_push_nsh() and the second time as part of the nla_for_each_nested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size:
BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVS_KEY_ATTR_NSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is.
--- net/openvswitch/flow_netlink.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
net/openvswitch/flow_netlink.c +10 -3
@@ -2760,13 +2760,20 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,return err; } -static bool validate_push_nsh (const struct nlattr *attr,bool log) +static bool validate_push_nsh (const struct nlattr *a,bool log) { +struct nlattr *nsh_key =nla_data (a);struct sw_flow_match match;struct sw_flow_key key; +/* There must be one and only one NSH header. */ +if (!nla_ok (nsh_key,nla_len (a)) || +nla_total_size (nla_len (nsh_key)) !=nla_len (a) || +nla_type (nsh_key) !=OVS_KEY_ATTR_NSH ) +return false; +ovs_match_init (&match, &key, true,NULL ); -return !nsh_key_put_from_nlattr (attr, &match, false, true, log); +return !nsh_key_put_from_nlattr (nsh_key, &match, false, true, log); }/* Return false if there are any non-masked bits set.
@@ -3320,7 +3327,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,return -EINVAL ; } mac_proto =MAC_PROTO_NONE ; -if (!validate_push_nsh (nla_data (a), log)) +if (!validate_push_nsh (a, log))return -EINVAL ;break ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 174/451 broadcom: b44: prevent uninitialized value usage
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Simakov <[email protected]>
[ Upstream commit 50b3db3e11864cb4e18ff099cfb38e11e7f87a68 ]
On execution path with raised B44_FLAG_EXTERNAL_PHY, b44_readphy() leaves bmcr value uninitialized and it is used later in the code.
Add check of this flag at the beginning of the b44_nway_reset() and exit early of the function with restarting autonegotiation if an external PHY is used.
--- drivers/net/ethernet/broadcom/b44.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/broadcom/b44.c +3 -0
@@ -1809,6 +1809,9 @@ static int b44_nway_reset(struct net_device *dev)u32 bmcr;int r; +if (bp->flags &B44_FLAG_EXTERNAL_PHY ) +return phy_ethtool_nway_reset (dev); +spin_lock_irq (&bp->lock);b44_readphy (bp,MII_BMCR , &bmcr);b44_readphy (bp,MII_BMCR , &bmcr);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 175/451 netfilter: nf_conncount: fix leaked ct in error paths
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fernando Fernandez Mancera <[email protected]>
[ Upstream commit 2e2a720766886190a6d35c116794693aabd332b6 ]
There are some situations where ct might be leaked as error paths are skipping the refcounted check and return immediately. In order to solve it make sure that the check is always called.
--- net/netfilter/nf_conncount.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
net/netfilter/nf_conncount.c +14 -11
@@ -172,14 +172,14 @@ static int __nf_conncount_add(struct net *net,struct nf_conn *found_ct;unsigned int collect =0 ;bool refcounted = false; +int err =0 ;if (!get_ct_or_tuple_from_skb (net, skb, l3num, &ct, &tuple, &zone, &refcounted))return -ENOENT ;if (ct &&nf_ct_is_confirmed (ct)) { -if (refcounted) -nf_ct_put (ct); -return -EEXIST ; + err = -EEXIST ; + goto out_put; }if ((u32 )jiffies == list->last_gc)
@@ -231,12 +231,16 @@ static int __nf_conncount_add(struct net *net, } add_new_node: -if (WARN_ON_ONCE (list->count >INT_MAX )) -return -EOVERFLOW ; +if (WARN_ON_ONCE (list->count >INT_MAX )) { + err = -EOVERFLOW ; + goto out_put; + } conn =kmem_cache_alloc (conncount_conn_cachep,GFP_ATOMIC ); -if (conn ==NULL ) -return -ENOMEM ; +if (conn ==NULL ) { + err = -ENOMEM ; + goto out_put; + } conn->tuple = tuple; conn->zone = *zone;
@@ -249,7 +253,7 @@ static int __nf_conncount_add(struct net *net, out_put:if (refcounted)nf_ct_put (ct); -return 0 ; +return err; } int nf_conncount_add_skb(struct net *net,
@@ -446,11 +450,10 @@ insert_tree(struct net *net,rb_link_node_rcu (&rbconn->node, parent, rbnode);rb_insert_color (&rbconn->node, root); - -if (refcounted) -nf_ct_put (ct); } out_unlock: +if (refcounted) +nf_ct_put (ct);spin_unlock_bh (&nf_conncount_locks[hash]);return count; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 176/451 ipvs: fix ipv4 null-ptr-deref in route error path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Slavin Liu <[email protected]>
[ Upstream commit ad891bb3d079a46a821bf2b8867854645191bab0 ]
The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fib_compute_spec_dst() when ipv4_link_failure() attempts to send ICMP destination unreachable messages.
The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure") started calling __ip_options_compile() from ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev) dereference by using a fallback device. The fix was incomplete because fib_compute_spec_dst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dst_link_failure().
The crash occurs when:
1. IPVS processes a packet in NAT mode with a misconfigured destination
2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route
3. The error path calls dst_link_failure(skb) with skb->dev == NULL
4. ipv4_link_failure() → ipv4_send_dest_unreach() → __ip_options_compile() → fib_compute_spec_dst()
5. fib_compute_spec_dst() dereferences NULL skb->dev
Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before calling dst_link_failure().
KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 Call Trace: <TASK> spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
--- net/netfilter/ipvs/ip_vs_xmit.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/ipvs/ip_vs_xmit.c +3 -0
@@ -420,6 +420,9 @@ __ip_vs_get_out_rt(struct netns_ipvs *ipvs, int skb_af, struct sk_buff *skb,return -1 ; err_unreach: +if (!skb->dev) + skb->dev =skb_dst (skb)->dev; +dst_link_failure (skb);return -1 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 177/451 caif: fix integer underflow in cffrml_receive()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
[ Upstream commit 8a11ff0948b5ad09b71896b7ccc850625f9878d1 ]
The cffrml_receive() function extracts a length field from the packet header and, when FCS is disabled, subtracts 2 from this length without validating that len >= 2.
If an attacker sends a malicious packet with a length field of 0 or 1 to an interface with FCS disabled, the subtraction causes an integer underflow.
This can lead to memory exhaustion and kernel instability, potential information disclosure if padding contains uninitialized kernel memory.
Fix this by validating that len >= 2 before performing the subtraction.
--- net/caif/cffrml.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
net/caif/cffrml.c +8 -1
@@ -92,8 +92,15 @@ static int cffrml_receive(struct cflayer *layr, struct cfpkt *pkt) len =le16_to_cpu (tmp);/* Subtract for FCS on length if FCS is not used. */ -if (!this->dofcs) +if (!this->dofcs) { +if (len <2 ) { + ++cffrml_rcv_error; +pr_err ("Invalid frame length (%d)\n" , len); +cfpkt_destroy (pkt); +return -EPROTO ; + } len -=2 ; + }if (cfpkt_setlen (pkt, len) <0 ) { ++cffrml_rcv_error;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 178/451 net/sched: ets: Remove drr class from the active list if it changes to strict
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victor Nogueira <[email protected]>
[ Upstream commit b1e125ae425aba9b45252e933ca8df52a843ec70 ]
Whenever a user issues an ets qdisc change command, transforming a drr class into a strict one, the ets code isn't checking whether that class was in the active list and removing it. This means that, if a user changes a strict class (which was in the active list) back to a drr one, that class will be added twice to the active list [1].
Doing so with the following commands:
tc qdisc add dev lo root handle 1: ets bands 2 strict 1 tc qdisc add dev lo parent 1:2 handle 20: \
tbf rate 8bit burst 100b latency 1s
tc filter add dev lo parent 1: basic classid 1:2 ping -c1 -W0.01 -s 56 127.0.0.1
tc qdisc change dev lo root handle 1: ets bands 2 strict 2 tc qdisc change dev lo root handle 1: ets bands 2 strict 1 ping -c1 -W0.01 -s 56 127.0.0.1
Will trigger the following splat with list debug turned on:
[ 59.279014][ T365] ------------[ cut here ]------------ [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0. [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220 [ 59.280860][ T365] Modules linked in: [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary) [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220 [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44 ... [ 59.288812][ T365] Call Trace: [ 59.289056][ T365] <TASK> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80 [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0 [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10 [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240 [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10 [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110 [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5 [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0
Fix this by always checking and removing an ets class from the active list when changing it to strict.
--- net/sched/sch_ets.c | 4 ++++ 1 file changed, 4 insertions(+)
net/sched/sch_ets.c +4 -0
@@ -677,6 +677,10 @@ static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, q->classes[i].deficit = quanta[i]; } } +for (i = q->nstrict; i < nstrict; i++) { +if (cl_is_active (&q->classes[i])) +list_del_init (&q->classes[i].alist); + }WRITE_ONCE (q->nstrict, nstrict);memcpy (q->prio2band, priomap,sizeof (priomap));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 179/451 nfc: pn533: Fix error code in pn533_acr122_poweron_rdr()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 885bebac9909994050bbbeed0829c727e42bd1b7 ]
Set the error code if "transferred != sizeof(cmd)" instead of returning success.
--- drivers/nfc/pn533/usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/nfc/pn533/usb.c +1 -1
@@ -411,7 +411,7 @@ static int pn533_acr122_poweron_rdr(struct pn533_usb_phy *phy)if (rc || (transferred !=sizeof (cmd))) {nfc_err (&phy->udev->dev,"Reader power on cmd error %d\n" , rc); -return rc; +return rc ?: -EINVAL ; } rc =usb_submit_urb (phy->in_urb,GFP_KERNEL );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 180/451 ethtool: use phydev variable
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Rix <[email protected]>
[ Upstream commit ccd21ec5b8dd9b8a528a70315cee95fc1dd79d20 ]
In ethtool_get_phy_stats(), the phydev varaible is set to dev->phydev but dev->phydev is still used. Replace dev->phydev uses with phydev.
Stable-dep-of: 7b07be1ff1cb ("ethtool: Avoid overflowing userspace buffer on stats query")
--- net/ethtool/ioctl.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/ethtool/ioctl.c +4 -4
@@ -2046,9 +2046,9 @@ static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)if (!phydev && (!ops->get_ethtool_phy_stats || !ops->get_sset_count))return -EOPNOTSUPP ; -if (dev->phydev && !ops->get_ethtool_phy_stats && +if (phydev && !ops->get_ethtool_phy_stats && phy_ops && phy_ops->get_sset_count) - n_stats = phy_ops->get_sset_count (dev->phydev); + n_stats = phy_ops->get_sset_count (phydev);else n_stats = ops->get_sset_count (dev,ETH_SS_PHY_STATS );if (n_stats <0 )
@@ -2068,9 +2068,9 @@ static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)if (!data)return -ENOMEM ; -if (dev->phydev && !ops->get_ethtool_phy_stats && +if (phydev && !ops->get_ethtool_phy_stats && phy_ops && phy_ops->get_stats) { - ret = phy_ops->get_stats (dev->phydev, &stats, data); + ret = phy_ops->get_stats (phydev, &stats, data);if (ret <0 ) goto out; }else {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 181/451 net/ethtool/ioctl: remove if n_stats checks from ethtool_get_phy_stats
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniil Tatianin <[email protected]>
[ Upstream commit fd4778581d61d8848b532f8cdc9b325138748437 ]
Now that we always early return if we don't have any stats we can remove these checks as they're no longer necessary.
Stable-dep-of: 7b07be1ff1cb ("ethtool: Avoid overflowing userspace buffer on stats query")
--- net/ethtool/ioctl.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)
net/ethtool/ioctl.c +10 -14
@@ -2063,28 +2063,24 @@ static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr) stats.n_stats = n_stats; -if (n_stats) { - data =vzalloc (array_size (n_stats,sizeof (u64))); -if (!data) -return -ENOMEM ; + data =vzalloc (array_size (n_stats,sizeof (u64))); +if (!data) +return -ENOMEM ; -if (phydev && !ops->get_ethtool_phy_stats && - phy_ops && phy_ops->get_stats) { - ret = phy_ops->get_stats (phydev, &stats, data); -if (ret <0 ) - goto out; - }else { - ops->get_ethtool_phy_stats (dev, &stats, data); - } +if (phydev && !ops->get_ethtool_phy_stats && + phy_ops && phy_ops->get_stats) { + ret = phy_ops->get_stats (phydev, &stats, data); +if (ret <0 ) + goto out; }else { - data =NULL ; + ops->get_ethtool_phy_stats (dev, &stats, data); } ret = -EFAULT ;if (copy_to_user (useraddr, &stats,sizeof (stats))) goto out; useraddr +=sizeof (stats); -if (n_stats &©_to_user (useraddr, data,array_size (n_stats,sizeof (u64)))) +if (copy_to_user (useraddr, data,array_size (n_stats,sizeof (u64)))) goto out; ret =0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 182/451 net/ethtool/ioctl: split ethtool_get_phy_stats into multiple helpers
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniil Tatianin <[email protected]>
[ Upstream commit 201ed315f9676809cd5b20a39206e964106d4f27 ]
So that it's easier to follow and make sense of the branching and various conditions.
Stats retrieval has been split into two separate functions ethtool_get_phy_stats_phydev & ethtool_get_phy_stats_ethtool. The former attempts to retrieve the stats using phydev & phy_ops, while the latter uses ethtool_ops.
Actual n_stats validation & array allocation has been moved into a new ethtool_vzalloc_stats_array helper.
This also fixes a potential NULL dereference of ops->get_ethtool_phy_stats where it was getting called in an else branch unconditionally without making sure it was actually present.
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
Stable-dep-of: 7b07be1ff1cb ("ethtool: Avoid overflowing userspace buffer on stats query")
--- net/ethtool/ioctl.c | 102 ++++++++++++++++++++++++++++++-------------- 1 file changed, 69 insertions(+), 33 deletions(-)
net/ethtool/ioctl.c +69 -33
@@ -2034,23 +2034,8 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)return ret; } -static int ethtool_get_phy_stats (struct net_device *dev,void __user *useraddr) +static int ethtool_vzalloc_stats_array (int n_stats,u64 **data) { -const struct ethtool_phy_ops *phy_ops = ethtool_phy_ops; -const struct ethtool_ops *ops = dev->ethtool_ops; -struct phy_device *phydev = dev->phydev; -struct ethtool_stats stats; -u64 *data; -int ret, n_stats; - -if (!phydev && (!ops->get_ethtool_phy_stats || !ops->get_sset_count)) -return -EOPNOTSUPP ; - -if (phydev && !ops->get_ethtool_phy_stats && - phy_ops && phy_ops->get_sset_count) - n_stats = phy_ops->get_sset_count (phydev); -else - n_stats = ops->get_sset_count (dev,ETH_SS_PHY_STATS );if (n_stats <0 )return n_stats;if (n_stats >S32_MAX /sizeof (u64))
@@ -2058,31 +2043,82 @@ static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)if (WARN_ON_ONCE (!n_stats))return -EOPNOTSUPP ; + *data =vzalloc (array_size (n_stats,sizeof (u64))); +if (!*data) +return -ENOMEM ; + +return 0 ; +} + +static int ethtool_get_phy_stats_phydev (struct phy_device *phydev, +struct ethtool_stats *stats, +u64 **data) + { +const struct ethtool_phy_ops *phy_ops = ethtool_phy_ops; +int n_stats, ret; + +if (!phy_ops || !phy_ops->get_sset_count || !phy_ops->get_stats) +return -EOPNOTSUPP ; + + n_stats = phy_ops->get_sset_count (phydev); + + ret =ethtool_vzalloc_stats_array (n_stats, data); +if (ret) +return ret; + + stats->n_stats = n_stats; +return phy_ops->get_stats (phydev, stats, *data); +} + +static int ethtool_get_phy_stats_ethtool (struct net_device *dev, +struct ethtool_stats *stats, +u64 **data) +{ +const struct ethtool_ops *ops = dev->ethtool_ops; +int n_stats, ret; + +if (!ops || !ops->get_sset_count || ops->get_ethtool_phy_stats) +return -EOPNOTSUPP ; + + n_stats = ops->get_sset_count (dev,ETH_SS_PHY_STATS ); + + ret =ethtool_vzalloc_stats_array (n_stats, data); +if (ret) +return ret; + + stats->n_stats = n_stats; + ops->get_ethtool_phy_stats (dev, stats, *data); + +return 0 ; +} + +static int ethtool_get_phy_stats (struct net_device *dev,void __user *useraddr) +{ +struct phy_device *phydev = dev->phydev; +struct ethtool_stats stats; +u64 *data =NULL ; +int ret = -EOPNOTSUPP ; +if (copy_from_user (&stats, useraddr,sizeof (stats)))return -EFAULT ; - stats.n_stats = n_stats; +if (phydev) + ret =ethtool_get_phy_stats_phydev (phydev, &stats, &data); - data =vzalloc (array_size (n_stats,sizeof (u64))); -if (!data) -return -ENOMEM ; +if (ret == -EOPNOTSUPP ) + ret =ethtool_get_phy_stats_ethtool (dev, &stats, &data); -if (phydev && !ops->get_ethtool_phy_stats && - phy_ops && phy_ops->get_stats) { - ret = phy_ops->get_stats (phydev, &stats, data); -if (ret <0 ) - goto out; - }else { - ops->get_ethtool_phy_stats (dev, &stats, data); - } +if (ret) + goto out; - ret = -EFAULT ; -if (copy_to_user (useraddr, &stats,sizeof (stats))) +if (copy_to_user (useraddr, &stats,sizeof (stats))) { + ret = -EFAULT ; goto out; + } + useraddr +=sizeof (stats); -if (copy_to_user (useraddr, data,array_size (n_stats,sizeof (u64)))) - goto out; - ret =0 ; +if (copy_to_user (useraddr, data,array_size (stats.n_stats,sizeof (u64)))) + ret = -EFAULT ; out:vfree (data);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 183/451 ethtool: Avoid overflowing userspace buffer on stats query
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <[email protected]>
[ Upstream commit 7b07be1ff1cb6c49869910518650e8d0abc7d25f ]
The ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and ETHTOOL_GSTATS for the values.
If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.
Drivers are generally expected to maintain stable stat counts, but some drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making this scenario possible.
Some drivers try to handle this internally:
- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.
- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.
However, both use stats.n_stats which is already assigned with the value returned from get_sset_count(), hence won't solve the issue described here.
Change ethtool_get_strings(), ethtool_get_stats(), ethtool_get_phy_stats() to not return anything in case of a mismatch between userspace's size and get_sset_size(), to prevent buffer overflow.
The returned n_stats value will be equal to zero, to reflect that nothing has been returned.
This could result in one of two cases when using upstream ethtool, depending on when the size change is detected:
1. When detected in ethtool_get_strings():
# ethtool -S eth2
no stats available2. When detected in get stats, all stats will be reported as zero.
Both cases are presumably transient, and a subsequent ethtool call should succeed.
Other than the overflow avoidance, these two cases are very evident (no output/cleared stats), which is arguably better than presenting incorrect/shifted stats.
I also considered returning an error instead of a "silent" response, but that seems more destructive towards userspace apps.
Notes:
- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.
- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.
- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
--- net/ethtool/ioctl.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-)
net/ethtool/ioctl.c +24 -6
@@ -1909,7 +1909,10 @@ static int ethtool_get_strings(struct net_device *dev, void __user *useraddr)return -ENOMEM ;WARN_ON_ONCE (!ret); - gstrings.len = ret; +if (gstrings.len && gstrings.len != ret) + gstrings.len =0 ; +else + gstrings.len = ret;if (gstrings.len) { data =vzalloc (array_size (gstrings.len,ETH_GSTRING_LEN ));
@@ -2010,10 +2013,13 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)if (copy_from_user (&stats, useraddr,sizeof (stats)))return -EFAULT ; - stats.n_stats = n_stats; +if (stats.n_stats && stats.n_stats != n_stats) + stats.n_stats =0 ; +else + stats.n_stats = n_stats; -if (n_stats) { - data =vzalloc (array_size (n_stats,sizeof (u64))); +if (stats.n_stats) { + data =vzalloc (array_size (stats.n_stats,sizeof (u64)));if (!data)return -ENOMEM ; ops->get_ethtool_stats (dev, &stats, data);
@@ -2025,7 +2031,9 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)if (copy_to_user (useraddr, &stats,sizeof (stats))) goto out; useraddr +=sizeof (stats); -if (n_stats &©_to_user (useraddr, data,array_size (n_stats,sizeof (u64)))) +if (stats.n_stats && +copy_to_user (useraddr, data, +array_size (stats.n_stats,sizeof (u64)))) goto out; ret =0 ;
@@ -2061,6 +2069,10 @@ static int ethtool_get_phy_stats_phydev(struct phy_device *phydev,return -EOPNOTSUPP ; n_stats = phy_ops->get_sset_count (phydev); +if (stats->n_stats && stats->n_stats != n_stats) { + stats->n_stats =0 ; +return 0 ; + } ret =ethtool_vzalloc_stats_array (n_stats, data);if (ret)
@@ -2081,6 +2093,10 @@ static int ethtool_get_phy_stats_ethtool(struct net_device *dev,return -EOPNOTSUPP ; n_stats = ops->get_sset_count (dev,ETH_SS_PHY_STATS ); +if (stats->n_stats && stats->n_stats != n_stats) { + stats->n_stats =0 ; +return 0 ; + } ret =ethtool_vzalloc_stats_array (n_stats, data);if (ret)
@@ -2117,7 +2133,9 @@ static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr) } useraddr +=sizeof (stats); -if (copy_to_user (useraddr, data,array_size (stats.n_stats,sizeof (u64)))) +if (stats.n_stats && +copy_to_user (useraddr, data, +array_size (stats.n_stats,sizeof (u64)))) ret = -EFAULT ; out:
Signature · 1 line
2.51.0
Re: [PATCH 5.10 183/451] ethtool: Avoid overflowing userspace buffer on stats query
Quoted 8 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <[email protected]>
[ Upstream commit
7b07be1ff1cb6c49869910518650e8d0abc7d25f]
Quoted 7 lines
The ethtool -S command operates across three ioctl calls:
ETHTOOL_GSSET_INFOfor the size,ETHTOOL_GSTRINGSfor the names, andETHTOOL_GSTATSfor the values.If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.
[...]
This seems like it could cause a regression for the DPDK driver for mlx5, which sets ethtool_stats::n_stats to a "maximum" value:
https://sources.debian.org/src/dpdk/25.11-2/drivers/net/mlx5/linux/mlx5_ethdev_os.c?hl=1324#L1324
Everything else I could find with Debian codesearch does seem to initialise ethtool_gstrings::len and ethtool_stats::n_stats as you expect, though.
This change should be documented in include/uapi/linux/ethtool.h, which currently specifies these fields as output only.
Ben.
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesRe: [PATCH 5.10 183/451] ethtool: Avoid overflowing userspace buffer on stats query
Quoted 13 lines · Ben Hutchings
Quoted 12 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <[email protected]>
[ Upstream commit
7b07be1ff1cb6c49869910518650e8d0abc7d25f]The ethtool -S command operates across three ioctl calls:
ETHTOOL_GSSET_INFOfor the size,ETHTOOL_GSTRINGSfor the names, andETHTOOL_GSTATSfor the values.
Quoted 8 lines
Quoted 3 lines
If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.
[...]
This seems like it could cause a regression for the DPDK driver for mlx5, which sets
ethtool_stats::n_statsto a "maximum" value:
https://sources.debian.org/src/dpdk/25.11-2/drivers/net/mlx5/linux/mlx5_ethdev_os.c?hl=1324#L1324
The maximum value is actually the number of stats returned by the driver (see mlx5_os_get_stats_n()). I also verified my change with the DPDK team.
Quoted 7 lines
Everything else I could find with Debian codesearch does seem to initialise
ethtool_gstrings::lenandethtool_stats::n_statsas you expect, though.This change should be documented in
include/uapi/linux/ethtool.h, which currently specifies these fields as output only.
Re: [PATCH 5.10 183/451] ethtool: Avoid overflowing userspace buffer on stats query
Quoted 1 line · Gal Pressman
On 17/01/2026 21:58, Ben Hutchings wrote:
[...]
Quoted 9 lines
Quoted 6 lines
Everything else I could find with Debian codesearch does seem to initialise
ethtool_gstrings::lenandethtool_stats::n_statsas you expect, though.This change should be documented in
include/uapi/linux/ethtool.h, which currently specifies these fields as output only.
Thank you. Please add:
so that the documentation update will also get into the stable kernel branches.
Ben.
Signature · 2 lines
Ben Hutchings Larkinson's Law: All laws are basically false.
Re: [PATCH 5.10 183/451] ethtool: Avoid overflowing userspace buffer on stats query
Quoted 13 lines · Ben Hutchings
Quoted 1 line · Gal Pressman
On 17/01/2026 21:58, Ben Hutchings wrote:
[...]
Quoted 9 lines
Quoted 6 lines
Everything else I could find with Debian codesearch does seem to initialise
ethtool_gstrings::lenandethtool_stats::n_statsas you expect, though.This change should be documented in
include/uapi/linux/ethtool.h, which currently specifies these fields as output only.
Quoted 6 lines
Thank you. Please add:
Fixes 7b07be1ff1cb ("ethtool: Avoid overflowing userspace buffer on stats query")so that the documentation update will also get into the stable kernel branches.
Sorry, this was merged already..
Greg Kroah-Hartman
maintainerPATCH 184/451 net/mlx5: fw_tracer, Add support for unrecognized string
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shay Drory <[email protected]>
[ Upstream commit f7133135235dbd11e7cb5fe62fe5d05ce5e82eeb ]
In case FW is publishing a string which isn't found in the driver's string DBs, keep the string as raw data.
Stable-dep-of: b35966042d20 ("net/mlx5: fw_tracer, Validate format string parameters")
--- .../mellanox/mlx5/core/diag/fw_tracer.c | 25 +++++++++++++++++-- .../mellanox/mlx5/core/diag/fw_tracer.h | 1 + 2 files changed, 24 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c +23 -2
@@ -460,6 +460,7 @@ static void poll_trace(struct mlx5_fw_tracer *tracer, tracer_event->event_id =MLX5_GET (tracer_event, trace, event_id); tracer_event->lost_event =MLX5_GET (tracer_event, trace, lost); + tracer_event->out = trace;switch (tracer_event->event_id) {case TRACER_EVENT_TYPE_TIMESTAMP :
@@ -582,6 +583,26 @@ void mlx5_tracer_print_trace(struct tracer_string_format *str_frmt,mlx5_tracer_clean_message (str_frmt); } +static int mlx5_tracer_handle_raw_string (struct mlx5_fw_tracer *tracer, +struct tracer_event *tracer_event) +{ +struct tracer_string_format *cur_string; + + cur_string =mlx5_tracer_message_insert (tracer, tracer_event); +if (!cur_string) +return -1 ; + + cur_string->event_id = tracer_event->event_id; + cur_string->timestamp = tracer_event->string_event.timestamp; + cur_string->lost = tracer_event->lost_event; + cur_string->string ="0x%08x%08x" ; + cur_string->num_of_params =2 ; + cur_string->params[0 ] =upper_32_bits (*tracer_event->out); + cur_string->params[1 ] =lower_32_bits (*tracer_event->out); +list_add_tail (&cur_string->list, &tracer->ready_strings_list); +return 0 ; +} +static int mlx5_tracer_handle_string_trace (struct mlx5_fw_tracer *tracer,struct tracer_event *tracer_event) {
@@ -590,7 +611,7 @@ static int mlx5_tracer_handle_string_trace(struct mlx5_fw_tracer *tracer,if (tracer_event->string_event.tdsn ==0 ) { cur_string =mlx5_tracer_get_string (tracer, tracer_event);if (!cur_string) -return -1 ; +return mlx5_tracer_handle_raw_string (tracer, tracer_event); cur_string->num_of_params =mlx5_tracer_get_num_of_params (cur_string->string); cur_string->last_param_num =0 ;
@@ -605,7 +626,7 @@ static int mlx5_tracer_handle_string_trace(struct mlx5_fw_tracer *tracer,if (!cur_string) {pr_debug ("%s Got string event for unknown string tmsn: %d\n" , __func__, tracer_event->string_event.tmsn); -return -1 ; +return mlx5_tracer_handle_raw_string (tracer, tracer_event); } cur_string->last_param_num +=1 ;if (cur_string->last_param_num >TRACER_MAX_PARAMS ) {
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h +1 -0
@@ -158,6 +158,7 @@ struct tracer_event {struct tracer_string_event string_event;struct tracer_timestamp_event timestamp_event; }; +u64 *out; };struct mlx5_ifc_tracer_event_bits {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 185/451 net/mlx5: fw_tracer, Validate format string parameters
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shay Drory <[email protected]>
[ Upstream commit b35966042d20b14e2d83330049f77deec5229749 ]
Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.
The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.
Add mlx5_tracer_validate_params() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BAD_FORMAT: " prefix.
--- .../mellanox/mlx5/core/diag/fw_tracer.c | 83 ++++++++++++++++--- .../mellanox/mlx5/core/diag/fw_tracer.h | 1 + 2 files changed, 74 insertions(+), 10 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c +73 -10
@@ -33,6 +33,7 @@#include "lib/eq.h" #include "fw_tracer.h" #include "fw_tracer_tracepoint.h" +#include <linux/ctype.h> static int mlx5_query_mtrc_caps (struct mlx5_fw_tracer *tracer) {
@@ -354,6 +355,43 @@ static const char *VAL_PARM = "%llx";static const char *REPLACE_64_VAL_PARM ="%x%x" ;static const char *PARAM_CHAR ="%" ; +static bool mlx5_is_valid_spec (const char *str) +{ +/* Parse format specifiers to find the actual type. +* Structure: %[flags][width][.precision][length]type +* Skip flags, width, precision & length. +*/ +while (isdigit (*str) || *str =='#' || *str =='.' || *str =='l' ) + str++; + +/* Check if it's a valid integer/hex specifier: +* Valid formats: %x, %d, %i, %u, etc. +*/ +if (*str !='x' && *str !='X' && *str !='d' && *str !='i' && + *str !='u' && *str !='c' ) +return false; + +return true; +} + +static bool mlx5_tracer_validate_params (const char *str) +{ +const char *substr = str; + +if (!str) +return false; + + substr =strstr (substr,PARAM_CHAR ); +while (substr) { +if (!mlx5_is_valid_spec (substr +1 )) +return false; + + substr =strstr (substr +1 ,PARAM_CHAR ); + } + +return true; +} +static int mlx5_tracer_message_hash (u32 message_id) {return jhash_1word (message_id,0 ) & (MESSAGE_HASH_SIZE -1 );
@@ -413,6 +451,10 @@ static int mlx5_tracer_get_num_of_params(char *str)char *substr, *pstr = str;int num_of_params =0 ; +/* Validate that all parameters are valid before processing */ +if (!mlx5_tracer_validate_params (str)) +return -EINVAL ; +/* replace %llx with %x%x */ substr =strstr (pstr,VAL_PARM );while (substr) {
@@ -564,14 +606,17 @@ void mlx5_tracer_print_trace(struct tracer_string_format *str_frmt, {char tmp[512 ]; -snprintf (tmp,sizeof (tmp), str_frmt->string, - str_frmt->params[0 ], - str_frmt->params[1 ], - str_frmt->params[2 ], - str_frmt->params[3 ], - str_frmt->params[4 ], - str_frmt->params[5 ], - str_frmt->params[6 ]); +if (str_frmt->invalid_string) +snprintf (tmp,sizeof (tmp),"BAD_FORMAT: %s" , str_frmt->string); +else +snprintf (tmp,sizeof (tmp), str_frmt->string, + str_frmt->params[0 ], + str_frmt->params[1 ], + str_frmt->params[2 ], + str_frmt->params[3 ], + str_frmt->params[4 ], + str_frmt->params[5 ], + str_frmt->params[6 ]);trace_mlx5_fw (dev->tracer, trace_timestamp, str_frmt->lost, str_frmt->event_id, tmp);
@@ -603,6 +648,13 @@ static int mlx5_tracer_handle_raw_string(struct mlx5_fw_tracer *tracer,return 0 ; } +static void mlx5_tracer_handle_bad_format_string (struct mlx5_fw_tracer *tracer, +struct tracer_string_format *cur_string) +{ + cur_string->invalid_string = true; +list_add_tail (&cur_string->list, &tracer->ready_strings_list); +} +static int mlx5_tracer_handle_string_trace (struct mlx5_fw_tracer *tracer,struct tracer_event *tracer_event) {
@@ -613,12 +665,18 @@ static int mlx5_tracer_handle_string_trace(struct mlx5_fw_tracer *tracer,if (!cur_string)return mlx5_tracer_handle_raw_string (tracer, tracer_event); - cur_string->num_of_params =mlx5_tracer_get_num_of_params (cur_string->string); - cur_string->last_param_num =0 ; cur_string->event_id = tracer_event->event_id; cur_string->tmsn = tracer_event->string_event.tmsn; cur_string->timestamp = tracer_event->string_event.timestamp; cur_string->lost = tracer_event->lost_event; + cur_string->last_param_num =0 ; + cur_string->num_of_params =mlx5_tracer_get_num_of_params (cur_string->string); +if (cur_string->num_of_params <0 ) { +pr_debug ("%s Invalid format string parameters\n" , + __func__); +mlx5_tracer_handle_bad_format_string (tracer, cur_string); +return 0 ; + }if (cur_string->num_of_params ==0 )/* trace with no params */ list_add_tail (&cur_string->list, &tracer->ready_strings_list); }else {
@@ -628,6 +686,11 @@ static int mlx5_tracer_handle_string_trace(struct mlx5_fw_tracer *tracer, __func__, tracer_event->string_event.tmsn);return mlx5_tracer_handle_raw_string (tracer, tracer_event); } +if (cur_string->num_of_params <0 ) { +pr_debug ("%s string parameter of invalid string, dumping\n" , + __func__); +return 0 ; + } cur_string->last_param_num +=1 ;if (cur_string->last_param_num >TRACER_MAX_PARAMS ) { pr_debug("%s Number of params exceeds the max (%d)\n",
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h +1 -0
@@ -117,6 +117,7 @@ struct tracer_string_format {struct list_head list;u32 timestamp;bool lost; +bool invalid_string; };enum mlx5_fw_tracer_ownership_state {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 186/451 net/mlx5: fw_tracer, Handle escaped percent properly
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shay Drory <[email protected]>
[ Upstream commit c0289f67f7d6a0dfba0e92cfe661a5c70c8c6e92 ]
The firmware tracer's format string validation and parameter counting did not properly handle escaped percent signs (%%). This caused fw_tracer to count more parameters when trace format strings contained literal percent characters.
To fix it, allow %% to pass string validation and skip %% sequences when counting parameters since they represent literal percent signs rather than format specifiers.
--- .../mellanox/mlx5/core/diag/fw_tracer.c | 20 +++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c +14 -6
@@ -364,11 +364,11 @@ static bool mlx5_is_valid_spec(const char *str)while (isdigit (*str) || *str =='#' || *str =='.' || *str =='l' ) str++; -/* Check if it's a valid integer/hex specifier: +/* Check if it's a valid integer/hex specifier or %%: * Valid formats: %x, %d, %i, %u, etc. */ if (*str !='x' && *str !='X' && *str !='d' && *str !='i' && - *str !='u' && *str !='c' ) + *str !='u' && *str !='c' && *str !='%' )return false;return true;
@@ -386,7 +386,11 @@ static bool mlx5_tracer_validate_params(const char *str)if (!mlx5_is_valid_spec (substr +1 ))return false; - substr =strstr (substr +1 ,PARAM_CHAR ); +if (*(substr +1 ) =='%' ) + substr =strstr (substr +2 ,PARAM_CHAR ); +else + substr =strstr (substr +1 ,PARAM_CHAR ); + }return true;
@@ -463,11 +467,15 @@ static int mlx5_tracer_get_num_of_params(char *str) substr =strstr (pstr,VAL_PARM ); } -/* count all the % characters */ +/* count all the % characters, but skip %% (escaped percent) */ substr =strstr (str,PARAM_CHAR );while (substr) { - num_of_params +=1 ; - str = substr +1 ; +if (*(substr +1 ) !='%' ) { + num_of_params +=1 ; + str = substr +1 ; + }else { + str = substr +2 ; + } substr =strstr (str,PARAM_CHAR ); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 187/451 net: hns3: using the num_tqps in the vf driver to apply for resources
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jian Shen <[email protected]>
[ Upstream commit c2a16269742e176fccdd0ef9c016a233491a49ad ]
Currently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp is allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to min(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smaller than hdev->num_tqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevf_knic_setup().
Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.
--- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +2 -2
@@ -434,12 +434,12 @@ static int hclgevf_knic_setup(struct hclgevf_dev *hdev) new_tqps = kinfo->rss_size * num_tc; kinfo->num_tqps =min (new_tqps, hdev->num_tqps); - kinfo->tqp =devm_kcalloc (&hdev->pdev->dev, kinfo->num_tqps, + kinfo->tqp =devm_kcalloc (&hdev->pdev->dev, hdev->num_tqps,sizeof (struct hnae3_queue *),GFP_KERNEL );if (!kinfo->tqp)return -ENOMEM ; -for (i =0 ; i < kinfo->num_tqps; i++) { +for (i =0 ; i < hdev->num_tqps; i++) { hdev->htqp[i].q.handle = &hdev->nic; hdev->htqp[i].q.tqp_index = i; kinfo->tqp[i] = &hdev->htqp[i].q;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 188/451 net: hns3: add VLAN id validation before using
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jian Shen <[email protected]>
[ Upstream commit 6ef935e65902bfed53980ad2754b06a284ea8ac1 ]
Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID.
Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.
--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +3 -0
@@ -9196,6 +9196,9 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,bool writen_to_tbl = false;int ret =0 ; +if (vlan_id >=VLAN_N_VID ) +return -EINVAL ; +/* When device is resetting or reset failed, firmware is unable to * handle mailbox. Just record the vlan id, and remove it after * reset finished.
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 189/451 hwmon: (ibmpex) fix use-after-free in high/low store
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
[ Upstream commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d ]
The ibmpex_high_low_store() function retrieves driver data using dev_get_drvdata() and uses it without validation. This creates a race condition where the sysfs callback can be invoked after the data structure is freed, leading to use-after-free.
Fix by adding a NULL check after dev_get_drvdata(), and reordering operations in the deletion path to prevent TOCTOU.
--- drivers/hwmon/ibmpex.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/hwmon/ibmpex.c +7 -2
@@ -282,6 +282,9 @@ static ssize_t ibmpex_high_low_store(struct device *dev, {struct ibmpex_bmc_data *data =dev_get_drvdata (dev); +if (!data) +return -ENODEV ; +ibmpex_reset_high_low_data (data);return count;
@@ -514,6 +517,9 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) {int i, j; +hwmon_device_unregister (data->hwmon_dev); +dev_set_drvdata (data->bmc_device,NULL ); +device_remove_file (data->bmc_device, &sensor_dev_attr_reset_high_low.dev_attr);device_remove_file (data->bmc_device, &sensor_dev_attr_name.dev_attr);
@@ -527,8 +533,7 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) }list_del (&data->list); -dev_set_drvdata (data->bmc_device,NULL ); -hwmon_device_unregister (data->hwmon_dev); +ipmi_destroy_user (data->user);kfree (data->sensors);kfree (data);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 190/451 MIPS: Fix a reference leak bug in ip22_check_gio()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
[ Upstream commit 680ad315caaa2860df411cb378bf3614d96c7648 ]
If gio_device_register fails, gio_dev_put() is required to drop the gio_dev device reference.
--- arch/mips/sgi-ip22/ip22-gio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/mips/sgi-ip22/ip22-gio.c +2 -1
@@ -372,7 +372,8 @@ static void ip22_check_gio(int slotno, unsigned long addr, int irq) gio_dev->resource.flags =IORESOURCE_MEM ; gio_dev->irq = irq;dev_set_name (&gio_dev->dev,"%d" , slotno); -gio_device_register (gio_dev); +if (gio_device_register (gio_dev)) +gio_dev_put (gio_dev); }else printk (KERN_INFO "GIO: slot %d : Empty\n" , slotno); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 191/451 block/rnbd: Remove a useless mutex
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 24afc15dbe218f860994f627b4ba1fb09225a298 ]
According to lib/idr.c,
The IDA handles its own locking. It is safe to call any of the IDA functions without synchronisation in your code.
so the 'ida_lock' mutex can just be removed.
It is here only to protect some ida_simple_get()/ida_simple_remove() calls.
While at it, switch to ida_alloc_XXX()/ida_free() instead to ida_simple_get()/ida_simple_remove().
The latter is deprecated and more verbose.
Stable-dep-of: c9b5645fd8ca ("block: rnbd-clt: Fix leaked ID in init_dev()")
--- drivers/block/rnbd/rnbd-clt.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
drivers/block/rnbd/rnbd-clt.c +3 -8
@@ -23,7 +23,6 @@ MODULE_LICENSE("GPL");static int rnbd_client_major;static DEFINE_IDA (index_ida); -static DEFINE_MUTEX (ida_lock);static DEFINE_MUTEX (sess_lock);static LIST_HEAD (sess_list);
@@ -55,9 +54,7 @@ static void rnbd_clt_put_dev(struct rnbd_clt_dev *dev)if (!refcount_dec_and_test (&dev->refcount))return ; -mutex_lock (&ida_lock); -ida_simple_remove (&index_ida, dev->clt_device_id); -mutex_unlock (&ida_lock); +ida_free (&index_ida, dev->clt_device_id);kfree (dev->hw_queues);kfree (dev->pathname);rnbd_clt_put_sess (dev->sess);
@@ -1381,10 +1378,8 @@ static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess, goto out_alloc; } -mutex_lock (&ida_lock); - ret =ida_simple_get (&index_ida,0 ,1 << (MINORBITS -RNBD_PART_BITS ), -GFP_KERNEL ); -mutex_unlock (&ida_lock); + ret =ida_alloc_max (&index_ida,1 << (MINORBITS -RNBD_PART_BITS ), +GFP_KERNEL );if (ret <0 ) {pr_err ("Failed to initialize device '%s' from session %s, allocating idr failed, err: %d\n" , pathname, sess->sessname, ret);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 192/451 block/rnbd-clt: fix wrong max ID in ida_alloc_max
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guoqing Jiang <[email protected]>
[ Upstream commit 9d6033e350694a67885605674244d43c9559dc36 ]
We need to pass 'end - 1' to ida_alloc_max after switch from ida_simple_get to ida_alloc_max.
Otherwise smatch warns.
drivers/block/rnbd/rnbd-clt.c:1460 init_dev() error: Calling ida_alloc_max() with a 'max' argument which is a power of 2. -1 missing?
Stable-dep-of: c9b5645fd8ca ("block: rnbd-clt: Fix leaked ID in init_dev()")
--- drivers/block/rnbd/rnbd-clt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/block/rnbd/rnbd-clt.c +1 -1
@@ -1378,7 +1378,7 @@ static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess, goto out_alloc; } - ret =ida_alloc_max (&index_ida,1 << (MINORBITS -RNBD_PART_BITS ), + ret =ida_alloc_max (&index_ida, (1 << (MINORBITS -RNBD_PART_BITS )) -1 ,GFP_KERNEL );if (ret <0 ) { pr_err("Failed to initialize device '%s' from session %s, allocating idr failed, err: %d\n",
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 193/451 block: rnbd-clt: Fix leaked ID in init_dev()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit c9b5645fd8ca10f310e41b07540f98e6a9720f40 ]
If kstrdup() fails in init_dev(), then the newly allocated ID is lost.
--- drivers/block/rnbd/rnbd-clt.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/block/rnbd/rnbd-clt.c +8 -5
@@ -1378,9 +1378,11 @@ static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess, goto out_alloc; } - ret =ida_alloc_max (&index_ida, (1 << (MINORBITS -RNBD_PART_BITS )) -1 , -GFP_KERNEL ); -if (ret <0 ) { + dev->clt_device_id =ida_alloc_max (&index_ida, + (1 << (MINORBITS -RNBD_PART_BITS )) -1 , +GFP_KERNEL ); +if (dev->clt_device_id <0 ) { + ret = dev->clt_device_id;pr_err ("Failed to initialize device '%s' from session %s, allocating idr failed, err: %d\n" , pathname, sess->sessname, ret); goto out_queues;
@@ -1389,10 +1391,9 @@ static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess, dev->pathname =kstrdup (pathname,GFP_KERNEL );if (!dev->pathname) { ret = -ENOMEM ; - goto out_queues; + goto out_ida; } - dev->clt_device_id = ret; dev->sess = sess; dev->access_mode = access_mode;mutex_init (&dev->lock);
@@ -1407,6 +1408,8 @@ static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess,return dev; +out_ida: +ida_free (&index_ida, dev->clt_device_id); out_queues:kfree (dev->hw_queues); out_alloc:
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 194/451 HID: input: map HID_GD_Z to ABS_DISTANCE for stylus/pen
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ping Cheng <[email protected]>
commit 7953794f741e94d30df9dafaaa4c031c85b891d6 upstream.
HID_GD_Z is mapped to ABS_Z for stylus and pen in hid-input.c. But HID_GD_Z should be used to report ABS_DISTANCE for stylus and pen as described at:
Documentation/input/event-codes.rst#n226
* ABS_DISTANCE:
- Used to describe the distance of a tool from an interaction surface. This event should only be emitted while the tool is hovering, meaning in close proximity of the device and while the value of the BTN_TOUCH code is 0. If the input device may be used freely in three dimensions, consider ABS_Z instead.
- BTN_TOOL_<name> should be set to 1 when the tool comes into detectable proximity and set to 0 when the tool leaves detectable proximity. BTN_TOOL_<name> signals the type of tool that is currently detected by the hardware and is otherwise independent of ABS_DISTANCE and/or BTN_TOUCH.
This patch makes the correct mapping. The ABS_DISTANCE is currently not mapped by any HID usage in hid-generic driver.
--- drivers/hid/hid-input.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
drivers/hid/hid-input.c +17 -1
@@ -718,7 +718,7 @@ static void hidinput_configure_usage(strswitch (usage->hid) {/* These usage IDs map directly to the usage codes. */ -case HID_GD_X :case HID_GD_Y :case HID_GD_Z : +case HID_GD_X :case HID_GD_Y :case HID_GD_RX :case HID_GD_RY :case HID_GD_RZ :if (field->flags &HID_MAIN_ITEM_RELATIVE )map_rel (usage->hid &0xf );
@@ -726,6 +726,22 @@ static void hidinput_configure_usage(strmap_abs_clear (usage->hid &0xf );break ; +case HID_GD_Z : +/* HID_GD_Z is mapped to ABS_DISTANCE for stylus/pen */ +if (field->flags &HID_MAIN_ITEM_RELATIVE ) { +map_rel (usage->hid &0xf ); + }else { +if (field->application ==HID_DG_PEN || + field->physical ==HID_DG_PEN || + field->logical ==HID_DG_STYLUS || + field->physical ==HID_DG_STYLUS || + field->application ==HID_DG_DIGITIZER ) +map_abs_clear (ABS_DISTANCE ); +else +map_abs_clear (usage->hid &0xf ); + } +break ; +case HID_GD_WHEEL :if (field->flags &HID_MAIN_ITEM_RELATIVE ) {set_bit (REL_WHEEL , input->relbit);
Greg Kroah-Hartman
maintainerPATCH 195/451 Input: ti_am335x_tsc - fix off-by-one error in wire_order validation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junjie Cao <[email protected]>
commit 248d3a73a0167dce15ba100477c3e778c4787178 upstream.
The current validation 'wire_order[i] > ARRAY_SIZE(config_pins)' allows wire_order[i] to equal ARRAY_SIZE(config_pins), which causes out-of-bounds access when used as index in 'config_pins[wire_order[i]]'.
Since config_pins has 4 elements (indices 0-3), the valid range for wire_order should be 0-3. Fix the off-by-one error by using >= instead of > in the validation check.
--- drivers/input/touchscreen/ti_am335x_tsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/touchscreen/ti_am335x_tsc.c +1 -1
@@ -86,7 +86,7 @@ static int titsc_config_wires(struct tit wire_order[i] = ts_dev->config_inp[i] &0x0F ;if (WARN_ON (analog_line[i] >7 ))return -EINVAL ; -if (WARN_ON (wire_order[i] >ARRAY_SIZE (config_pins))) +if (WARN_ON (wire_order[i] >=ARRAY_SIZE (config_pins)))return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 196/451 Input: i8042 - add TUXEDO InfinityBook Max Gen10 AMD to i8042 quirk table
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoffer Sandberg <[email protected]>
commit aed3716db7fff74919cc5775ca3a80c8bb246489 upstream.
The device occasionally wakes up from suspend with missing input on the internal keyboard and the following suspend attempt results in an instant wake-up. The quirks fix both issues for this device.
--- drivers/input/serio/i8042-acpipnpio.h | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/input/serio/i8042-acpipnpio.h +7 -0
@@ -1169,6 +1169,13 @@ static const struct dmi_system_id i8042_ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS | SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP) }, + { + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "X5KK45xS_X5SP45xS"), + }, + .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS | + SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP) + }, /* * A lot of modern Clevo barebones have touchpad and/or keyboard issues * after suspend fixable with nomux + reset + noloop + nopnp. Luckily,
Greg Kroah-Hartman
maintainerPATCH 197/451 ACPI: CPPC: Fix missing PCC check for guaranteed_perf
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pengjie Zhang <[email protected]>
commit 6ea3a44cef28add2d93b1ef119d84886cb1e3c9b upstream.
The current implementation overlooks the 'guaranteed_perf' register in this check.
If the Guaranteed Performance register is located in the PCC subspace, the function currently attempts to read it without acquiring the lock and without sending the CMD_READ doorbell to the firmware. This can result in reading stale data.
--- drivers/acpi/cppc_acpi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/acpi/cppc_acpi.c +2 -1
@@ -1097,7 +1097,8 @@ int cppc_get_perf_caps(int cpunum, struc/* Are any of the regs PCC ?*/ if (CPC_IN_PCC (highest_reg) ||CPC_IN_PCC (lowest_reg) ||CPC_IN_PCC (lowest_non_linear_reg) ||CPC_IN_PCC (nominal_reg) || -CPC_IN_PCC (low_freq_reg) ||CPC_IN_PCC (nom_freq_reg)) { +CPC_IN_PCC (low_freq_reg) ||CPC_IN_PCC (nom_freq_reg) || +CPC_IN_PCC (guaranteed_reg)) {if (pcc_ss_id <0 ) {pr_debug ("Invalid pcc_ss_id\n" );return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 198/451 spi: fsl-cpm: Check length parity before switching to 16 bit mode
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 1417927df8049a0194933861e9b098669a95c762 upstream.
Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers with even size") failed to make sure that the size is really even before switching to 16 bit mode. Until recently the problem went unnoticed because kernfs uses a pre-allocated bounce buffer of size PAGE_SIZE for reading EEPROM.
But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API") introduced an additional dynamically allocated bounce buffer whose size is exactly the size of the transfer, leading to a buffer overrun in the fsl-cpm driver when that size is odd.
Add the missing length parity verification and remain in 8 bit mode when the length is not even.
--- drivers/spi/spi-fsl-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-fsl-spi.c +1 -1
@@ -369,7 +369,7 @@ static int fsl_spi_do_one_msg(struct spiif (t->bits_per_word ==16 || t->bits_per_word ==32 ) t->bits_per_word =8 ;/* pretend its 8 bits */ if (t->bits_per_word ==8 && t->len >=256 && - (mpc8xxx_spi->flags &SPI_CPM1 )) + !(t->len &1 ) && (mpc8xxx_spi->flags &SPI_CPM1 )) t->bits_per_word =16 ; } }
Greg Kroah-Hartman
maintainerPATCH 199/451 net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shaurya Rane <[email protected]>
commit 188e0fa5a679570ea35474575e724d8211423d17 upstream.
prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_std but doesn't check if the allocation failed. If __pskb_copy() returns NULL, skb_clone() is called with a NULL pointer, causing a crash:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041 Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207 RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480 RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000 RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000 R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00 FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0 Call Trace: <TASK> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0449f8e1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48 RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8 RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001 R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 </TASK>
Add a NULL check immediately after __pskb_copy() to handle allocation failures gracefully.
--- net/hsr/hsr_forward.c | 2 ++ 1 file changed, 2 insertions(+)
net/hsr/hsr_forward.c +2 -0
@@ -134,6 +134,8 @@ struct sk_buff *prp_get_untagged_frame(s__pskb_copy (frame->skb_prp,skb_headroom (frame->skb_prp),GFP_ATOMIC ); +if (!frame->skb_std) +return NULL ; }else {/* Unexpected */ WARN_ONCE(1, "%s:%d: Unexpected frame received (port_src %s)\n",
Greg Kroah-Hartman
maintainerPATCH 200/451 ALSA: vxpocket: Fix resource leak in vxpocket_probe error path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
[ Upstream commit 2a03b40deacbd293ac9aed0f9b11197dad54fe5f ]
When vxpocket_config() fails, vxpocket_probe() returns the error code directly without freeing the sound card resources allocated by snd_card_new(), which leads to a memory leak.
Add proper error handling to free the sound card and clear the allocation bit when vxpocket_config() fails.
--- sound/pcmcia/vx/vxpocket.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
sound/pcmcia/vx/vxpocket.c +7 -1
@@ -320,7 +320,13 @@ static int vxpocket_probe(struct pcmcia_device *p_dev) vxp->p_dev = p_dev; -return vxpocket_config (p_dev); + err =vxpocket_config (p_dev); +if (err <0 ) { + card_alloc &= ~(1 << i); +snd_card_free (card); +return err; + } +return 0 ; }static void vxpocket_detach (struct pcmcia_device *link)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 201/451 ALSA: pcmcia: Fix resource leak in snd_pdacf_probe error path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
[ Upstream commit 5032347c04ba7ff9ba878f262e075d745c06a2a8 ]
When pdacf_config() fails, snd_pdacf_probe() returns the error code directly without freeing the sound card resources allocated by snd_card_new(), which leads to a memory leak.
Add proper error handling to free the sound card and clear the card list entry when pdacf_config() fails.
--- sound/pcmcia/pdaudiocf/pdaudiocf.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
sound/pcmcia/pdaudiocf/pdaudiocf.c +7 -1
@@ -133,7 +133,13 @@ static int snd_pdacf_probe(struct pcmcia_device *link) link->config_index =1 ; link->config_regs =PRESENT_OPTION ; -return pdacf_config (link); + err =pdacf_config (link); +if (err <0 ) { + card_list[i] =NULL ; +snd_card_free (card); +return err; + } +return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 202/451 ALSA: usb-mixer: us16x08: validate meter packet indices
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shipei Qu <[email protected]>
[ Upstream commit 5526c1c6ba1d0913c7dfcbbd6fe1744ea7c55f1e ]
get_meter_levels_from_urb() parses the 64-byte meter packets sent by the device and fills the per-channel arrays meter_level[], comp_level[] and master_level[] in struct snd_us16x08_meter_store.
Currently the function derives the channel index directly from the meter packet (MUB2(meter_urb, s) - 1) and uses it to index those arrays without validating the range. If the packet contains a negative or out-of-range channel number, the driver may write past the end of these arrays.
Introduce a local channel variable and validate it before updating the arrays. We reject negative indices, limit meter_level[] and comp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[] updates with ARRAY_SIZE(master_level).
--- sound/usb/mixer_us16x08.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
sound/usb/mixer_us16x08.c +14 -6
@@ -656,17 +656,25 @@ static void get_meter_levels_from_urb(int s, u8 *meter_urb) {int val =MUC2 (meter_urb, s) + (MUC3 (meter_urb, s) <<8 ); +int ch =MUB2 (meter_urb, s) -1 ; + +if (ch <0 ) +return ;if (MUA0 (meter_urb, s) ==0x61 &&MUA1 (meter_urb, s) ==0x02 &&MUA2 (meter_urb, s) ==0x04 &&MUB0 (meter_urb, s) ==0x62 ) { -if (MUC0 (meter_urb, s) ==0x72 ) - store->meter_level[MUB2 (meter_urb, s) -1 ] = val; -if (MUC0 (meter_urb, s) ==0xb2 ) - store->comp_level[MUB2 (meter_urb, s) -1 ] = val; +if (ch <SND_US16X08_MAX_CHANNELS ) { +if (MUC0 (meter_urb, s) ==0x72 ) + store->meter_level[ch] = val; +if (MUC0 (meter_urb, s) ==0xb2 ) + store->comp_level[ch] = val; + } }if (MUA0 (meter_urb, s) ==0x61 &&MUA1 (meter_urb, s) ==0x02 && -MUA2 (meter_urb, s) ==0x02 &&MUB0 (meter_urb, s) ==0x62 ) - store->master_level[MUB2 (meter_urb, s) -1 ] = val; +MUA2 (meter_urb, s) ==0x02 &&MUB0 (meter_urb, s) ==0x62 ) { +if (ch <ARRAY_SIZE (store->master_level)) + store->master_level[ch] = val; + } }/* Function to retrieve current meter values from the device.
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 203/451 ipmi: Fix the race between __scan_channels() and deliver_response()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinhui Guo <[email protected]>
[ Upstream commit 936750fdba4c45e13bbd17f261bb140dd55f5e93 ]
The race window between __scan_channels() and deliver_response() causes the parameters of some channels to be set to 0.
1.[CPUA] __scan_channels() issues an IPMI request and waits with
wait_event() until all channels have been scanned. wait_event() internally calls might_sleep(), which might yield the CPU. (Moreover, an interrupt can preempt wait_event() and force the task to yield the CPU.)
2.[CPUB] deliver_response() is invoked when the CPU receives the
IPMI response. After processing a IPMI response, deliver_response() directly assigns intf->wchannels to intf->channel_list and sets intf->channels_ready to true. However, not all channels are actually ready for use.
3.[CPUA] Since intf->channels_ready is already true, wait_event()
never enters __wait_event(). __scan_channels() immediately clears intf->null_user_handler and exits.
4.[CPUB] Once intf->null_user_handler is set to NULL, deliver_response()
ignores further IPMI responses, leaving the remaining channels zero-initialized and unusable.
CPUA CPUB
------------------------------- ----------------------------- __scan_channels()
intf->null_user_handler
= channel_handler;
send_channel_info_cmd(intf,
0);
wait_event(intf->waitq,
intf->channels_ready);
do {
might_sleep();
deliver_response()
channel_handler()
intf->channel_list =
intf->wchannels + set;
intf->channels_ready = true;
send_channel_info_cmd(intf,
intf->curr_channel);
if (condition)
break;
__wait_event(wq_head,
condition);
} while(0)
intf->null_user_handler
= NULL;
deliver_response()
if (!msg->user)
if (intf->null_user_handler)
rv = -EINVAL;
return rv;------------------------------- -----------------------------
Fix the race between __scan_channels() and deliver_response() by deferring both the assignment intf->channel_list = intf->wchannels and the flag intf->channels_ready = true until all channels have been successfully scanned or until the IPMI request has failed.
Message-ID: <[email protected]>
--- drivers/char/ipmi/ipmi_msghandler.c | 2 -- 1 file changed, 2 deletions(-)
drivers/char/ipmi/ipmi_msghandler.c +0 -2
@@ -3305,8 +3305,6 @@ channel_handler(struct ipmi_smi *intf, struct ipmi_recv_msg *msg) intf->channels_ready = true;wake_up (&intf->waitq); }else { - intf->channel_list = intf->wchannels + set; - intf->channels_ready = true; rv =send_channel_info_cmd (intf, intf->curr_channel); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 204/451 ipmi: Fix __scan_channels() failing to rescan channels
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinhui Guo <[email protected]>
[ Upstream commit 6bd30d8fc523fb880b4be548e8501bc0fe8f42d4 ]
channel_handler() sets intf->channels_ready to true but never clears it, so __scan_channels() skips any rescan. When the BMC firmware changes a rescan is required. Allow it by clearing the flag before starting a new scan.
Message-ID: <[email protected]>
--- drivers/char/ipmi/ipmi_msghandler.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
drivers/char/ipmi/ipmi_msghandler.c +13 -5
@@ -605,7 +605,8 @@ static void __ipmi_bmc_unregister(struct ipmi_smi *intf);static int __ipmi_bmc_register (struct ipmi_smi *intf,struct ipmi_device_id *id,bool guid_set,guid_t *guid,int intf_num); -static int __scan_channels (struct ipmi_smi *intf,struct ipmi_device_id *id); +static int __scan_channels (struct ipmi_smi *intf, +struct ipmi_device_id *id,bool rescan);/**
@@ -2556,7 +2557,7 @@ static int __bmc_get_device_id(struct ipmi_smi *intf, struct bmc_device *bmc,if (__ipmi_bmc_register (intf, &id, guid_set, &guid, intf_num))need_waiter (intf);/* Retry later on an error. */ else -__scan_channels (intf, &id); +__scan_channels (intf, &id, false);if (!intf_set) {
@@ -2576,7 +2577,7 @@ static int __bmc_get_device_id(struct ipmi_smi *intf, struct bmc_device *bmc, goto out_noprocessing; }else if (memcmp (&bmc->fetch_id, &bmc->id,sizeof (bmc->id)))/* Version info changes, scan the channels again. */ -__scan_channels (intf, &bmc->fetch_id); +__scan_channels (intf, &bmc->fetch_id, true); bmc->dyn_id_expiry = jiffies +IPMI_DYN_DEV_ID_EXPIRY ;
@@ -3326,10 +3327,17 @@ channel_handler(struct ipmi_smi *intf, struct ipmi_recv_msg *msg)/* * Must be holding intf->bmc_reg_mutex to call this. */ -static int __scan_channels (struct ipmi_smi *intf,struct ipmi_device_id *id) +static int __scan_channels (struct ipmi_smi *intf, +struct ipmi_device_id *id, +bool rescan) {int rv; +if (rescan) { +/* Clear channels_ready to force channels rescan. */ + intf->channels_ready = false; + } +if (ipmi_version_major (id) >1 || (ipmi_version_major (id) ==1 &&ipmi_version_minor (id) >=5 )) {
@@ -3501,7 +3509,7 @@ int ipmi_add_smi(struct module *owner, }mutex_lock (&intf->bmc_reg_mutex); - rv =__scan_channels (intf, &id); + rv =__scan_channels (intf, &id, false);mutex_unlock (&intf->bmc_reg_mutex);if (rv) goto out_err_bmc_reg;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 205/451 firmware: imx: scu-irq: Init workqueue before request mbox channel
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit 81fb53feb66a3aefbf6fcab73bb8d06f5b0c54ad ]
With mailbox channel requested, there is possibility that interrupts may come in, so need to make sure the workqueue is initialized before the queue is scheduled by mailbox rx callback.
--- drivers/firmware/imx/imx-scu-irq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/firmware/imx/imx-scu-irq.c +2 -2
@@ -148,6 +148,8 @@ int imx_scu_enable_general_irq_channel(struct device *dev) cl->dev = dev; cl->rx_callback = imx_scu_irq_callback; +INIT_WORK (&imx_sc_irq_work, imx_scu_irq_work_handler); +/* SCU general IRQ uses general interrupt channel 3 */ ch =mbox_request_channel_byname (cl,"gip3" );if (IS_ERR (ch)) {
@@ -157,8 +159,6 @@ int imx_scu_enable_general_irq_channel(struct device *dev)return ret; } -INIT_WORK (&imx_sc_irq_work, imx_scu_irq_work_handler); -if (!of_parse_phandle_with_args (dev->of_node,"mboxes" ,"#mbox-cells" ,0 , &spec)) { i =of_alias_get_id (spec.np,"mu" );
Signature · 1 line
2.51.0
Re: [PATCH 5.10 205/451] firmware: imx: scu-irq: Init workqueue before request mbox channel
Quoted 11 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit
81fb53feb66a3aefbf6fcab73bb8d06f5b0c54ad]With mailbox channel requested, there is possibility that interrupts may come in, so need to make sure the workqueue is initialized before the queue is scheduled by mailbox rx callback.
[...]
This is an incomplete fix; you also need to pick:
commit ff3f9913bc0749364fbfd86ea62ba2d31c6136c8
Author: Peng Fan <[email protected]> Date: Fri Oct 17 09:56:27 2025 +0800
firmware: imx: scu-irq: Set mu_resource_id before get handle
Ben.
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesGreg Kroah-Hartman
maintainerRe: [PATCH 5.10 205/451] firmware: imx: scu-irq: Init workqueue before request mbox channel
Quoted 14 lines · Ben Hutchings
Quoted 11 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit
81fb53feb66a3aefbf6fcab73bb8d06f5b0c54ad]With mailbox channel requested, there is possibility that interrupts may come in, so need to make sure the workqueue is initialized before the queue is scheduled by mailbox rx callback.
[...]
Quoted 7 lines
This is an incomplete fix; you also need to pick:
commit
ff3f9913bc0749364fbfd86ea62ba2d31c6136c8Author: Peng Fan <[email protected]> Date: Fri Oct 17 09:56:27 2025 +0800firmware: imx: scu-irq: Set
mu_resource_idbefore get handle
How did you determine this? There's no "Fixes:" tag to give us a clue as to if it's needed anywhere or not.
thanks,
greg k-h
Re: [PATCH 5.10 205/451] firmware: imx: scu-irq: Init workqueue before request mbox channel
Quoted 17 lines · Greg Kroah-Hartman
Quoted 16 lines · Ben Hutchings
Quoted 11 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit
81fb53feb66a3aefbf6fcab73bb8d06f5b0c54ad]With mailbox channel requested, there is possibility that interrupts may come in, so need to make sure the workqueue is initialized before the queue is scheduled by mailbox rx callback.
[...]
This is an incomplete fix; you also need to pick:
Quoted 8 lines
Quoted 5 lines
commit
ff3f9913bc0749364fbfd86ea62ba2d31c6136c8Author: Peng Fan <[email protected]> Date: Fri Oct 17 09:56:27 2025 +0800firmware: imx: scu-irq: Set
mu_resource_idbefore get handleHow did you determine this? There's no "Fixes:" tag to give us a clue as to if it's needed anywhere or not.
I looked at the first fix and asked myself "what other initialisation does the interrupt handler depend on?", and then I found this. I think all versions of the driver need both fixes.
Ben.
Signature · 2 lines
Ben Hutchings Larkinson's Law: All laws are basically false.
Greg Kroah-Hartman
maintainerRe: [PATCH 5.10 205/451] firmware: imx: scu-irq: Init workqueue before request mbox channel
Quoted 22 lines · Ben Hutchings
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Ben Hutchings
Quoted 11 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit
81fb53feb66a3aefbf6fcab73bb8d06f5b0c54ad]With mailbox channel requested, there is possibility that interrupts may come in, so need to make sure the workqueue is initialized before the queue is scheduled by mailbox rx callback.
[...]
This is an incomplete fix; you also need to pick:
commit
ff3f9913bc0749364fbfd86ea62ba2d31c6136c8Author: Peng Fan <[email protected]> Date: Fri Oct 17 09:56:27 2025 +0800
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
firmware: imx: scu-irq: Set
mu_resource_idbefore get handleHow did you determine this? There's no "Fixes:" tag to give us a clue as to if it's needed anywhere or not.
I looked at the first fix and asked myself "what other initialisation does the interrupt handler depend on?", and then I found this. I think all versions of the driver need both fixes.
Ok, now queued up, thanks.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 206/451 ti-sysc: allow OMAP2 and OMAP4 timers to be reserved on AM33xx
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthias Schiffer <[email protected]>
[ Upstream commit 3f61783920504b2cf99330b372d82914bb004d8e ]
am33xx.dtsi has the same clock setup as am35xx.dtsi, setting ti,no-reset-on-init and ti,no-idle on timer1_target and timer2_target, so AM33 needs the same workaround as AM35 to avoid ti-sysc probe failing on certain target modules.
--- drivers/bus/ti-sysc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/bus/ti-sysc.c +9 -2
@@ -37,6 +37,7 @@ enum sysc_soc {SOC_UNKNOWN ,SOC_2420 ,SOC_2430 , +SOC_AM33 ,SOC_3430 ,SOC_AM35 , SOC_3630,
@@ -2933,6 +2934,7 @@ static void ti_sysc_idle(struct work_struct *work)static const struct soc_device_attribute sysc_soc_match[] = {SOC_FLAG ("OMAP242*" ,SOC_2420 ),SOC_FLAG ("OMAP243*" ,SOC_2430 ), +SOC_FLAG ("AM33*" ,SOC_AM33 ),SOC_FLAG ("AM35*" ,SOC_AM35 ),SOC_FLAG ("OMAP3[45]*" ,SOC_3430 ),SOC_FLAG ("OMAP3[67]*" ,SOC_3630 ),
@@ -3121,10 +3123,15 @@ static int sysc_check_active_timer(struct sysc *ddata)* can be dropped if we stop supporting old beagleboard revisions * A to B4 at some point. */ -if (sysc_soc->soc ==SOC_3430 || sysc_soc->soc ==SOC_AM35 ) +switch (sysc_soc->soc) { +case SOC_AM33 : +case SOC_3430 : +case SOC_AM35 : error = -ENXIO ; -else +break ; +default : error = -EBUSY ; + }if ((ddata->cfg.quirks &SYSC_QUIRK_NO_RESET_ON_INIT ) && (ddata->cfg.quirks &SYSC_QUIRK_NO_IDLE ))
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 207/451 clk: mvebu: cp110 add CLK_IGNORE_UNUSED to pcie_x10, pcie_x11 & pcie_x4
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josua Mayer <[email protected]>
[ Upstream commit f0e6bc0c3ef4b4afb299bd6912586cafd5d864e9 ]
CP110 based platforms rely on the bootloader for pci port initialization.
TF-A actively prevents non-uboot re-configuration of pci lanes, and many boards do not have software control over the pci card reset.
If a pci port had link at boot-time and the clock is stopped at a later point, the link fails and can not be recovered.
PCI controller driver probe - and by extension ownership of a driver for the pci clocks - may be delayed especially on large modular kernels, causing the clock core to start disabling unused clocks.
Add the CLK_IGNORE_UNUSED flag to the three pci port's clocks to ensure they are not stopped before the pci controller driver has taken ownership and tested for an existing link.
This fixes failed pci link detection when controller driver probes late, e.g. with arm64 defconfig and CONFIG_PHY_MVEBU_CP110_COMPHY=m.
--- drivers/clk/mvebu/cp110-system-controller.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
drivers/clk/mvebu/cp110-system-controller.c +20 -0
@@ -110,6 +110,25 @@ static const char * const gate_base_names[] = { [CP110_GATE_EIP197 ] ="eip197" }; +static unsigned long gate_flags (const u8 bit_idx) +{ +switch (bit_idx) { +case CP110_GATE_PCIE_X1_0 : +case CP110_GATE_PCIE_X1_1 : +case CP110_GATE_PCIE_X4 : +/* +* If a port had an active link at boot time, stopping +* the clock creates a failed state from which controller +* driver can not recover. +* Prevent stopping this clock till after a driver has taken +* ownership. +*/ +return CLK_IGNORE_UNUSED ; +default : +return 0 ; + } +}; +struct cp110_gate_clk {struct clk_hw hw;struct regmap *regmap;
@@ -171,6 +190,7 @@ static struct clk_hw *cp110_register_gate(const char *name, init.ops = &cp110_gate_ops; init.parent_names = &parent_name; init.num_parents =1 ; + init.flags =gate_flags (bit_idx); gate->regmap = regmap; gate->bit_idx = bit_idx;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 208/451 powerpc/addnote: Fix overflow on 32-bit builds
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Collins <[email protected]>
[ Upstream commit 825ce89a3ef17f84cf2c0eacfa6b8dc9fd11d13f ]
The PUT_64[LB]E() macros need to cast the value to unsigned long long like the GET_64[LB]E() macros. Caused lots of warnings when compiled on 32-bit, and clobbered addresses (36-bit P4080).
--- arch/powerpc/boot/addnote.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
arch/powerpc/boot/addnote.c +4 -3
@@ -68,8 +68,8 @@ static int e_class = ELFCLASS32;#define PUT_16BE (off, v)(buf[off] = ((v) >> 8) & 0xff, \ buf[(off) + 1] = (v) & 0xff)#define PUT_32BE (off, v)(PUT_16BE((off), (v) >> 16L), PUT_16BE((off) + 2, (v))) -#define PUT_64BE (off, v)((PUT_32BE((off), (v) >> 32L), \ - PUT_32BE((off) + 4, (v)))) +#define PUT_64BE (off, v)((PUT_32BE((off), (unsigned long long)(v) >> 32L), \ + PUT_32BE((off) + 4, (unsigned long long)(v))))#define GET_16LE (off) ((buf[off]) + (buf[(off)+1] << 8))#define GET_32LE (off) (GET_16LE(off) + (GET_16LE((off)+2U) << 16U))
@@ -78,7 +78,8 @@ static int e_class = ELFCLASS32;#define PUT_16LE (off, v) (buf[off] = (v) & 0xff, \ buf[(off) + 1] = ((v) >> 8) & 0xff)#define PUT_32LE (off, v) (PUT_16LE((off), (v)), PUT_16LE((off) + 2, (v) >> 16L)) -#define PUT_64LE (off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, (v) >> 32L)) +#define PUT_64LE (off, v) (PUT_32LE((off), (unsigned long long)(v)), \ + PUT_32LE((off) + 4, (unsigned long long)(v) >> 32L))#define GET_16 (off) (e_data == ELFDATA2MSB ? GET_16BE(off) : GET_16LE(off))#define GET_32 (off) (e_data == ELFDATA2MSB ? GET_32BE(off) : GET_32LE(off))
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 209/451 scsi: qla2xxx: Fix initiator mode with qlini_mode=exclusive
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Battersby <[email protected]>
[ Upstream commit 8f58fc64d559b5fda1b0a5e2a71422be61e79ab9 ]
When given the module parameter qlini_mode=exclusive, qla2xxx in initiator mode is initially unable to successfully send SCSI commands to devices it finds while scanning, resulting in an escalating series of resets until an adapter reset clears the issue. Fix by checking the active mode instead of the module parameter.
--- drivers/scsi/qla2xxx/qla_os.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +1 -7
@@ -3288,13 +3288,7 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) base_vha->mgmt_svr_loop_id, host->sg_tablesize);if (ha->mqenable) { -bool startit = false; - -if (QLA_TGT_MODE_ENABLED ()) - startit = false; - -if (ql2x_ini_mode ==QLA2XXX_INI_MODE_ENABLED ) - startit = true; +bool startit = !!(host->active_mode &MODE_INITIATOR );/* Create start of day qpairs for Block MQ */ for (i =0 ; i < ha->max_qpairs; i++)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 210/451 scsi: qla2xxx: Use reinit_completion on mbx_intr_comp
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Battersby <[email protected]>
[ Upstream commit 957aa5974989fba4ae4f807ebcb27f12796edd4d ]
If a mailbox command completes immediately after wait_for_completion_timeout() times out, ha->mbx_intr_comp could be left in an inconsistent state, causing the next mailbox command not to wait for the hardware. Fix by reinitializing the completion before use.
--- drivers/scsi/qla2xxx/qla_mbx.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/scsi/qla2xxx/qla_mbx.c +2 -0
@@ -249,6 +249,7 @@ qla2x00_mailbox_command(scsi_qla_host_t *vha, mbx_cmd_t *mcp)/* Issue set host interrupt command to send cmd out. */ ha->flags.mbox_int =0 ;clear_bit (MBX_INTERRUPT , &ha->mbx_cmd_flags); +reinit_completion (&ha->mbx_intr_comp);/* Unlock mbx registers and wait for interrupt */ ql_dbg(ql_dbg_mbx, vha, 0x100f,
@@ -275,6 +276,7 @@ qla2x00_mailbox_command(scsi_qla_host_t *vha, mbx_cmd_t *mcp) "cmd=%x Timeout.\n", command);spin_lock_irqsave (&ha->hardware_lock, flags);clear_bit (MBX_INTR_WAIT , &ha->mbx_cmd_flags); +reinit_completion (&ha->mbx_intr_comp);spin_unlock_irqrestore (&ha->hardware_lock, flags);if (chip_reset != ha->chip_reset) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 211/451 via_wdt: fix critical boot hang due to unnamed resource allocation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Qiang <[email protected]>
[ Upstream commit 7aa31ee9ec92915926e74731378c009c9cc04928 ]
The VIA watchdog driver uses allocate_resource() to reserve a MMIO region for the watchdog control register. However, the allocated resource was not given a name, which causes the kernel resource tree to contain an entry marked as "<BAD>" under /proc/iomem on x86 platforms.
During boot, this unnamed resource can lead to a critical hang because subsequent resource lookups and conflict checks fail to handle the invalid entry properly.
--- drivers/watchdog/via_wdt.c | 1 + 1 file changed, 1 insertion(+)
drivers/watchdog/via_wdt.c +1 -0
@@ -165,6 +165,7 @@ static int wdt_probe(struct pci_dev *pdev,dev_err (&pdev->dev,"cannot enable PCI device\n" );return -ENODEV ; } + wdt_res.name ="via_wdt" ;/* * Allocate a MMIO region which contains watchdog control register
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 212/451 reset: fix BIT macro reference
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Encrow Thorne <[email protected]>
[ Upstream commit f3d8b64ee46c9b4b0b82b1a4642027728bac95b8 ]
RESET_CONTROL_FLAGS_BIT_* macros use BIT(), but reset.h does not include bits.h. This causes compilation errors when including reset.h standalone.
Include bits.h to make reset.h self-contained.
--- include/linux/reset.h | 1 + 1 file changed, 1 insertion(+)
include/linux/reset.h +1 -0
@@ -2,6 +2,7 @@#ifndef _LINUX_RESET_H_#define _LINUX_RESET_H_ +#include <linux/bits.h> #include <linux/err.h> #include <linux/errno.h> #include <linux/types.h>
Signature · 1 line
2.51.0
Re: [PATCH 5.10 212/451] reset: fix BIT macro reference
Quoted 6 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Encrow Thorne <[email protected]>
Quoted 7 lines
[ Upstream commit
f3d8b64ee46c9b4b0b82b1a4642027728bac95b8]RESET_CONTROL_FLAGS_BIT_* macros use
BIT(), butreset.hdoes not includebits.h. This causes compilation errors when includingreset.hstandalone.Include
bits.hto makereset.hself-contained.
[...]
This should have had:
That commit went into 6.13, so only the 6.18-stable branch needed this.
Ben.
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesGreg Kroah-Hartman
maintainerRe: [PATCH 5.10 212/451] reset: fix BIT macro reference
Quoted 13 lines · Ben Hutchings
Quoted 12 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Encrow Thorne <[email protected]>
[ Upstream commit
f3d8b64ee46c9b4b0b82b1a4642027728bac95b8]RESET_CONTROL_FLAGS_BIT_* macros use
BIT(), butreset.hdoes not includebits.h. This causes compilation errors when includingreset.hstandalone.
Quoted 8 lines
Quoted 1 line
Include
bits.hto makereset.hself-contained.[...]
This should have had:
Fixes dad35f7d2fc1 ("reset: replace boolean parameters with flags parameter")That commit went into 6.13, so only the 6.18-stable branch needed this.
Now dropped, thanks.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 213/451 exfat: fix remount failure in different process environments
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuezhang Mo <[email protected]>
[ Upstream commit 51fc7b4ce10ccab8ea5e4876bcdc42cf5202a0ef ]
The kernel test robot reported that the exFAT remount operation failed. The reason for the failure was that the process's umask is different between mount and remount, causing fs_fmask and fs_dmask are changed.
Potentially, both gid and uid may also be changed. Therefore, when initializing fs_context for remount, inherit these mount options from the options used during mount.
--- fs/exfat/super.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
fs/exfat/super.c +15 -4
@@ -757,10 +757,21 @@ static int exfat_init_fs_context(struct fs_context *fc)ratelimit_state_init (&sbi->ratelimit,DEFAULT_RATELIMIT_INTERVAL ,DEFAULT_RATELIMIT_BURST ); - sbi->options.fs_uid =current_uid (); - sbi->options.fs_gid =current_gid (); - sbi->options.fs_fmask = current->fs->umask; - sbi->options.fs_dmask = current->fs->umask; +if (fc->purpose ==FS_CONTEXT_FOR_RECONFIGURE && fc->root) { +struct super_block *sb = fc->root->d_sb; +struct exfat_mount_options *cur_opts = &EXFAT_SB (sb)->options; + + sbi->options.fs_uid = cur_opts->fs_uid; + sbi->options.fs_gid = cur_opts->fs_gid; + sbi->options.fs_fmask = cur_opts->fs_fmask; + sbi->options.fs_dmask = cur_opts->fs_dmask; + }else { + sbi->options.fs_uid =current_uid (); + sbi->options.fs_gid =current_gid (); + sbi->options.fs_fmask = current->fs->umask; + sbi->options.fs_dmask = current->fs->umask; + } + sbi->options.allow_utime =-1 ; sbi->options.iocharset = exfat_default_iocharset; sbi->options.errors =EXFAT_ERRORS_RO ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 214/451 usbip: Fix locking bug in RT-enabled kernels
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lizhi Xu <[email protected]>
[ Upstream commit 09bf21bf5249880f62fe759b53b14b4b52900c6c ]
Interrupts are disabled before entering usb_hcd_giveback_urb(). A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts.
Save the interrupt status and restore it after usb_hcd_giveback_urb().
syz reported:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 rt_spin_lock+0xc7/0x2c0 kernel/locking/spinlock_rt.c:57 spin_lock include/linux/spinlock_rt.h:44 [inline] mon_bus_complete drivers/usb/mon/mon_main.c:134 [inline] mon_complete+0x5c/0x200 drivers/usb/mon/mon_main.c:147 usbmon_urb_complete include/linux/usb/hcd.h:738 [inline] __usb_hcd_giveback_urb+0x254/0x5e0 drivers/usb/core/hcd.c:1647 vhci_urb_enqueue+0xb4f/0xe70 drivers/usb/usbip/vhci_hcd.c:818
--- drivers/usb/usbip/vhci_hcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/usbip/vhci_hcd.c +3 -3
@@ -830,15 +830,15 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag no_need_xmit:usb_hcd_unlink_urb_from_ep (hcd, urb); no_need_unlink: -spin_unlock_irqrestore (&vhci->lock, flags);if (!ret) {/* usb_hcd_giveback_urb() should be called with * irqs disabled */ -local_irq_disable (); +spin_unlock (&vhci->lock);usb_hcd_giveback_urb (hcd, urb, urb->status); -local_irq_enable (); +spin_lock (&vhci->lock); } +spin_unlock_irqrestore (&vhci->lock, flags);return ret; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 215/451 usb: typec: ucsi: Handle incorrect num_connectors capability
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Pearson <[email protected]>
[ Upstream commit 30cd2cb1abf4c4acdb1ddb468c946f68939819fb ]
The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero.
Some buggy FW has been known to set this bit, and it can lead to a system not booting.
Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.
Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.
--- drivers/usb/typec/ucsi/ucsi.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/typec/ucsi/ucsi.c +6 -0
@@ -1220,6 +1220,12 @@ static int ucsi_init(struct ucsi *ucsi) ret = -ENODEV ; goto err_reset; } +/* Check if reserved bit set. This is out of spec but happens in buggy FW */ +if (ucsi->cap.num_connectors &0x80 ) { +dev_warn (ucsi->dev,"UCSI: Invalid num_connectors %d. Likely buggy FW\n" , + ucsi->cap.num_connectors); + ucsi->cap.num_connectors &=0x7f ;// clear bit and carry on + }/* Allocate the connectors. Released in ucsi_unregister_ppm() */ ucsi->connector = kcalloc(ucsi->cap.num_connectors + 1,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 216/451 usb: xhci: limit run_graceperiod for only usb 3.0 devices
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hongyu Xie <[email protected]>
[ Upstream commit 8d34983720155b8f05de765f0183d9b0e1345cc0 ]
run_graceperiod blocks usb 2.0 devices from auto suspending after xhci_start for 500ms.
Log shows:
[ 13.387170] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.387177] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.387182] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.387188] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.387191] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.387193] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.387296] hub_event:5779: hub 3-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.393343] handle_port_status:2034: xhci-hcd PNP0D10:02: handle_port_status: starting usb5 port polling. [ 13.393353] xhci_hub_control:1271: xhci-hcd PNP0D10:02: Get port status 5-1 read: 0x206e1, return 0x10101 [ 13.400047] hub_suspend:3903: hub 3-0:1.0: hub_suspend [ 13.403077] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.403080] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.403085] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.403087] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.403090] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.403093] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.403095] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.405002] handle_port_status:1913: xhci-hcd PNP0D10:04: Port change event, 9-1, id 1, portsc: 0x6e1 [ 13.405016] hub_activate:1169: usb usb5-port1: status 0101 change 0001 [ 13.405026] xhci_clear_port_change_bit:658: xhci-hcd PNP0D10:02: clear port1 connect change, portsc: 0x6e1 [ 13.413275] hcd_bus_suspend:2250: usb usb3: bus auto-suspend, wakeup 1 [ 13.419081] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.419086] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.419095] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.419100] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.419106] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.419110] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event [ 13.419112] hcd_bus_resume:2303: usb usb7: usb auto-resume [ 13.420455] handle_port_status:2034: xhci-hcd PNP0D10:04: handle_port_status: starting usb9 port polling. [ 13.420493] handle_port_status:1913: xhci-hcd PNP0D10:05: Port change event, 10-1, id 1, portsc: 0x6e1 [ 13.425332] hcd_bus_suspend:2279: usb usb3: suspend raced with wakeup event [ 13.431931] handle_port_status:2034: xhci-hcd PNP0D10:05: handle_port_status: starting usb10 port polling. [ 13.435080] hub_resume:3948: hub 7-0:1.0: hub_resume [ 13.435084] xhci_hub_control:1271: xhci-hcd PNP0D10:03: Get port status 7-1 read: 0x2a0, return 0x100 [ 13.435092] hub_event:5779: hub 7-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 13.435096] hub_suspend:3903: hub 7-0:1.0: hub_suspend [ 13.435102] hcd_bus_suspend:2250: usb usb7: bus auto-suspend, wakeup 1 [ 13.435106] hcd_bus_suspend:2279: usb usb7: suspend raced with wakeup event
usb7 and other usb 2.0 root hub were rapidly toggling between suspend and resume states. More, "suspend raced with wakeup event" confuses people.
So, limit run_graceperiod for only usb 3.0 devices
--- drivers/usb/host/xhci-hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci-hub.c +1 -1
@@ -1564,7 +1564,7 @@ int xhci_hub_status_data(struct usb_hcd *hcd, char *buf)* SS devices are only visible to roothub after link training completes. * Keep polling roothubs for a grace period after xHC start */ -if (xhci->run_graceperiod) { +if (hcd->speed >=HCD_USB3 && xhci->run_graceperiod) {if (time_before (jiffies, xhci->run_graceperiod)) status =1 ;else
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 217/451 usb: usb-storage: No additional quirks need to be added to the EL-R12 optical drive.
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Changcheng <[email protected]>
[ Upstream commit 955a48a5353f4fe009704a9a4272a3adf627cd35 ]
The optical drive of EL-R12 has the same vid and pid as INIC-3069, as follows:
T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=13fd ProdID=3940 Rev= 3.10 S: Manufacturer=HL-DT-ST S: Product= DVD+-RW GT80N S: SerialNumber=423349524E4E38303338323439202020 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=144mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=02 Prot=50 Driver=usb-storage E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
This will result in the optical drive device also adding the quirks of US_FL_NO_ATA_1X. When performing an erase operation, it will fail, and the reason for the failure is as follows:
[ 388.967742] sr 5:0:0:0: [sr0] tag#0 Send: scmd 0x00000000d20c33a7 [ 388.967742] sr 5:0:0:0: [sr0] tag#0 CDB: ATA command pass through(12)/Blank a1 11 00 00 00 00 00 00 00 00 00 00 [ 388.967773] sr 5:0:0:0: [sr0] tag#0 Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE driverbyte=DRIVER_OK cmd_age=0s [ 388.967773] sr 5:0:0:0: [sr0] tag#0 CDB: ATA command pass through(12)/Blank a1 11 00 00 00 00 00 00 00 00 00 00 [ 388.967803] sr 5:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current] [ 388.967803] sr 5:0:0:0: [sr0] tag#0 Add. Sense: Invalid field in cdb [ 388.967803] sr 5:0:0:0: [sr0] tag#0 scsi host busy 1 failed 0 [ 388.967803] sr 5:0:0:0: Notifying upper driver of completion (result 8100002) [ 388.967834] sr 5:0:0:0: [sr0] tag#0 0 sectors total, 0 bytes done.
For the EL-R12 standard optical drive, all operational commands and usage scenarios were tested without adding the IGNORE_RESIDUE quirks, and no issues were encountered. It can be reasonably concluded that removing the IGNORE_RESIDUE quirks has no impact.
--- drivers/usb/storage/unusual_uas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/storage/unusual_uas.h +1 -1
@@ -98,7 +98,7 @@ UNUSUAL_DEV(0x125f, 0xa94a, 0x0160, 0x0160, US_FL_NO_ATA_1X),/* Reported-by: Benjamin Tissoires <[email protected]> */ -UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999, +UNUSUAL_DEV(0x13fd, 0x3940, 0x0309, 0x0309, "Initio Corporation", "INIC-3069", USB_SC_DEVICE, USB_PR_DEVICE, NULL,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 218/451 serial: sprd: Return -EPROBE_DEFER when uart clock is not ready
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wenhua Lin <[email protected]>
[ Upstream commit 29e8a0c587e328ed458380a45d6028adf64d7487 ]
In sprd_clk_init(), when devm_clk_get() returns -EPROBE_DEFER for either uart or source clock, we should propagate the error instead of just warning and continuing with NULL clocks.
Currently the driver only emits a warning when clock acquisition fails and proceeds with NULL clock pointers. This can lead to issues later when the clocks are actually needed. More importantly, when the clock provider is not ready yet and returns -EPROBE_DEFER, we should return this error to allow deferred probing.
This change adds explicit checks for -EPROBE_DEFER after both:
1. devm_clk_get(uport->dev, uart)
2. devm_clk_get(uport->dev, source)
When -EPROBE_DEFER is encountered, the function now returns -EPROBE_DEFER to let the driver framework retry probing later when the clock dependencies are resolved.
--- drivers/tty/serial/sprd_serial.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/tty/serial/sprd_serial.c +6 -0
@@ -1137,6 +1137,9 @@ static int sprd_clk_init(struct uart_port *uport) clk_uart =devm_clk_get (uport->dev,"uart" );if (IS_ERR (clk_uart)) { +if (PTR_ERR (clk_uart) == -EPROBE_DEFER ) +return -EPROBE_DEFER ; +dev_warn (uport->dev,"uart%d can't get uart clock\n" , uport->line); clk_uart =NULL ;
@@ -1144,6 +1147,9 @@ static int sprd_clk_init(struct uart_port *uport) clk_parent =devm_clk_get (uport->dev,"source" );if (IS_ERR (clk_parent)) { +if (PTR_ERR (clk_parent) == -EPROBE_DEFER ) +return -EPROBE_DEFER ; +dev_warn (uport->dev,"uart%d can't get source clock\n" , uport->line); clk_parent =NULL ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 219/451 nvme-fc: dont hold rport lock when putting ctrl
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Wagner <[email protected]>
[ Upstream commit b71cbcf7d170e51148d5467820ae8a72febcb651 ]
nvme_fc_ctrl_put can acquire the rport lock when freeing the ctrl object:
nvme_fc_ctrl_put
nvme_fc_ctrl_free
spin_lock_irqsave(rport->lock)
Thus we can't hold the rport lock when calling nvme_fc_ctrl_put.
Justin suggested use the safe list iterator variant because nvme_fc_ctrl_put will also modify the rport->list.
--- drivers/nvme/host/fc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/nvme/host/fc.c +4 -2
@@ -1500,14 +1500,14 @@ nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport, {struct fcnvme_ls_disconnect_assoc_rqst *rqst = &lsop->rqstbuf->rq_dis_assoc; -struct nvme_fc_ctrl *ctrl, *ret =NULL ; +struct nvme_fc_ctrl *ctrl, *tmp, *ret =NULL ;struct nvmefc_ls_rcv_op *oldls =NULL ;u64 association_id =be64_to_cpu (rqst->associd.association_id);unsigned long flags;spin_lock_irqsave (&rport->lock, flags); -list_for_each_entry (ctrl, &rport->ctrl_list, ctrl_list) { +list_for_each_entry_safe (ctrl, tmp, &rport->ctrl_list, ctrl_list) {if (!nvme_fc_ctrl_get (ctrl))continue ;spin_lock (&ctrl->lock);
@@ -1520,7 +1520,9 @@ nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport,if (ret)/* leave the ctrl get reference */ break ; +spin_unlock_irqrestore (&rport->lock, flags);nvme_fc_ctrl_put (ctrl); +spin_lock_irqsave (&rport->lock, flags); }spin_unlock_irqrestore (&rport->lock, flags);
Signature · 1 line
2.51.0
Re: [PATCH 5.10 219/451] nvme-fc: dont hold rport lock when putting ctrl
Quoted 11 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Wagner <[email protected]>
[ Upstream commit
b71cbcf7d170e51148d5467820ae8a72febcb651]
nvme_fc_ctrl_putcan acquire the rport lock when freeing the ctrl object:
Quoted 8 lines
nvme_fc_ctrl_put
nvme_fc_ctrl_freespin_lock_irqsave(rport->lock)Thus we can't hold the rport lock when calling
nvme_fc_ctrl_put.Justin suggested use the safe list iterator variant because
nvme_fc_ctrl_putwill also modify therport->list.
The "safe" list iterator macros do protect against deletion of the current node within the loop body, but they assume the next node won't also be deleted.
[...]
drivers/nvme/host/fc.c nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport, · line 1525
Quoted 12 lines
drivers/nvme/host/fc.c +3
-1-list_for_each_entry (ctrl, &rport->ctrl_list, ctrl_list) { +list_for_each_entry_safe (ctrl, tmp, &rport->ctrl_list, ctrl_list) {if (!nvme_fc_ctrl_get (ctrl))continue ;spin_lock (&ctrl->lock);@@ -1520,7 +1520,9 @@ nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport,if (ret)/* leave the ctrl get reference */ break ; +spin_unlock_irqrestore (&rport->lock, flags);nvme_fc_ctrl_put (ctrl); +spin_lock_irqsave (&rport->lock, flags);
Does anything prevent the next node (*tmp) being removed by another thread while the lock is dropped here?
Ben.
Quoted 3 lines
drivers/nvme/host/fc.c +0
-0}spin_unlock_irqrestore (&rport->lock, flags);
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesRe: [PATCH 5.10 219/451] nvme-fc: dont hold rport lock when putting ctrl
Hi Ben,
Quoted 8 lines · Ben Hutchings
Quoted 2 lines
Justin suggested use the safe list iterator variant because
nvme_fc_ctrl_putwill also modify therport->list.The "safe" list iterator macros do protect against deletion of the current node within the loop body, but they assume the next node won't also be deleted.
[...]
Quoted 15 lines
drivers/nvme/host/fc.c nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport, · line 1525
Quoted 12 lines
drivers/nvme/host/fc.c +3
-1-list_for_each_entry (ctrl, &rport->ctrl_list, ctrl_list) { +list_for_each_entry_safe (ctrl, tmp, &rport->ctrl_list, ctrl_list) {if (!nvme_fc_ctrl_get (ctrl))continue ;spin_lock (&ctrl->lock);@@ -1520,7 +1520,9 @@ nvme_fc_match_disconn_ls(struct nvme_fc_rport *rport,if (ret)/* leave the ctrl get reference */ break ; +spin_unlock_irqrestore (&rport->lock, flags);nvme_fc_ctrl_put (ctrl); +spin_lock_irqsave (&rport->lock, flags);Does anything prevent the next node (*tmp) being removed by another thread while the lock is dropped here?
Thanks for looking at this. There is nothing in place to prevent LS requests running in parallel, e.g. two dissociating controllers LS for one rport,
schedule_work(&rport->lsrcv_work)
nvme_fc_handle_ls_rqst_work
nvme_fc_handle_ls_rqst
nvme_fc_ls_disconnect_assocWhat's the proper way to address this? I saw there is a list_safe_reset_next:
list_for_each_entry_safe(ctrl, tmp, &rport->ctrl_list, ctrl_list) {
[...]
spin_unlock_irqrestore(&rport->lock, flags);
nvme_fc_ctrl_put(ctrl);
spin_lock_irqsave(&rport->lock, flags);
list_safe_reset_next(ctrl, tmp, ctrl_list);
}Is there another common pattern? Normally, I would use the list swap approach but here it doesn't work, at least without a lot of changes I think.
Thanks,
Daniel
Greg Kroah-Hartman
maintainerPATCH 220/451 block: rnbd-clt: Fix signedness bug in init_dev()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 1ddb815fdfd45613c32e9bd1f7137428f298e541 ]
The "dev->clt_device_id" variable is set using ida_alloc_max() which returns an int and in particular it returns negative error codes. Change the type from u32 to int to fix the error checking.
--- drivers/block/rnbd/rnbd-clt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/block/rnbd/rnbd-clt.h +1 -1
@@ -105,7 +105,7 @@ struct rnbd_clt_dev {struct rnbd_queue *hw_queues;u32 device_id;/* local Idr index - used to track minor number allocations. */ -u32 clt_device_id; +int clt_device_id;struct mutex lock;enum rnbd_clt_dev_state dev_state;char *pathname;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 221/451 vhost/vsock: improve RCU read sections around vhost_vsock_get()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Garzarella <[email protected]>
[ Upstream commit d8ee3cfdc89b75dc059dc21c27bef2c1440f67eb ]
vhost_vsock_get() uses hash_for_each_possible_rcu() to find the vhost_vsock associated with the guest_cid. hash_for_each_possible_rcu() should only be called within an RCU read section, as mentioned in the following comment in include/linux/rculist.h:
/**
* hlist_for_each_entry_rcu - iterate over rcu list of given type
* @pos: the type * to use as a loop cursor.
* @head: the head for your list.
* @member: the name of the hlist_node within the struct.
* @cond: optional lockdep expression if called from non-RCU protection.
*
* This list-traversal primitive may safely run concurrently with
* the _rcu list-mutation primitives such as hlist_add_head_rcu()
* as long as the traversal is guarded by rcu_read_lock(). */
Currently, all calls to vhost_vsock_get() are between rcu_read_lock() and rcu_read_unlock() except for calls in vhost_vsock_set_cid() and vhost_vsock_reset_orphans(). In both cases, the current code is safe, but we can make improvements to make it more robust.
About vhost_vsock_set_cid(), when building the kernel with CONFIG_PROVE_RCU_LIST enabled, we get the following RCU warning when the user space issues ioctl(dev, VHOST_VSOCK_SET_GUEST_CID, ...) :
WARNING: suspicious RCU usage
6.18.0-rc7 #62 Not tainted
-----------------------------
drivers/vhost/vsock.c:74 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by rpc-libvirtd/3443:
#0: ffffffffc05032a8 (vhost_vsock_mutex){+.+.}-{4:4}, at: vhost_vsock_dev_ioctl+0x2ff/0x530 [vhost_vsock]
stack backtrace: CPU: 2 UID: 0 PID: 3443 Comm: rpc-libvirtd Not tainted 6.18.0-rc7 #62 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-7.fc42 06/10/2025 Call Trace: <TASK> dump_stack_lvl+0x75/0xb0 dump_stack+0x14/0x1a lockdep_rcu_suspicious.cold+0x4e/0x97 vhost_vsock_get+0x8f/0xa0 [vhost_vsock] vhost_vsock_dev_ioctl+0x307/0x530 [vhost_vsock] __x64_sys_ioctl+0x4f2/0xa00 x64_sys_call+0xed0/0x1da0 do_syscall_64+0x73/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... </TASK>
This is not a real problem, because the vhost_vsock_get() caller, i.e. vhost_vsock_set_cid(), holds the vhost_vsock_mutex used by the hash table writers. Anyway, to prevent that warning, add lockdep_is_held() condition to hash_for_each_possible_rcu() to verify that either the caller is in an RCU read section or vhost_vsock_mutex is held when CONFIG_PROVE_RCU_LIST is enabled; and also clarify the comment for vhost_vsock_get() to better describe the locking requirements and the scope of the returned pointer validity.
About vhost_vsock_reset_orphans(), currently this function is only called via vsock_for_each_connected_socket(), which holds the vsock_table_lock spinlock (which is also an RCU read-side critical section). However, add an explicit RCU read lock there to make the code more robust and explicit about the RCU requirements, and to prevent issues if the calling context changes in the future or if vhost_vsock_reset_orphans() is called from other contexts.
Message-Id: <[email protected]>
Message-ID: <20251126210313.GA499503@fedora>
--- drivers/vhost/vsock.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/vhost/vsock.c +11 -4
@@ -58,14 +58,15 @@ static u32 vhost_transport_get_local_cidreturn VHOST_VSOCK_DEFAULT_HOST_CID ; } -/* Callers that dereference the return value must hold vhost_vsock_mutex or the -* RCU read lock. +/* Callers must be in an RCU read section or hold the vhost_vsock_mutex. +* The return value can only be dereferenced while within the section. */ static struct vhost_vsock *vhost_vsock_get (u32 guest_cid) {struct vhost_vsock *vsock; -hash_for_each_possible_rcu (vhost_vsock_hash, vsock, hash, guest_cid) { +hash_for_each_possible_rcu (vhost_vsock_hash, vsock, hash, guest_cid, +lockdep_is_held (&vhost_vsock_mutex)) {u32 other_cid = vsock->guest_cid;/* Skip instances that have no CID yet */
@@ -666,9 +667,15 @@ static void vhost_vsock_reset_orphans(st* executing. */ +rcu_read_lock (); +/* If the peer is still valid, no need to reset connection */ -if (vhost_vsock_get (vsk->remote_addr.svm_cid)) +if (vhost_vsock_get (vsk->remote_addr.svm_cid)) { +rcu_read_unlock ();return ; + } + +rcu_read_unlock ();/* If the close timeout is pending, let it expire. This avoids races * with the timeout callback.
Greg Kroah-Hartman
maintainerPATCH 222/451 lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 upstream.
In the C code, the 'inc' argument to the assembly functions blake2s_compress_ssse3() and blake2s_compress_avx512() is declared with type u32, matching blake2s_compress(). The assembly code then reads it from the 64-bit %rcx. However, the ABI doesn't guarantee zero-extension to 64 bits, nor do gcc or clang guarantee it. Therefore, fix these functions to read this argument from the 32-bit %ecx.
In theory, this bug could have caused the wrong 'inc' value to be used, causing incorrect BLAKE2s hashes. In practice, probably not: I've fixed essentially this same bug in many other assembly files too, but there's never been a real report of it having caused a problem. In x86_64, all writes to 32-bit registers are zero-extended to 64 bits. That results in zero-extension in nearly all situations. I've only been able to demonstrate a lack of zero-extension with a somewhat contrived example involving truncation, e.g. when the C code has a u64 variable holding 0x1234567800000040 and passes it as a u32 expecting it to be truncated to 0x40 (64). But that's not what the real code does, of course.
--- arch/x86/crypto/blake2s-core.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/crypto/blake2s-core.S +2 -2
@@ -54,7 +54,7 @@ SYM_FUNC_START(blake2s_compress_ssse3) movdqa ROT16(%rip),%xmm12 movdqa ROR328(%rip),%xmm13 movdqu 0x20(%rdi),%xmm14 - movq %rcx,%xmm15 + movd %ecx,%xmm15 leaq SIGMA+0xa0(%rip),%r8 jmp .Lbeginofloop .align 32
@@ -179,7 +179,7 @@ SYM_FUNC_START(blake2s_compress_avx512) vmovdqu (%rdi),%xmm0 vmovdqu 0x10(%rdi),%xmm1 vmovdqu 0x20(%rdi),%xmm4 - vmovq %rcx,%xmm5 + vmovd %ecx,%xmm5 vmovdqa IV(%rip),%xmm14 vmovdqa IV+16(%rip),%xmm15 jmp .Lblake2s_compress_avx512_mainloop
Greg Kroah-Hartman
maintainerPATCH 223/451 floppy: fix for PAGE_SIZE != 4KB
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rene Rebe <[email protected]>
commit 82d20481024cbae2ea87fe8b86d12961bfda7169 upstream.
For years I wondered why the floppy driver does not just work on sparc64, e.g:
root@SUNW_375_0066:# disktype /dev/fd0 disktype: Can't open /dev/fd0: No such device or address
[ 525.341906] disktype: attempt to access beyond end of device fd0: rw=0, sector=0, nr_sectors = 16 limit=8 [ 525.341991] floppy: error 10 while reading block 0
Turns out floppy.c __floppy_read_block_0 tries to read one page for the first test read to determine the disk size and thus fails if that is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
--- drivers/block/floppy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/block/floppy.c +1 -1
@@ -332,7 +332,7 @@ static bool initialized;* This default is used whenever the current disk size is unknown. * [Now it is rather a minimum] */ -#define MAX_DISK_SIZE 4/* 3984 */ +#define MAX_DISK_SIZE (PAGE_SIZE / 1024)/* * globals used by 'result()'
Greg Kroah-Hartman
maintainerPATCH 224/451 ktest.pl: Fix uninitialized var in config-bisect.pl
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit d3042cbe84a060b4df764eb6c5300bbe20d125ca upstream.
The error path of copying the old config used the wrong variable in the error message:
$ mkdir /tmp/build $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad $ chmod 0 /tmp/build $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad good cp /tmp/build//.config config-good.tmp ... [0 seconds] FAILED! Use of uninitialized value $config in concatenation (.) or string at ./tools/testing/ktest/config-bisect.pl line 744. failed to copy to config-good.tmp
When it should have shown:
failed to copy /tmp/build//.config to config-good.tmp
--- tools/testing/ktest/config-bisect.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/ktest/config-bisect.pl +2 -2
@@ -741,9 +741,9 @@ if ($start) { die "Can not find file $bad\n"; } if ($val eq "good") { - run_command "cp $output_config $good" or die "failed to copy $config to $good\n"; + run_command "cp $output_config $good" or die "failed to copy $output_config to $good\n"; } elsif ($val eq "bad") { - run_command "cp $output_config $bad" or die "failed to copy $config to $bad\n"; + run_command "cp $output_config $bad" or die "failed to copy $output_config to $bad\n"; } }
Greg Kroah-Hartman
maintainerPATCH 225/451 ext4: xattr: fix null pointer deref in ext4_raw_inode()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karina Yankevich <[email protected]>
commit b97cb7d6a051aa6ebd57906df0e26e9e36c26d14 upstream.
If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Message-ID: <[email protected]>
--- fs/ext4/xattr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
fs/ext4/xattr.c +5 -1
@@ -1134,7 +1134,11 @@ ext4_xattr_inode_dec_ref_all(handle_t *hif (block_csum) end = (void *)bh->b_data + bh->b_size;else { -ext4_get_inode_loc (parent, &iloc); + err =ext4_get_inode_loc (parent, &iloc); +if (err) { +EXT4_ERROR_INODE (parent,"parent inode loc (error %d)" , err); +return ; + } end = (void *)ext4_raw_inode (&iloc) +EXT4_SB (parent->i_sb)->s_inode_size; }
Greg Kroah-Hartman
maintainerPATCH 226/451 ext4: fix incorrect group number assertion in mb_check_buddy
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yongjian Sun <[email protected]>
commit 3f7a79d05c692c7cfec70bf104b1b3c3d0ce6247 upstream.
When the MB_CHECK_ASSERT macro is enabled, an assertion failure can occur in __mb_check_buddy when checking preallocated blocks (pa) in a block group:
Assertion failure in mb_free_blocks() : "groupnr == e4b->bd_group"
This happens when a pa at the very end of a block group (e.g., pa_pstart=32765, pa_len=3 in a group of 32768 blocks) becomes exhausted - its pa_pstart is advanced by pa_len to 32768, which lies in the next block group. If this exhausted pa (with pa_len == 0) is still in the bb_prealloc_list during the buddy check, the assertion incorrectly flags it as belonging to the wrong group. A possible sequence is as follows:
ext4_mb_new_blocks
ext4_mb_release_context
pa->pa_pstart += EXT4_C2B(sbi, ac->ac_b_ex.fe_len)
pa->pa_len -= ac->ac_b_ex.fe_len
__mb_check_buddy
for each pa in group
ext4_get_group_no_and_offset
MB_CHECK_ASSERT(groupnr == e4b->bd_group)To fix this, we modify the check to skip block group validation for exhausted preallocations (where pa_len == 0). Such entries are in a transitional state and will be removed from the list soon, so they should not trigger an assertion. This change prevents the false positive while maintaining the integrity of the checks for active allocations.
Message-ID: <[email protected]>
--- fs/ext4/mballoc.c | 2 ++ 1 file changed, 2 insertions(+)
fs/ext4/mballoc.c +2 -0
@@ -706,6 +706,8 @@ static void __mb_check_buddy(struct ext4ext4_group_t groupnr;struct ext4_prealloc_space *pa; pa = list_entry(cur, struct ext4_prealloc_space, pa_group_list); +if (!pa->pa_len) +continue ;ext4_get_group_no_and_offset (sb, pa->pa_pstart, &groupnr, &k);MB_CHECK_ASSERT (groupnr == e4b->bd_group);for (i =0 ; i < pa->pa_len; i++)
Greg Kroah-Hartman
maintainerPATCH 227/451 jbd2: use a weaker annotation in journal handling
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Byungchul Park <[email protected]>
commit 40a71b53d5a6d4ea17e4d54b99b2ac03a7f5e783 upstream.
jbd2 journal handling code doesn't want jbd2_might_wait_for_commit() to be placed between start_this_handle() and stop_this_handle(). So it marks the region with rwsem_acquire_read() and rwsem_release().
However, the annotation is too strong for that purpose. We don't have to use more than try lock annotation for that.
rwsem_acquire_read() implies:
1. might be a waiter on contention of the lock.
2. enter to the critical section of the lock.
All we need in here is to act 2, not 1. So trylock version of annotation is sufficient for that purpose. Now that dept partially relies on lockdep annotaions, dept interpets rwsem_acquire_read() as a potential wait and might report a deadlock by the wait.
Replace it with trylock version of annotation.
Message-ID: <[email protected]>
--- fs/jbd2/transaction.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/jbd2/transaction.c +1 -1
@@ -448,7 +448,7 @@ repeat:read_unlock (&journal->j_state_lock); current->journal_info = handle; -rwsem_acquire_read (&journal->j_trans_commit_map,0 ,0 , _THIS_IP_); +rwsem_acquire_read (&journal->j_trans_commit_map,0 ,1 , _THIS_IP_);jbd2_journal_free_transaction (new_transaction);/* * Ensure that no allocations done while the transaction is open are
Greg Kroah-Hartman
maintainerPATCH 228/451 media: v4l2-mem2mem: Fix outdated documentation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
commit 082b86919b7a94de01d849021b4da820a6cb89dc upstream.
Commit cbd9463da1b1 ("media: v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish") deferred calls to .device_run() to a work queue to avoid recursive calls when a job is finished right away from .device_run(). It failed to update the v4l2_m2m_job_finish() documentation that still states the function must not be called from .device_run(). Fix it.
--- include/media/v4l2-mem2mem.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
include/media/v4l2-mem2mem.h +1 -2
@@ -185,8 +185,7 @@ void v4l2_m2m_try_schedule(struct v4l2_m* other instances to take control of the device. * * This function has to be called only after &v4l2_m2m_ops->device_run -* callback has been called on the driver. To prevent recursion, it should -* not be called directly from the &v4l2_m2m_ops->device_run callback though. +* callback has been called on the driver. */ void v4l2_m2m_job_finish (struct v4l2_m2m_dev *m2m_dev,struct v4l2_m2m_ctx *m2m_ctx);
Greg Kroah-Hartman
maintainerPATCH 229/451 usb: usb-storage: Maintain minimal modifications to the bcdDevice range.
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Changcheng <[email protected]>
commit 0831269b5f71594882accfceb02638124f88955d upstream.
We cannot determine which models require the NO_ATA_1X and IGNORE_RESIDUE quirks aside from the EL-R12 optical drive device.
--- drivers/usb/storage/unusual_uas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/storage/unusual_uas.h +1 -1
@@ -98,7 +98,7 @@ UNUSUAL_DEV(0x125f, 0xa94a, 0x0160, 0x01 US_FL_NO_ATA_1X),/* Reported-by: Benjamin Tissoires <[email protected]> */ -UNUSUAL_DEV(0x13fd, 0x3940, 0x0309, 0x0309, +UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x0309, "Initio Corporation", "INIC-3069", USB_SC_DEVICE, USB_PR_DEVICE, NULL,
Greg Kroah-Hartman
maintainerPATCH 230/451 media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
commit b91e6aafe8d356086cc621bc03e35ba2299e4788 upstream.
rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.
Therefore, we need to add proper range checking to prevent this vuln.
--- drivers/media/usb/dvb-usb/dtv5100.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/media/usb/dvb-usb/dtv5100.c +5 -0
@@ -55,6 +55,11 @@ static int dtv5100_i2c_msg(struct dvb_us } index = (addr <<8 ) + wbuf[0 ]; +if (rlen >sizeof (st->data)) { +warn ("rlen = %x is too big!\n" , rlen); +return -EINVAL ; + } +memcpy (st->data, rbuf, rlen);msleep (1 );/* avoid I2C errors */ return usb_control_msg(d->udev, pipe, request,
Greg Kroah-Hartman
maintainerPATCH 231/451 media: pvrusb2: Fix incorrect variable used in trace message
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
commit be440980eace19c035a0745fd6b6e42707bc4f49 upstream.
The pvr2_trace message is reporting an error about control read transfers, however it is using the incorrect variable write_len instead of read_lean. Fix this by using the correct variable read_len.
--- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/usb/pvrusb2/pvrusb2-hdw.c +1 -1
@@ -3617,7 +3617,7 @@ static int pvr2_send_request_ex(struct ppvr2_trace (PVR2_TRACE_ERROR_LEGS ,"Attempted to execute %d byte control-read transfer (limit=%d)" , - write_len,PVR2_CTL_BUFFSIZE ); + read_len,PVR2_CTL_BUFFSIZE );return -EINVAL ; }if ((!write_len) && (!read_len)) {
Greg Kroah-Hartman
maintainerPATCH 232/451 phy: broadcom: bcm63xx-usbh: fix section mismatches
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 356d1924b9a6bc2164ce2bf1fad147b0c37ae085 upstream.
Platform drivers can be probed after their init sections have been discarded (e.g. on probe deferral or manual rebind through sysfs) so the probe function and match table must not live in init.
--- drivers/phy/broadcom/phy-bcm63xx-usbh.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/phy/broadcom/phy-bcm63xx-usbh.c +3 -3
@@ -374,7 +374,7 @@ static struct phy *bcm63xx_usbh_phy_xlatreturn of_phy_simple_xlate (dev, args); } -static int __init bcm63xx_usbh_phy_probe (struct platform_device *pdev) +static int bcm63xx_usbh_phy_probe (struct platform_device *pdev) {struct device *dev = &pdev->dev;struct bcm63xx_usbh_phy *usbh;
@@ -431,7 +431,7 @@ static int __init bcm63xx_usbh_phy_probereturn 0 ; } -static const struct of_device_id bcm63xx_usbh_phy_ids[]__initconst = { +static const struct of_device_id bcm63xx_usbh_phy_ids[] = { { .compatible ="brcm,bcm6318-usbh-phy" , .data = &usbh_bcm6318 }, { .compatible ="brcm,bcm6328-usbh-phy" , .data = &usbh_bcm6328 }, { .compatible ="brcm,bcm6358-usbh-phy" , .data = &usbh_bcm6358 },
@@ -442,7 +442,7 @@ static const struct of_device_id bcm63xx };MODULE_DEVICE_TABLE (of, bcm63xx_usbh_phy_ids); -static struct platform_driver bcm63xx_usbh_phy_driver__refdata = { +static struct platform_driver bcm63xx_usbh_phy_driver = { .driver = { .name ="bcm63xx-usbh-phy" , .of_match_table = bcm63xx_usbh_phy_ids,
Greg Kroah-Hartman
maintainerPATCH 233/451 USB: lpc32xx_udc: Fix error handling in probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit c84117912bddd9e5d87e68daf182410c98181407 upstream.
lpc32xx_udc_probe() acquires an i2c_client reference through isp1301_get_client() but fails to release it in both error handling paths and the normal removal path. This could result in a reference count leak for the I2C device, preventing proper cleanup and potentially leading to resource exhaustion. Add put_device() to release the reference in the probe failure path and in the remove function.
Calling path: isp1301_get_client() -> of_find_i2c_device_by_node() -> i2c_find_device_by_fwnode(). As comments of i2c_find_device_by_fwnode() says, 'The user must call put_device(&client->dev) once done with the i2c client.'
Found by code review.
--- drivers/usb/gadget/udc/lpc32xx_udc.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
drivers/usb/gadget/udc/lpc32xx_udc.c +15 -6
@@ -3026,7 +3026,7 @@ static int lpc32xx_udc_probe(struct plat pdev->dev.dma_mask = &lpc32xx_usbd_dmamask; retval =dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 ));if (retval) -return retval; + goto i2c_fail; udc->board = &lpc32xx_usbddata;
@@ -3044,28 +3044,32 @@ static int lpc32xx_udc_probe(struct plat/* Get IRQs */ for (i =0 ; i <4 ; i++) { udc->udp_irq[i] =platform_get_irq (pdev, i); -if (udc->udp_irq[i] <0 ) -return udc->udp_irq[i]; +if (udc->udp_irq[i] <0 ) { + retval = udc->udp_irq[i]; + goto i2c_fail; + } } udc->udp_baseaddr =devm_platform_ioremap_resource (pdev,0 );if (IS_ERR (udc->udp_baseaddr)) {dev_err (udc->dev,"IO map failure\n" ); -return PTR_ERR (udc->udp_baseaddr); + retval =PTR_ERR (udc->udp_baseaddr); + goto i2c_fail; }/* Get USB device clock */ udc->usb_slv_clk =devm_clk_get (&pdev->dev,NULL );if (IS_ERR (udc->usb_slv_clk)) {dev_err (udc->dev,"failed to acquire USB device clock\n" ); -return PTR_ERR (udc->usb_slv_clk); + retval =PTR_ERR (udc->usb_slv_clk); + goto i2c_fail; }/* Enable USB device clock */ retval =clk_prepare_enable (udc->usb_slv_clk);if (retval <0 ) {dev_err (udc->dev,"failed to start USB device clock\n" ); -return retval; + goto i2c_fail; }/* Setup deferred workqueue data */
@@ -3167,6 +3171,8 @@ dma_alloc_fail:dma_free_coherent (&pdev->dev,UDCA_BUFF_SIZE , udc->udca_v_base, udc->udca_p_base); i2c_fail: +if (udc->isp1301_i2c_client) +put_device (&udc->isp1301_i2c_client->dev);clk_disable_unprepare (udc->usb_slv_clk);dev_err (udc->dev,"%s probe failed, %d\n" , driver_name, retval);
@@ -3192,6 +3198,9 @@ static int lpc32xx_udc_remove(struct pladma_free_coherent (&pdev->dev,UDCA_BUFF_SIZE , udc->udca_v_base, udc->udca_p_base); +if (udc->isp1301_i2c_client) +put_device (&udc->isp1301_i2c_client->dev); +clk_disable_unprepare (udc->usb_slv_clk);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 234/451 usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit 41ca62e3e21e48c2903b3b45e232cf4f2ff7434f upstream.
The delayed work item otg_event is initialized in fsl_otg_conf() and scheduled under two conditions:
1. When a host controller binds to the OTG controller.
2. When the USB ID pin state changes (cable insertion/removal).
A race condition occurs when the device is removed via fsl_otg_remove():
the fsl_otg instance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work function fsl_otg_event() accesses the already freed memory.
The problematic scenario:
(detach thread) | (delayed work)
fsl_otg_remove() |
kfree(fsl_otg_dev) //FREE| fsl_otg_event()
| og = container_of(...) //USE
| og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove() before deallocating the fsl_otg structure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.
This bug was identified through static analysis.
--- drivers/usb/phy/phy-fsl-usb.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/phy/phy-fsl-usb.c +1 -0
@@ -987,6 +987,7 @@ static int fsl_otg_remove(struct platfor {struct fsl_usb2_platform_data *pdata =dev_get_platdata (&pdev->dev); +disable_delayed_work_sync (&fsl_otg_dev->otg_event);usb_remove_phy (&fsl_otg_dev->phy);free_irq (fsl_otg_dev->irq, fsl_otg_dev);
Re: [PATCH 5.10 234/451] usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal
Quoted 26 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit
41ca62e3e21e48c2903b3b45e232cf4f2ff7434fupstream.The delayed work item
otg_eventis initialized infsl_otg_conf()and scheduled under two conditions:
1. When a host controller binds to the OTG controller.
2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via
fsl_otg_remove():
thefsl_otginstance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work functionfsl_otg_event()accesses the already freed memory.The problematic scenario:
(detach thread) | (delayed work) fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USE
Quoted 3 lines
Fix this by calling
disable_delayed_work_sync()infsl_otg_remove()before deallocating thefsl_otgstructure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.
[...]
The disable_delayed_work_sync() function was only added in 6.10 and has not (yet) been backported anywhere.
So for older branches, either this fix needs to be changed to use cancel_delayed_work_sync() (which I suspect requires reordering some of the cleanup, to be safe) or disable_delayed_work_sync() needs to be backported first.
Ben.
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesGreg Kroah-Hartman
maintainerRe: [PATCH 5.10 234/451] usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal
Quoted 32 lines · Ben Hutchings
Quoted 29 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duoming Zhou <[email protected]>
commit
41ca62e3e21e48c2903b3b45e232cf4f2ff7434fupstream.The delayed work item
otg_eventis initialized infsl_otg_conf()and scheduled under two conditions:
1. When a host controller binds to the OTG controller.
2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via
fsl_otg_remove():
thefsl_otginstance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work functionfsl_otg_event()accesses the already freed memory.The problematic scenario:
(detach thread) | (delayed work) fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling
disable_delayed_work_sync()infsl_otg_remove()before deallocating thefsl_otgstructure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.[...]
Quoted 7 lines
The
disable_delayed_work_sync()function was only added in 6.10 and has not (yet) been backported anywhere.So for older branches, either this fix needs to be changed to use
cancel_delayed_work_sync()(which I suspect requires reordering some of the cleanup, to be safe) ordisable_delayed_work_sync()needs to be backported first.
As no build tests seem to be picking this up, odds are no one uses it :)
I've dropped this now, thanks!
greg k-h
Greg Kroah-Hartman
maintainerPATCH 235/451 usb: dwc3: of-simple: fix clock resource leak in dwc3_of_simple_probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit 3b4961313d31e200c9e974bb1536cdea217f78b5 upstream.
When clk_bulk_prepare_enable() fails, the error path jumps to err_resetc_assert, skipping clk_bulk_put_all() and leaking the clock references acquired by clk_bulk_get_all().
Add err_clk_put_all label to properly release clock resources in all error paths.
Found via static analysis and code review.
--- drivers/usb/dwc3/dwc3-of-simple.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/usb/dwc3/dwc3-of-simple.c +4 -3
@@ -71,11 +71,11 @@ static int dwc3_of_simple_probe(struct p simple->num_clocks = ret; ret =clk_bulk_prepare_enable (simple->num_clocks, simple->clks);if (ret) - goto err_resetc_assert; + goto err_clk_put_all; ret =of_platform_populate (np,NULL ,NULL , dev);if (ret) - goto err_clk_put; + goto err_clk_disable;pm_runtime_set_active (dev);pm_runtime_enable (dev);
@@ -83,8 +83,9 @@ static int dwc3_of_simple_probe(struct preturn 0 ; -err_clk_put: +err_clk_disable:clk_bulk_disable_unprepare (simple->num_clocks, simple->clks); +err_clk_put_all:clk_bulk_put_all (simple->num_clocks, simple->clks); err_resetc_assert:
Greg Kroah-Hartman
maintainerPATCH 236/451 usb: renesas_usbhs: Fix a resource leak in usbhs_pipe_malloc()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit 36cc7e09df9e43db21b46519b740145410dd9f4a upstream.
usbhsp_get_pipe() set pipe's flags to IS_USED. In error paths, usbhsp_put_pipe() is required to clear pipe's flags to prevent pipe exhaustion.
--- drivers/usb/renesas_usbhs/pipe.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/renesas_usbhs/pipe.c +2 -0
@@ -713,11 +713,13 @@ struct usbhs_pipe *usbhs_pipe_malloc(str/* make sure pipe is not busy */ ret =usbhsp_pipe_barrier (pipe);if (ret <0 ) { +usbhsp_put_pipe (pipe);dev_err (dev,"pipe setup failed %d\n" ,usbhs_pipe_number (pipe));return NULL ; }if (usbhsp_setup_pipecfg (pipe, is_host, dir_in, &pipecfg)) { +usbhsp_put_pipe (pipe);dev_err (dev,"can't setup pipe\n" );return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 237/451 char: applicom: fix NULL pointer dereference in ac_ioctl
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tianchu Chen <[email protected]>
commit 82d12088c297fa1cef670e1718b3d24f414c23f7 upstream.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
In ac_ioctl, the validation of IndexCard and the check for a valid RamIO pointer are skipped when cmd is 6. However, the function unconditionally executes readb(apbs[IndexCard].RamIO + VERS) at the end.
If cmd is 6, IndexCard may reference a board that does not exist (where RamIO is NULL), leading to a NULL pointer dereference.
Fix this by skipping the readb access when cmd is 6, as this command is a global information query and does not target a specific board context.
--- drivers/char/applicom.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/char/applicom.c +4 -1
@@ -836,7 +836,10 @@ static long ac_ioctl(struct file *file, ret = -ENOTTY ;break ; } - Dummy =readb (apbs[IndexCard].RamIO +VERS ); + +if (cmd !=6 ) + Dummy =readb (apbs[IndexCard].RamIO +VERS ); +kfree (adgl);mutex_unlock (&ac_mutex);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 238/451 intel_th: Fix error handling in intel_th_output_open
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit 6d5925b667e4ed9e77c8278cc215191d29454a3f upstream.
intel_th_output_open() calls bus_find_device_by_devt() which internally increments the device reference count via get_device(), but this reference is not properly released in several error paths. When device driver is unavailable, file operations cannot be obtained, or the driver's open method fails, the function returns without calling put_device(), leading to a permanent device reference count leak. This prevents the device from being properly released and could cause resource exhaustion over time.
Found by code review.
--- drivers/hwtracing/intel_th/core.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
drivers/hwtracing/intel_th/core.c +15 -5
@@ -810,13 +810,17 @@ static int intel_th_output_open(struct iint err; dev =bus_find_device_by_devt (&intel_th_bus, inode->i_rdev); -if (!dev || !dev->driver) -return -ENODEV ; +if (!dev || !dev->driver) { + err = -ENODEV ; + goto out_no_device; + } thdrv =to_intel_th_driver (dev->driver); fops =fops_get (thdrv->fops); -if (!fops) -return -ENODEV ; +if (!fops) { + err = -ENODEV ; + goto out_put_device; + }replace_fops (file, fops);
@@ -824,10 +828,16 @@ static int intel_th_output_open(struct iif (file->f_op->open) { err = file->f_op->open (inode, file); -return err; +if (err) + goto out_put_device; }return 0 ; + +out_put_device: +put_device (dev); +out_no_device: +return err; }static const struct file_operations intel_th_output_fops = {
Greg Kroah-Hartman
maintainerPATCH 239/451 cpufreq: nforce2: fix reference count leak in nforce2
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit 9600156bb99852c216a2128cdf9f114eb67c350f upstream.
There are two reference count leaks in this driver:
1. In nforce2_fsb_read(): pci_get_subsys() increases the reference count of the PCI device, but pci_dev_put() is never called to release it, thus leaking the reference.
2. In nforce2_detect_chipset(): pci_get_subsys() gets a reference to the nforce2_dev which is stored in a global variable, but the reference is never released when the module is unloaded.
Fix both by:
- Adding pci_dev_put(nforce2_sub5) in nforce2_fsb_read() after reading the configuration.
- Adding pci_dev_put(nforce2_dev) in nforce2_exit() to release the global device reference.
Found via static analysis.
--- drivers/cpufreq/cpufreq-nforce2.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/cpufreq/cpufreq-nforce2.c +3 -0
@@ -145,6 +145,8 @@ static unsigned int nforce2_fsb_read(intpci_read_config_dword (nforce2_sub5,NFORCE2_BOOTFSB , &fsb); fsb /=1000000 ; +pci_dev_put (nforce2_sub5); +/* Check if PLL register is already set */ pci_read_config_byte (nforce2_dev,NFORCE2_PLLENABLE , (u8 *)&temp);
@@ -432,6 +434,7 @@ static int __init nforce2_init(void) static void __exit nforce2_exit(void) {cpufreq_unregister_driver (&nforce2_driver); +pci_dev_put (nforce2_dev); }module_init (nforce2_init);
Greg Kroah-Hartman
maintainerPATCH 240/451 scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Battersby <[email protected]>
commit b57fbc88715b6d18f379463f48a15b560b087ffe upstream.
This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.
The commit being reverted added code to __qla2x00_abort_all_cmds() to call sp->done() without holding a spinlock. But unlike the older code below it, this new code failed to check sp->cmd_type and just assumed TYPE_SRB, which results in a jump to an invalid pointer in target-mode with TYPE_TGT_CMD:
qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success
0000000009f7a79b
qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h
mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.
qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no buffer
qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event
0x8002 occurred
qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -
ha=0000000058183fda.
BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor instruction fetch in kernel mode PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1 Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206 RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000 RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 </TASK>
Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within lock") added the spinlock back, because not having the lock caused a race and a crash. But qla2x00_abort_srb() in the switch below already checks for qla2x00_chip_is_down() and handles it the same way, so the code above the switch is now redundant and still buggy in target-mode. Remove it.
--- drivers/scsi/qla2xxx/qla_os.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +0 -6
@@ -1752,12 +1752,6 @@ __qla2x00_abort_all_cmds(struct qla_qpaifor (cnt =1 ; cnt < req->num_outstanding_cmds; cnt++) { sp = req->outstanding_cmds[cnt];if (sp) { -if (qla2x00_chip_is_down (vha)) { - req->outstanding_cmds[cnt] =NULL ; - sp->done (sp, res); -continue ; - } -switch (sp->cmd_type) {case TYPE_SRB :qla2x00_abort_srb (qp, sp, res, &flags);
Greg Kroah-Hartman
maintainerPATCH 241/451 scsi: aic94xx: fix use-after-free in device removal path
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
commit f6ab594672d4cba08540919a4e6be2e202b60007 upstream.
The asd_pci_remove() function fails to synchronize with pending tasklets before freeing the asd_ha structure, leading to a potential use-after-free vulnerability.
When a device removal is triggered (via hot-unplug or module unload), race condition can occur.
The fix adds tasklet_kill() before freeing the asd_ha structure, ensuring all scheduled tasklets complete before cleanup proceeds.
--- drivers/scsi/aic94xx/aic94xx_init.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/aic94xx/aic94xx_init.c +3 -0
@@ -897,6 +897,9 @@ static void asd_pci_remove(struct pci_deasd_disable_ints (asd_ha); +/* Ensure all scheduled tasklets complete before freeing resources */ +tasklet_kill (&asd_ha->seq.dl_tasklet); +asd_remove_dev_attrs (asd_ha);/* XXX more here as needed */
Greg Kroah-Hartman
maintainerPATCH 242/451 NFSD: use correct reservation type in nfsd4_scsi_fence_client
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dai Ngo <[email protected]>
commit 6f52063db9aabdaabea929b1e998af98c2e8d917 upstream.
The reservation type argument for the pr_preempt call should match the one used in nfsd4_block_get_device_info_scsi.
--- fs/nfsd/blocklayout.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/nfsd/blocklayout.c +2 -1
@@ -410,7 +410,8 @@ nfsd4_scsi_fence_client(struct nfs4_layostruct block_device *bdev = ls->ls_file->nf_file->f_path.mnt->mnt_sb->s_bdev; bdev->bd_disk->fops->pr_ops->pr_preempt (bdev,NFSD_MDS_PR_KEY , -nfsd4_scsi_pr_key (clp),0 , true); +nfsd4_scsi_pr_key (clp), +PR_EXCLUSIVE_ACCESS_REG_ONLY , true); }const struct nfsd4_layout_ops scsi_layout_ops = {
Greg Kroah-Hartman
maintainerPATCH 243/451 scsi: target: Reset t_task_cdb pointer in error case
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Vatoropin <[email protected]>
commit 5053eab38a4c4543522d0c320c639c56a8b59908 upstream.
If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced in the 'err' path.
In case of error, reset NULL t_task_cdb value to point at the default fixed-size buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/target/target_core_transport.c | 1 + 1 file changed, 1 insertion(+)
drivers/target/target_core_transport.c +1 -0
@@ -1449,6 +1449,7 @@ target_cmd_init_cdb(struct se_cmd *cmd, cmd->t_task_cdb =kzalloc (scsi_command_size (cdb),GFP_KERNEL );if (!cmd->t_task_cdb) { + cmd->t_task_cdb = &cmd->__t_task_cdb[0 ]; pr_err("Unable to allocate cmd->t_task_cdb" " %u > sizeof(cmd->__t_task_cdb): %lu ops\n", scsi_command_size(cdb),
Greg Kroah-Hartman
maintainerPATCH 244/451 f2fs: invalidate dentry cache on failed whiteout creation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit d33f89b34aa313f50f9a512d58dd288999f246b0 upstream.
F2FS can mount filesystems with corrupted directory depth values that get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT operations are performed on such directories, f2fs_rename performs directory modifications (updating target entry and deleting source entry) before attempting to add the whiteout entry via f2fs_add_link.
If f2fs_add_link fails due to the corrupted directory structure, the function returns an error to VFS, but the partial directory modifications have already been committed to disk. VFS assumes the entire rename operation failed and does not update the dentry cache, leaving stale mappings.
In the error path, VFS does not call d_move() to update the dentry cache. This results in new_dentry still pointing to the old inode (new_inode) which has already had its i_nlink decremented to zero. The stale cache causes subsequent operations to incorrectly reference the freed inode.
This causes subsequent operations to use cached dentry information that no longer matches the on-disk state. When a second rename targets the same entry, VFS attempts to decrement i_nlink on the stale inode, which may already have i_nlink=0, triggering a WARNING in drop_nlink().
Example sequence:
1. First rename (RENAME_WHITEOUT): file2 → file1
- f2fs updates file1 entry on disk (points to inode 8)
- f2fs deletes file2 entry on disk
- f2fs_add_link(whiteout) fails (corrupted directory)
- Returns error to VFS
- VFS does not call d_move() due to error
- VFS cache still has: file1 → inode 7 (stale!)
- inode 7 has i_nlink=0 (already decremented)
2. Second rename: file3 → file1
- VFS uses stale cache: file1 → inode 7
- Tries to drop_nlink on inode 7 (i_nlink already 0)
- WARNING in drop_nlink()
Fix this by explicitly invalidating old_dentry and new_dentry when f2fs_add_link fails during whiteout creation. This forces VFS to refresh from disk on subsequent operations, ensuring cache consistency even when the rename partially succeeds.
Reproducer:
1. Mount F2FS image with corrupted i_current_depth
2. renameat2(file2, file1, RENAME_WHITEOUT)
3. renameat2(file3, file1, 0)
4. System triggers WARNING in drop_nlink()
--- fs/f2fs/namei.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/f2fs/namei.c +4 -2
@@ -1064,9 +1064,11 @@ static int f2fs_rename(struct inode *oldif (whiteout) {set_inode_flag (whiteout,FI_INC_LINK ); err =f2fs_add_link (old_dentry, whiteout); -if (err) +if (err) { +d_invalidate (old_dentry); +d_invalidate (new_dentry); goto put_out_dir; - + }spin_lock (&whiteout->i_lock); whiteout->i_state &= ~I_LINKABLE ;spin_unlock (&whiteout->i_lock);
Greg Kroah-Hartman
maintainerPATCH 245/451 f2fs: fix return value of f2fs_recover_fsync_data()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit 01fba45deaddcce0d0b01c411435d1acf6feab7b upstream.
With below scripts, it will trigger panic in f2fs:
mkfs.f2fs -f /dev/vdd
mount /dev/vdd /mnt/f2fs
touch /mnt/f2fs/foo
sync
echo 111 >> /mnt/f2fs/foof2fs_io fsync /mnt/f2fs/foof2fs_io shutdown 2 /mnt/f2fs
umount /mnt/f2fs
mount -o ro,norecovery /dev/vdd /mnt/f2fs or
mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0 F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f F2FS-fs (vdd): Stopped filesystem due to reason: 0
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1 Filesystem f2fs get_tree() didn't set fc->root, returned 1
------------[ cut here ]------------ kernel BUG at fs/super.c:1761! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vfs_get_tree.cold+0x18/0x1a Call Trace: <TASK> fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fa6cc126cfe
The root cause is we missed to handle error number returned from f2fs_recover_fsync_data() when mounting image w/ ro,norecovery or ro,disable_roll_forward mount option, result in returning a positive error number to vfs_get_tree(), fix it.
--- fs/f2fs/super.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
fs/f2fs/super.c +9 -5
@@ -3910,11 +3910,15 @@ try_onemore: } }else { err =f2fs_recover_fsync_data (sbi, true); - -if (!f2fs_readonly (sb) && err >0 ) { - err = -EINVAL ; -f2fs_err (sbi,"Need to recover fsync data" ); - goto free_meta; +if (err >0 ) { +if (!f2fs_readonly (sb)) { +f2fs_err (sbi,"Need to recover fsync data" ); + err = -EINVAL ; + goto free_meta; + }else { +f2fs_info (sbi,"drop all fsynced data" ); + err =0 ; + } } }
Greg Kroah-Hartman
maintainerPATCH 246/451 tools/testing/nvdimm: Use per-DIMM device handle
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alison Schofield <[email protected]>
commit f59b701b4674f7955170b54c4167c5590f4714eb upstream.
KASAN reports a global-out-of-bounds access when running these nfit
tests: clear.sh, pmem-errors.sh, pfn-meta-errors.sh, btt-errors.sh, daxdev-errors.sh, and inject-error.sh.
[] BUG: KASAN: global-out-of-bounds in nfit_test_ctl+0x769f/0x7840 [nfit_test] [] Read of size 4 at addr ffffffffc03ea01c by task ndctl/1215
[] The buggy address belongs to the variable:
[] handle+0x1c/0x1df4 [nfit_test]
nfit_test_search_spa() uses handle[nvdimm->id] to retrieve a device handle and triggers a KASAN error when it reads past the end of the handle array. It should not be indexing the handle array at all.
The correct device handle is stored in per-DIMM test data. Each DIMM has a struct nfit_mem that embeds a struct acpi_nfit_memdev that describes the NFIT device handle. Use that device handle here.
--- tools/testing/nvdimm/test/nfit.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
tools/testing/nvdimm/test/nfit.c +6 -1
@@ -673,6 +673,7 @@ static int nfit_test_search_spa(struct n .addr = spa->spa, .region = NULL, }; +struct nfit_mem *nfit_mem;u64 dpa; ret = device_for_each_child(&bus->dev, &ctx,
@@ -690,8 +691,12 @@ static int nfit_test_search_spa(struct n*/ nd_mapping = &nd_region->mapping[nd_region->ndr_mappings -1 ]; nvdimm = nd_mapping->nvdimm; + nfit_mem =nvdimm_provider_data (nvdimm); +if (!nfit_mem) +return -EINVAL ; - spa->devices[0 ].nfit_device_handle = handle[nvdimm->id]; + spa->devices[0 ].nfit_device_handle = +__to_nfit_memdev (nfit_mem)->device_handle; spa->num_nvdimms =1 ; spa->devices[0 ].dpa = dpa;
Greg Kroah-Hartman
maintainerPATCH 247/451 media: vidtv: initialize local pointers upon transfer of memory ownership
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
commit 98aabfe2d79f74613abc2b0b1cef08f97eaf5322 upstream.
vidtv_channel_si_init() creates a temporary list (program, service, event) and ownership of the memory itself is transferred to the PAT/SDT/EIT tables through vidtv_psi_pat_program_assign(), vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().
The problem here is that the local pointer where the memory ownership transfer was completed is not initialized to NULL. This causes the vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and in the flow that jumps to free_eit, the memory that was freed by vidtv_psi_*_table_destroy() can be accessed again by vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it is freed once again.
Therefore, to prevent use-after-free and double-free vulnerability, local pointers must be initialized to NULL when transferring memory ownership.
--- drivers/media/test-drivers/vidtv/vidtv_channel.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/test-drivers/vidtv/vidtv_channel.c +3 -0
@@ -461,12 +461,15 @@ int vidtv_channel_si_init(struct vidtv_m/* assemble all programs and assign to PAT */ vidtv_psi_pat_program_assign (m->si.pat, programs); + programs =NULL ;/* assemble all services and assign to SDT */ vidtv_psi_sdt_service_assign (m->si.sdt, services); + services =NULL ;/* assemble all events and assign to EIT */ vidtv_psi_eit_event_assign (m->si.eit, events); + events =NULL ; m->si.pmt_secs =vidtv_psi_pmt_create_sec_for_each_pat_entry (m->si.pat, m->pcr_pid);
Greg Kroah-Hartman
maintainerPATCH 248/451 ocfs2: fix kernel BUG in ocfs2_find_victim_chain
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prithvi Tambewagh <[email protected]>
commit 039bef30e320827bac8990c9f29d2a68cd8adb5f upstream.
syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the cl_next_free_rec field of the allocation chain list (next free slot in the chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition in ocfs2_find_victim_chain() and panicking the kernel.
To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(), just before calling ocfs2_find_victim_chain(), the code block in it being executed when either of the following conditions is true:
1. cl_next_free_rec is equal to 0, indicating that there are no free chains in the allocation chain list
2. cl_next_free_rec is greater than cl_count (the total number of chains in the allocation chain list)
Either of them being true is indicative of the fact that there are no chains left for usage.
This is addressed using ocfs2_error(), which prints
the error log for debugging purposes, rather than panicking the kernel.
--- fs/ocfs2/suballoc.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
fs/ocfs2/suballoc.c +10 -0
@@ -1925,6 +1925,16 @@ static int ocfs2_claim_suballoc_bits(str } cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; +if (!le16_to_cpu (cl->cl_next_free_rec) || +le16_to_cpu (cl->cl_next_free_rec) >le16_to_cpu (cl->cl_count)) { + status =ocfs2_error (ac->ac_inode->i_sb, +"Chain allocator dinode %llu has invalid next " +"free chain record %u, but only %u total\n" , + (unsigned long long )le64_to_cpu (fe->i_blkno), +le16_to_cpu (cl->cl_next_free_rec), +le16_to_cpu (cl->cl_count)); + goto bail; + } victim =ocfs2_find_victim_chain (cl); ac->ac_chain = victim;
Greg Kroah-Hartman
maintainerPATCH 249/451 platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tzung-Bi Shih <[email protected]>
commit 944edca81e7aea15f83cf9a13a6ab67f711e8abd upstream.
After unbinding the driver, another kthread cros_ec_console_log_work is still accessing the device, resulting an UAF and crash.
The driver doesn't unregister the EC device in .remove() which should shutdown sub-devices synchronously. Fix it.
--- drivers/platform/chrome/cros_ec_ishtp.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/chrome/cros_ec_ishtp.c +1 -0
@@ -714,6 +714,7 @@ static int cros_ec_ishtp_remove(struct icancel_work_sync (&client_data->work_ishtp_reset);cancel_work_sync (&client_data->work_ec_evt); +cros_ec_unregister (client_data->ec_dev);cros_ish_deinit (cros_ish_cl);ishtp_put_device (cl_device);
Greg Kroah-Hartman
maintainerPATCH 250/451 scs: fix a wrong parameter in __scs_magic
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhichi Lin <[email protected]>
commit 08bd4c46d5e63b78e77f2605283874bbe868ab19 upstream.
__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is given. 'task_scs(tsk)' is the starting address of the task's shadow call stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's shadow call stack. Here should be '__scs_magic(task_scs(tsk))'.
The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE is enabled, the shadow call stack usage checking function (scs_check_usage) would scan an incorrect memory range. This could lead to:
1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg.
2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses).
However, since this is purely a debugging feature (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled.
--- kernel/scs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/scs.c +1 -1
@@ -71,7 +71,7 @@ static void scs_check_usage(struct task_if (!IS_ENABLED (CONFIG_DEBUG_STACK_USAGE ))return ; -for (p =task_scs (tsk); p <__scs_magic (tsk); ++p) { +for (p =task_scs (tsk); p <__scs_magic (task_scs (tsk)); ++p) {if (!READ_ONCE_NOCHECK (*p))break ; used +=sizeof (*p);
Greg Kroah-Hartman
maintainerPATCH 251/451 parisc: Do not reprogram affinitiy on ASP chip
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit dca7da244349eef4d78527cafc0bf80816b261f5 upstream.
The ASP chip is a very old variant of the GSP chip and is used e.g. in HP 730 workstations. When trying to reprogram the affinity it will crash with a HPMC as the relevant registers don't seem to be at the usual location. Let's avoid the crash by checking the sversion. Also note, that reprogramming isn't necessary either, as the HP730 is a just a single-CPU machine.
--- drivers/parisc/gsc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/parisc/gsc.c +3 -1
@@ -154,7 +154,9 @@ static int gsc_set_affinity_irq(struct i gsc_dev->eim = ((u32 ) gsc_dev->gsc_irq.txn_addr) | gsc_dev->gsc_irq.txn_data;/* switch IRQ's for devices below LASI/WAX to other CPU */ -gsc_writel (gsc_dev->eim, gsc_dev->hpa +OFFSET_IAR ); +/* ASP chip (svers 0x70) does not support reprogramming */ +if (gsc_dev->gsc->id.sversion !=0x70 ) +gsc_writel (gsc_dev->eim, gsc_dev->hpa +OFFSET_IAR );irq_data_update_effective_affinity (d, &tmask);
Greg Kroah-Hartman
maintainerPATCH 252/451 libceph: make decode_pool() more resilient against corrupted osdmaps
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 8c738512714e8c0aa18f8a10c072d5b01c83db39 upstream.
If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.
This patch adds explicit bounds checks for each field that is decoded or skipped.
--- net/ceph/osdmap.c | 118 ++++++++++++++++++++++++------------------------------ 1 file changed, 53 insertions(+), 65 deletions(-)
net/ceph/osdmap.c +53 -65
@@ -790,51 +790,49 @@ static int decode_pool(void **p, void *eceph_decode_need (p, end, len, bad); pool_end = *p + len; +ceph_decode_need (p, end,4 +4 +4 , bad); pi->type =ceph_decode_8 (p); pi->size =ceph_decode_8 (p); pi->crush_ruleset =ceph_decode_8 (p); pi->object_hash =ceph_decode_8 (p); - pi->pg_num =ceph_decode_32 (p); pi->pgp_num =ceph_decode_32 (p); - *p +=4 +4 ;/* skip lpg* */ - *p +=4 ;/* skip last_change */ - *p +=8 +4 ;/* skip snap_seq, snap_epoch */ +/* lpg*, last_change, snap_seq, snap_epoch */ +ceph_decode_skip_n (p, end,8 +4 +8 +4 , bad);/* skip snaps */ - num =ceph_decode_32 (p); +ceph_decode_32_safe (p, end, num, bad);while (num--) { - *p +=8 ;/* snapid key */ - *p +=1 +1 ;/* versions */ - len =ceph_decode_32 (p); - *p += len; +/* snapid key, pool snap (with versions) */ +ceph_decode_skip_n (p, end,8 +2 , bad); +ceph_decode_skip_string (p, end, bad); } -/* skip removed_snaps */ - num =ceph_decode_32 (p); - *p += num * (8 +8 ); +/* removed_snaps */ +ceph_decode_skip_map (p, end,64 ,64 , bad); +ceph_decode_need (p, end,8 +8 +4 , bad); *p +=8 ;/* skip auid */ pi->flags =ceph_decode_64 (p); *p +=4 ;/* skip crash_replay_interval */ if (ev >=7 ) - pi->min_size =ceph_decode_8 (p); +ceph_decode_8_safe (p, end, pi->min_size, bad);else pi->min_size = pi->size - pi->size /2 ;if (ev >=8 ) - *p +=8 +8 ;/* skip quota_max_* */ +/* quota_max_* */ +ceph_decode_skip_n (p, end,8 +8 , bad);if (ev >=9 ) { -/* skip tiers */ - num =ceph_decode_32 (p); - *p += num *8 ; +/* tiers */ +ceph_decode_skip_set (p, end,64 , bad); +ceph_decode_need (p, end,8 +1 +8 +8 , bad); *p +=8 ;/* skip tier_of */ *p +=1 ;/* skip cache_mode */ - pi->read_tier =ceph_decode_64 (p); pi->write_tier =ceph_decode_64 (p); }else {
@@ -842,86 +840,76 @@ static int decode_pool(void **p, void *e pi->write_tier =-1 ; } -if (ev >=10 ) { -/* skip properties */ - num =ceph_decode_32 (p); -while (num--) { - len =ceph_decode_32 (p); - *p += len;/* key */ - len =ceph_decode_32 (p); - *p += len;/* val */ - } - } +if (ev >=10 ) +/* properties */ +ceph_decode_skip_map (p, end, string, string, bad);if (ev >=11 ) { -/* skip hit_set_params */ - *p +=1 +1 ;/* versions */ - len =ceph_decode_32 (p); - *p += len; +/* hit_set_params (with versions) */ +ceph_decode_skip_n (p, end,2 , bad); +ceph_decode_skip_string (p, end, bad); - *p +=4 ;/* skip hit_set_period */ - *p +=4 ;/* skip hit_set_count */ +/* hit_set_period, hit_set_count */ +ceph_decode_skip_n (p, end,4 +4 , bad); }if (ev >=12 ) - *p +=4 ;/* skip stripe_width */ +/* stripe_width */ +ceph_decode_skip_32 (p, end, bad); -if (ev >=13 ) { - *p +=8 ;/* skip target_max_bytes */ - *p +=8 ;/* skip target_max_objects */ - *p +=4 ;/* skip cache_target_dirty_ratio_micro */ - *p +=4 ;/* skip cache_target_full_ratio_micro */ - *p +=4 ;/* skip cache_min_flush_age */ - *p +=4 ;/* skip cache_min_evict_age */ - } - -if (ev >=14 ) { -/* skip erasure_code_profile */ - len =ceph_decode_32 (p); - *p += len; - } +if (ev >=13 ) +/* target_max_*, cache_target_*, cache_min_* */ +ceph_decode_skip_n (p, end,16 +8 +8 , bad); + +if (ev >=14 ) +/* erasure_code_profile */ +ceph_decode_skip_string (p, end, bad);/* * last_force_op_resend_preluminous, will be overridden if the * map was encoded with RESEND_ON_SPLIT */ if (ev >=15 ) - pi->last_force_request_resend =ceph_decode_32 (p); +ceph_decode_32_safe (p, end, pi->last_force_request_resend, bad);else pi->last_force_request_resend =0 ;if (ev >=16 ) - *p +=4 ;/* skip min_read_recency_for_promote */ +/* min_read_recency_for_promote */ +ceph_decode_skip_32 (p, end, bad);if (ev >=17 ) - *p +=8 ;/* skip expected_num_objects */ +/* expected_num_objects */ +ceph_decode_skip_64 (p, end, bad);if (ev >=19 ) - *p +=4 ;/* skip cache_target_dirty_high_ratio_micro */ +/* cache_target_dirty_high_ratio_micro */ +ceph_decode_skip_32 (p, end, bad);if (ev >=20 ) - *p +=4 ;/* skip min_write_recency_for_promote */ +/* min_write_recency_for_promote */ +ceph_decode_skip_32 (p, end, bad);if (ev >=21 ) - *p +=1 ;/* skip use_gmt_hitset */ +/* use_gmt_hitset */ +ceph_decode_skip_8 (p, end, bad);if (ev >=22 ) - *p +=1 ;/* skip fast_read */ +/* fast_read */ +ceph_decode_skip_8 (p, end, bad); -if (ev >=23 ) { - *p +=4 ;/* skip hit_set_grade_decay_rate */ - *p +=4 ;/* skip hit_set_search_last_n */ - } +if (ev >=23 ) +/* hit_set_grade_decay_rate, hit_set_search_last_n */ +ceph_decode_skip_n (p, end,4 +4 , bad);if (ev >=24 ) { -/* skip opts */ - *p +=1 +1 ;/* versions */ - len =ceph_decode_32 (p); - *p += len; +/* opts (with versions) */ +ceph_decode_skip_n (p, end,2 , bad); +ceph_decode_skip_string (p, end, bad); }if (ev >=25 ) - pi->last_force_request_resend =ceph_decode_32 (p); +ceph_decode_32_safe (p, end, pi->last_force_request_resend, bad);/* ignore the rest */
Greg Kroah-Hartman
maintainerPATCH 253/451 KVM: x86: WARN if hrtimer callback for periodic APIC timer fires with period=0
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit 0ea9494be9c931ddbc084ad5e11fda91b554cf47 upstream.
WARN and don't restart the hrtimer if KVM's callback runs with the guest's APIC timer in periodic mode but with a period of '0', as not advancing the hrtimer's deadline would put the CPU into an infinite loop of hrtimer events. Observing a period of '0' should be impossible, even when the hrtimer is running on a different CPU than the vCPU, as KVM is supposed to cancel the hrtimer before changing (or zeroing) the period, e.g. when switching from periodic to one-shot.
--- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/lapic.c +1 -1
@@ -2434,7 +2434,7 @@ static enum hrtimer_restart apic_timer_fapic_timer_expired (apic, true); -if (lapic_is_periodic (apic)) { +if (lapic_is_periodic (apic) && !WARN_ON_ONCE (!apic->lapic_timer.period)) {advance_periodic_target_expiration (apic);hrtimer_add_expires_ns (&ktimer->timer, ktimer->period);return HRTIMER_RESTART ;
Greg Kroah-Hartman
maintainerPATCH 254/451 KVM: x86: Explicitly set new periodic hrtimer expiration in apic_timer_fn()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: fuqiang wang <[email protected]>
commit 9633f180ce994ab293ce4924a9b7aaf4673aa114 upstream.
When restarting an hrtimer to emulate a the guest's APIC timer in periodic mode, explicitly set the expiration using the target expiration computed by advance_periodic_target_expiration() instead of adding the period to the existing timer. This will allow making adjustments to the expiration, e.g. to deal with expirations far in the past, without having to implement the same logic in both advance_periodic_target_expiration() and apic_timer_fn().
--- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/lapic.c +1 -1
@@ -2436,7 +2436,7 @@ static enum hrtimer_restart apic_timer_fif (lapic_is_periodic (apic) && !WARN_ON_ONCE (!apic->lapic_timer.period)) {advance_periodic_target_expiration (apic); -hrtimer_add_expires_ns (&ktimer->timer, ktimer->period); +hrtimer_set_expires (&ktimer->timer, ktimer->target_expiration);return HRTIMER_RESTART ; }else return HRTIMER_NORESTART ;
Greg Kroah-Hartman
maintainerPATCH 255/451 KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: fuqiang wang <[email protected]>
commit 18ab3fc8e880791aa9f7c000261320fc812b5465 upstream.
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45
...
RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in perpetuity.
--- arch/x86/kvm/lapic.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-)
arch/x86/kvm/lapic.c +23 -5
@@ -1790,15 +1790,33 @@ static void advance_periodic_target_expiktime_t delta;/* -* Synchronize both deadlines to the same time source or -* differences in the periods (caused by differences in the -* underlying clocks or numerical approximation errors) will -* cause the two to drift apart over time as the errors -* accumulate. +* Use kernel time as the time source for both the hrtimer deadline and +* TSC-based deadline so that they stay synchronized. Computing each +* deadline independently will cause the two deadlines to drift apart +* over time as differences in the periods accumulate, e.g. due to +* differences in the underlying clocks or numerical approximation errors. */ apic->lapic_timer.target_expiration =ktime_add_ns (apic->lapic_timer.target_expiration, apic->lapic_timer.period); + +/* +* If the new expiration is in the past, e.g. because userspace stopped +* running the VM for an extended duration, then force the expiration +* to "now" and don't try to play catch-up with the missed events. KVM +* will only deliver a single interrupt regardless of how many events +* are pending, i.e. restarting the timer with an expiration in the +* past will do nothing more than waste host cycles, and can even lead +* to a hard lockup in extreme cases. +*/ +if (ktime_before (apic->lapic_timer.target_expiration, now)) + apic->lapic_timer.target_expiration = now; + +/* +* Note, ensuring the expiration isn't in the past also prevents delta +* from going negative, which could cause the TSC deadline to become +* excessively large due to it an unsigned value. +*/ delta =ktime_sub (apic->lapic_timer.target_expiration, now); apic->lapic_timer.tscdeadline =kvm_read_l1_tsc (apic->vcpu, tscl) +nsec_to_cycles (apic->vcpu, delta);
Greg Kroah-Hartman
maintainerPATCH 256/451 KVM: nSVM: Propagate SVM_EXIT_CR0_SEL_WRITE correctly for LMSW emulation
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yosry Ahmed <[email protected]>
commit 5674a76db0213f9db1e4d08e847ff649b46889c0 upstream.
When emulating L2 instructions, svm_check_intercept() checks whether a write to CR0 should trigger a synthesized #VMEXIT with SVM_EXIT_CR0_SEL_WRITE. For MOV-to-CR0, SVM_EXIT_CR0_SEL_WRITE is only triggered if any bit other than CR0.MP and CR0.TS is updated. However, according to the APM (24593—Rev. 3.42—March 2024, Table 15-7):
The LMSW instruction treats the selective CR0-write intercept as a non-selective intercept (i.e., it intercepts regardless of the value being written).
Skip checking the changed bits for x86_intercept_lmsw and always inject SVM_EXIT_CR0_SEL_WRITE.
--- arch/x86/kvm/svm/svm.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/x86/kvm/svm/svm.c +9 -9
@@ -3900,20 +3900,20 @@ static int svm_check_intercept(struct kv INTERCEPT_SELECTIVE_CR0)))break ; - cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK ; - val = info->src_val & ~SVM_CR0_SELECTIVE_MASK ; - +/* LMSW always triggers INTERCEPT_SELECTIVE_CR0 */ if (info->intercept == x86_intercept_lmsw) { - cr0 &=0xfUL ; - val &=0xfUL ; -/* lmsw can't clear PE - catch this here */ -if (cr0 &X86_CR0_PE ) - val |=X86_CR0_PE ; + icpt_info.exit_code =SVM_EXIT_CR0_SEL_WRITE ; +break ; } +/* +* MOV-to-CR0 only triggers INTERCEPT_SELECTIVE_CR0 if any bit +* other than SVM_CR0_SELECTIVE_MASK is changed. +*/ + cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK ; + val = info->src_val & ~SVM_CR0_SELECTIVE_MASK ;if (cr0 ^ val) icpt_info.exit_code =SVM_EXIT_CR0_SEL_WRITE ; -break ; }case SVM_EXIT_READ_DR0 :
Greg Kroah-Hartman
maintainerPATCH 257/451 KVM: nSVM: Set exit_code_hi to -1 when synthesizing SVM_EXIT_ERR (failed VMRUN)
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
commit f402ecd7a8b6446547076f4bd24bd5d4dcc94481 upstream.
Set exit_code_hi to -1u as a temporary band-aid to fix a long-standing (effectively since KVM's inception) bug where KVM treats the exit code as a 32-bit value, when in reality it's a 64-bit value. Per the APM, offset 0x70 is a single 64-bit value:
070h 63:0 EXITCODE
And a sane reading of the error values defined in "Table C-1. SVM Intercept Codes" is that negative values use the full 64 bits:
–1 VMEXIT_INVALID Invalid guest state in VMCB.
–2 VMEXIT_BUSYBUSY bit was set in the VMSA
–3 VMEXIT_IDLE_REQUIREDThe sibling thread is not in an idle state -4 VMEXIT_INVALID_PMC Invalid PMC state
And that interpretation is confirmed by testing on Milan and Turin (by setting bits in CR0[63:32] to generate VMEXIT_INVALID on VMRUN).
Furthermore, Xen has treated exitcode as a 64-bit value since HVM support was adding in 2006 (see Xen commit d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")).
--- arch/x86/kvm/svm/nested.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kvm/svm/nested.c +2 -2
@@ -528,7 +528,7 @@ int nested_svm_vmrun(struct vcpu_svm *svif (!nested_vmcb_check_save (svm, vmcb12) || !nested_vmcb_check_controls (&svm->nested.ctl)) { vmcb12->control.exit_code =SVM_EXIT_ERR ; - vmcb12->control.exit_code_hi =0 ; + vmcb12->control.exit_code_hi =-1u ; vmcb12->control.exit_info_1 =0 ; vmcb12->control.exit_info_2 =0 ; goto out;
@@ -587,7 +587,7 @@ out_exit_err: svm->nested.nested_run_pending =0 ; svm->vmcb->control.exit_code =SVM_EXIT_ERR ; - svm->vmcb->control.exit_code_hi =0 ; + svm->vmcb->control.exit_code_hi =-1u ; svm->vmcb->control.exit_info_1 =0 ; svm->vmcb->control.exit_info_2 =0 ;
Greg Kroah-Hartman
maintainerPATCH 258/451 tracing: Do not register unsupported perf events
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit ef7f38df890f5dcd2ae62f8dbde191d72f3bebae upstream.
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.
--- kernel/trace/trace_events.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/trace/trace_events.c +2 -0
@@ -303,6 +303,8 @@ int trace_event_reg(struct trace_event_c#ifdef CONFIG_PERF_EVENTS case TRACE_REG_PERF_REGISTER : +if (!call->class->perf_probe) +return -ENODEV ;return tracepoint_probe_register (call->tp, call->class->perf_probe, call);
Greg Kroah-Hartman
maintainerPATCH 259/451 PM: runtime: Do not clear needs_force_resume with enabled runtime PM
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit 359afc8eb02a518fbdd0cbd462c8c2827c6cbec2 upstream.
Commit 89d9cec3b1e9 ("PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()") added provisional clearing of power.needs_force_resume to pm_runtime_reinit(), but it is done unconditionally which is a mistake because pm_runtime_reinit() may race with driver probing and removal [1].
To address this, notice that power.needs_force_resume should never be set when runtime PM is enabled and so it only needs to be cleared when runtime PM is disabled, and update pm_runtime_init() to only clear that flag when runtime PM is disabled.
--- drivers/base/power/runtime.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
drivers/base/power/runtime.c +12 -10
@@ -1749,16 +1749,18 @@ void pm_runtime_init(struct device *dev)*/ void pm_runtime_reinit (struct device *dev) { -if (!pm_runtime_enabled (dev)) { -if (dev->power.runtime_status ==RPM_ACTIVE ) -pm_runtime_set_suspended (dev); -if (dev->power.irq_safe) { -spin_lock_irq (&dev->power.lock); - dev->power.irq_safe =0 ; -spin_unlock_irq (&dev->power.lock); -if (dev->parent) -pm_runtime_put (dev->parent); - } +if (pm_runtime_enabled (dev)) +return ; + +if (dev->power.runtime_status ==RPM_ACTIVE ) +pm_runtime_set_suspended (dev); + +if (dev->power.irq_safe) { +spin_lock_irq (&dev->power.lock); + dev->power.irq_safe =0 ; +spin_unlock_irq (&dev->power.lock); +if (dev->parent) +pm_runtime_put (dev->parent); }/* * Clear power.needs_force_resume in case it has been set by
Greg Kroah-Hartman
maintainerPATCH 260/451 fsnotify: do not generate ACCESS/MODIFY events on child for special files
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amir Goldstein <[email protected]>
commit 635bc4def026a24e071436f4f356ea08c0eed6ff upstream.
inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).
Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.
The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().
Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].
[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
--- fs/notify/fsnotify.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
fs/notify/fsnotify.c +8 -1
@@ -224,8 +224,15 @@ int __fsnotify_parent(struct dentry *den/* * Include parent/name in notification either if some notification * groups require parent info or the parent is interested in this event. +* The parent interest in ACCESS/MODIFY events does not apply to special +* files, where read/write are not on the filesystem of the parent and +* events can provide an undesirable side-channel for information +* exfiltration. */ - parent_interested = mask & p_mask &ALL_FSNOTIFY_EVENTS ; + parent_interested = mask & p_mask &ALL_FSNOTIFY_EVENTS && + !(data_type ==FSNOTIFY_EVENT_PATH && +d_is_special (dentry) && + (mask & (FS_ACCESS |FS_MODIFY )));if (parent_needed || parent_interested) {/* When notifying parent, child should be passed as data */ WARN_ON_ONCE (inode !=fsnotify_data_inode (data, data_type));
Greg Kroah-Hartman
maintainerPATCH 261/451 nfsd: Mark variable __maybe_unused to avoid W=1 build break
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit ebae102897e760e9e6bc625f701dd666b2163bd1 upstream.
Clang is not happy about set but (in some cases) unused variable:
fs/nfsd/export.c:1027:17: error: variable 'inode' set but not used [-Werror,-Wunused-but-set-variable]
since it's used as a parameter to dprintk() which might be configured a no-op. To avoid uglifying code with the specific ifdeffery just mark the variable __maybe_unused.
The commit [1], which introduced this behaviour, is quite old and hence the Fixes tag points to the first of the Git era.
--- fs/nfsd/export.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/export.c +1 -1
@@ -984,7 +984,7 @@ exp_rootfh(struct net *net, struct auth_ {struct svc_export *exp;struct path path; -struct inode *inode; +struct inode *inode__maybe_unused ;struct svc_fh fh;int err;struct nfsd_net *nn =net_generic (net, nfsd_net_id);
Greg Kroah-Hartman
maintainerPATCH 262/451 io_uring: fix filename leak in __io_openat_prep()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prithvi Tambewagh <[email protected]>
__io_openat_prep() allocates a struct filename using getname(). However,
for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.
--- io_uring/io_uring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/io_uring.c +1 -1
@@ -4178,13 +4178,13 @@ static int __io_openat_prep(struct io_ki req->open.filename =NULL ;return ret; } + req->flags |=REQ_F_NEED_CLEANUP ; req->open.file_slot =READ_ONCE (sqe->file_index);if (req->open.file_slot && (req->open.how.flags &O_CLOEXEC ))return -EINVAL ; req->open.nofile =rlimit (RLIMIT_NOFILE ); - req->flags |=REQ_F_NEED_CLEANUP ;return 0 ; }
Re: [PATCH 5.10 262/451] io_uring: fix filename leak in __io_openat_prep()
Quoted 4 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 8 lines
From: Prithvi Tambewagh <[email protected]>
__io_openat_prep()allocates a struct filename usinggetname(). However,
for the condition of the file being installed in the fixed file table as well as havingO_CLOEXECflag set, the function returns early. At that point, the request doesn't haveREQ_F_NEED_CLEANUPflag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
[...]
This patch is missing a reference to the upstream commit (b14fad555302a2104948feaff70503b64c80ac01).
Ben.
Signature · 2 lines
Ben Hutchings Larkinson's Law: All laws are basically false.
Greg Kroah-Hartman
maintainerRe: [PATCH 5.10 262/451] io_uring: fix filename leak in __io_openat_prep()
Quoted 13 lines · Ben Hutchings
Quoted 4 lines · Greg Kroah-Hartman
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 8 lines
From: Prithvi Tambewagh <[email protected]>
__io_openat_prep()allocates a struct filename usinggetname(). However,
for the condition of the file being installed in the fixed file table as well as havingO_CLOEXECflag set, the function returns early. At that point, the request doesn't haveREQ_F_NEED_CLEANUPflag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.
Quoted 4 lines
[...]
This patch is missing a reference to the upstream commit (
b14fad555302a2104948feaff70503b64c80ac01).
Oops, don't know where that went, will go add it now, thanks!
greg k-h
Greg Kroah-Hartman
maintainerPATCH 263/451 drm/amd/display: Use GFP_ATOMIC in dc_create_plane_state()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 3c41114dcdabb7b25f5bc33273c6db9c7af7f4a7 upstream.
This can get called from an atomic context.
--- drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/core/dc_surface.c +1 -1
@@ -104,7 +104,7 @@ void enable_surface_flip_reporting(strucstruct dc_plane_state *dc_create_plane_state (struct dc *dc) {struct dc_plane_state *plane_state =kvzalloc (sizeof (*plane_state), -GFP_KERNEL ); +GFP_ATOMIC );if (NULL == plane_state)return NULL ;
Greg Kroah-Hartman
maintainerPATCH 264/451 amba: tegra-ahb: Fix device leak on SMMU enable
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 500e1368e46928f4b2259612dcabb6999afae2a6 upstream.
Make sure to drop the reference taken to the AHB platform device when looking up its driver data while enabling the SMMU.
Note that holding a reference to a device does not prevent its driver data from going away.
--- drivers/amba/tegra-ahb.c | 1 + 1 file changed, 1 insertion(+)
drivers/amba/tegra-ahb.c +1 -0
@@ -144,6 +144,7 @@ int tegra_ahb_enable_smmu(struct device_if (!dev)return -EPROBE_DEFER ; ahb =dev_get_drvdata (dev); +put_device (dev); val =gizmo_readl (ahb,AHB_ARBITRATION_XBAR_CTRL ); val |=AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE ;gizmo_writel (ahb, val,AHB_ARBITRATION_XBAR_CTRL );
Greg Kroah-Hartman
maintainerPATCH 265/451 soc: qcom: ocmem: fix device leak on lookup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit b5c16ea57b030b8e9428ec726e26219dfe05c3d9 upstream.
Make sure to drop the reference taken to the ocmem platform device when looking up its driver data.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
Also note that commit 0ff027027e05 ("soc: qcom: ocmem: Fix missing put_device() call in of_get_ocmem") fixed the leak in a lookup error path, but the reference is still leaking on success.
--- drivers/soc/qcom/ocmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/qcom/ocmem.c +1 -1
@@ -211,9 +211,9 @@ struct ocmem *of_get_ocmem(struct deviceof_node_put (devnode); ocmem =platform_get_drvdata (pdev); +put_device (&pdev->dev);if (!ocmem) {dev_err (dev,"Cannot get ocmem\n" ); -put_device (&pdev->dev);return ERR_PTR (-ENODEV ); }return ocmem;
Greg Kroah-Hartman
maintainerPATCH 266/451 soc: amlogic: canvas: fix device leak on lookup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 32200f4828de9d7e6db379909898e718747f4e18 upstream.
Make sure to drop the reference taken to the canvas platform device when looking up its driver data.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
Also note that commit 28f851e6afa8 ("soc: amlogic: canvas: add missing put_device() call in meson_canvas_get()") fixed the leak in a lookup error path, but the reference is still leaking on success.
--- drivers/soc/amlogic/meson-canvas.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/soc/amlogic/meson-canvas.c +2 -3
@@ -72,10 +72,9 @@ struct meson_canvas *meson_canvas_get(st* current state, this driver probe cannot return -EPROBE_DEFER */ canvas =dev_get_drvdata (&canvas_pdev->dev); -if (!canvas) { -put_device (&canvas_pdev->dev); +put_device (&canvas_pdev->dev); +if (!canvas)return ERR_PTR (-EINVAL ); - }return canvas; }
Greg Kroah-Hartman
maintainerPATCH 267/451 rpmsg: glink: fix rpmsg device leak
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
commit a53e356df548f6b0e82529ef3cc6070f42622189 upstream.
While testing rpmsg-char interface it was noticed that duplicate sysfs entries are getting created and below warning is noticed.
Reason for this is that we are leaking rpmsg device pointer, setting it null without actually unregistering device.
Any further attempts to unregister fail because rpdev is NULL, resulting in a leak.
Fix this by unregistering rpmsg device before removing its reference from rpmsg channel.
sysfs: cannot create duplicate filename '/devices/platform/soc@0/3700000.remot eproc/remoteproc/remoteproc1/3700000.remoteproc:glink-edge/3700000.remoteproc:
glink-edge.adsp_apps.-1.-1'
[ 114.115347] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.16.0-rc4 #7 PREEMPT [ 114.115355] Hardware name: Qualcomm Technologies, Inc. Robotics RB3gen2 (DT) [ 114.115358] Workqueue: events qcom_glink_work [ 114.115371] Call trace:8 [ 114.115374] show_stack+0x18/0x24 (C) [ 114.115382] dump_stack_lvl+0x60/0x80 [ 114.115388] dump_stack+0x18/0x24 [ 114.115393] sysfs_warn_dup+0x64/0x80 [ 114.115402] sysfs_create_dir_ns+0xf4/0x120 [ 114.115409] kobject_add_internal+0x98/0x260 [ 114.115416] kobject_add+0x9c/0x108 [ 114.115421] device_add+0xc4/0x7a0 [ 114.115429] rpmsg_register_device+0x5c/0xb0 [ 114.115434] qcom_glink_work+0x4bc/0x820 [ 114.115438] process_one_work+0x148/0x284 [ 114.115446] worker_thread+0x2c4/0x3e0 [ 114.115452] kthread+0x12c/0x204 [ 114.115457] ret_from_fork+0x10/0x20 [ 114.115464] kobject: kobject_add_internal failed for 3700000.remoteproc: glink-edge.adsp_apps.-1.-1 with -EEXIST, don't try to register things with the same name in the same directory. [ 114.250045] rpmsg 3700000.remoteproc:glink-edge.adsp_apps.-1.-1:
device_add failed: -17
--- drivers/rpmsg/qcom_glink_native.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/rpmsg/qcom_glink_native.c +8 -0
@@ -1244,6 +1244,7 @@ static void qcom_glink_destroy_ept(struc {struct glink_channel *channel =to_glink_channel (ept);struct qcom_glink *glink = channel->glink; +struct rpmsg_channel_info chinfo;unsigned long flags;spin_lock_irqsave (&channel->recv_lock, flags);
@@ -1251,6 +1252,13 @@ static void qcom_glink_destroy_ept(strucspin_unlock_irqrestore (&channel->recv_lock, flags);/* Decouple the potential rpdev from the channel */ +if (channel->rpdev) { +strscpy_pad (chinfo.name, channel->name,sizeof (chinfo.name)); + chinfo.src =RPMSG_ADDR_ANY ; + chinfo.dst =RPMSG_ADDR_ANY ; + +rpmsg_unregister_device (glink->dev, &chinfo); + } channel->rpdev =NULL ;qcom_glink_send_close_req (glink, channel);
Greg Kroah-Hartman
maintainerPATCH 268/451 i2c: amd-mp2: fix reference leak in MP2 PCI device
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit a6ee6aac66fb394b7f6e6187c73bdcd873f2d139 upstream.
In i2c_amd_probe(), amd_mp2_find_device() utilizes driver_find_next_device() which internally calls driver_find_device() to locate the matching device. driver_find_device() increments the reference count of the found device by calling get_device(), but amd_mp2_find_device() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the PCI device each time i2c_amd_probe() is executed, which may prevent the device from being properly released and cause a memory leak.
Found by code review.
--- drivers/i2c/busses/i2c-amd-mp2-pci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-amd-mp2-pci.c +4 -1
@@ -461,13 +461,16 @@ struct amd_mp2_dev *amd_mp2_find_device( {struct device *dev;struct pci_dev *pci_dev; +struct amd_mp2_dev *mp2_dev; dev =driver_find_next_device (&amd_mp2_pci_driver.driver,NULL );if (!dev)return NULL ; pci_dev =to_pci_dev (dev); -return (struct amd_mp2_dev *)pci_get_drvdata (pci_dev); + mp2_dev = (struct amd_mp2_dev *)pci_get_drvdata (pci_dev); +put_device (dev); +return mp2_dev; }EXPORT_SYMBOL_GPL (amd_mp2_find_device);
Greg Kroah-Hartman
maintainerPATCH 269/451 hwmon: (w83791d) Convert macros to functions to avoid TOCTOU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gui-Dong Han <[email protected]>
commit 670d7ef945d3a84683594429aea6ab2cdfa5ceb4 upstream.
The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors.
Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions.
Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data.
Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts.
--- drivers/hwmon/w83791d.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/hwmon/w83791d.c +11 -6
@@ -218,9 +218,14 @@ static u8 fan_to_reg(long rpm, int div)return clamp_val ((1350000 + rpm * div /2 ) / (rpm * div),1 ,254 ); } -#define FAN_FROM_REG (val, div) ((val) == 0 ? -1 : \ - ((val) == 255 ? 0 : \ - 1350000 / ((val) * (div)))) +static int fan_from_reg (int val,int div) +{ +if (val ==0 ) +return -1 ; +if (val ==255 ) +return 0 ; +return 1350000 / (val * div); +}/* for temp1 which is 8-bit resolution, LSB = 1 degree Celsius */ #define TEMP1_FROM_REG (val) ((val) * 1000)
@@ -521,7 +526,7 @@ static ssize_t show_##reg(struct devicestruct w83791d_data *data =w83791d_update_device (dev); \int nr = sensor_attr->index; \return sprintf (buf,"%d\n" , \ -FAN_FROM_REG (data->reg[nr],DIV_FROM_REG (data->fan_div[nr]))); \ +fan_from_reg (data->reg[nr],DIV_FROM_REG (data->fan_div[nr]))); \ }show_fan_reg (fan);
@@ -585,10 +590,10 @@ static ssize_t store_fan_div(struct deviif (err)return err; +mutex_lock (&data->update_lock);/* Save fan_min */ - min =FAN_FROM_REG (data->fan_min[nr],DIV_FROM_REG (data->fan_div[nr])); + min =fan_from_reg (data->fan_min[nr],DIV_FROM_REG (data->fan_div[nr])); -mutex_lock (&data->update_lock); data->fan_div[nr] =div_to_reg (nr, val);switch (nr) {
Greg Kroah-Hartman
maintainerPATCH 270/451 hwmon: (w83l786ng) Convert macros to functions to avoid TOCTOU
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gui-Dong Han <[email protected]>
commit 07272e883fc61574b8367d44de48917f622cdd83 upstream.
The macros FAN_FROM_REG and TEMP_FROM_REG evaluate their arguments multiple times. When used in lockless contexts involving shared driver data, this causes Time-of-Check to Time-of-Use (TOCTOU) race conditions.
Convert the macros to static functions. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions.
Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts.
--- drivers/hwmon/w83l786ng.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)
drivers/hwmon/w83l786ng.c +18 -8
@@ -77,15 +77,25 @@ FAN_TO_REG(long rpm, int div)return clamp_val ((1350000 + rpm * div /2 ) / (rpm * div),1 ,254 ); } -#define FAN_FROM_REG (val, div) ((val) == 0 ? -1 : \ - ((val) == 255 ? 0 : \ - 1350000 / ((val) * (div)))) +static int fan_from_reg (int val,int div) +{ +if (val ==0 ) +return -1 ; +if (val ==255 ) +return 0 ; +return 1350000 / (val * div); +}/* for temp */ #define TEMP_TO_REG (val) (clamp_val(((val) < 0 ? (val) + 0x100 * 1000 \ : (val)) / 1000, 0, 0xff)) -#define TEMP_FROM_REG (val) (((val) & 0x80 ? \ - (val) - 0x100 : (val)) * 1000) + +static int temp_from_reg (int val) +{ +if (val &0x80 ) +return (val -0x100 ) *1000 ; +return val *1000 ; +}/* * The analog voltage inputs have 8mV LSB. Since the sysfs output is
@@ -281,7 +291,7 @@ static ssize_t show_##reg(struct deviceint nr =to_sensor_dev_attr (attr)->index; \struct w83l786ng_data *data =w83l786ng_update_device (dev); \return sprintf (buf,"%d\n" , \ -FAN_FROM_REG (data->reg[nr],DIV_FROM_REG (data->fan_div[nr]))); \ +fan_from_reg (data->reg[nr],DIV_FROM_REG (data->fan_div[nr]))); \ }show_fan_reg (fan);
@@ -348,7 +358,7 @@ store_fan_div(struct device *dev, struct/* Save fan_min */ mutex_lock (&data->update_lock); - min =FAN_FROM_REG (data->fan_min[nr],DIV_FROM_REG (data->fan_div[nr])); + min =fan_from_reg (data->fan_min[nr],DIV_FROM_REG (data->fan_div[nr])); data->fan_div[nr] =DIV_TO_REG (val);
@@ -410,7 +420,7 @@ show_temp(struct device *dev, struct devint nr = sensor_attr->nr;int index = sensor_attr->index;struct w83l786ng_data *data =w83l786ng_update_device (dev); -return sprintf (buf,"%d\n" ,TEMP_FROM_REG (data->temp[nr][index])); +return sprintf (buf,"%d\n" ,temp_from_reg (data->temp[nr][index])); } static ssize_t
Greg Kroah-Hartman
maintainerPATCH 271/451 i40e: fix scheduling in set_rx_mode
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Przemyslaw Korba <[email protected]>
[ Upstream commit be43abc5514167cc129a8d8e9727b89b8e1d9719 ]
Add service task schedule to set_rx_mode.
In some cases there are error messages printed out in PTP application (ptp4l):
ptp4l[13848.762]: port 1 (ens2f3np3): received SYNC without timestamp ptp4l[13848.825]: port 1 (ens2f3np3): received SYNC without timestamp ptp4l[13848.887]: port 1 (ens2f3np3): received SYNC without timestamp
This happens when service task would not run immediately after set_rx_mode, and we need it for setup tasks. This service task checks, if PTP RX packets are hung in firmware, and propagate correct settings such as multicast address for IEEE 1588 Precision Time Protocol. RX timestamping depends on some of these filters set. Bug happens only with high PTP packets frequency incoming, and not every run since sometimes service task is being ran from a different place immediately after starting ptp4l.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/intel/i40e/i40e_main.c +1 -0
@@ -2101,6 +2101,7 @@ static void i40e_set_rx_mode(struct net_device *netdev) vsi->flags |=I40E_VSI_FLAG_FILTER_CHANGED ;set_bit (__I40E_MACVLAN_SYNC_PENDING, vsi->back->state); } +i40e_service_event_schedule (vsi->back); }/**
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 272/451 iavf: fix off-by-one issues in iavf_config_rss_reg()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kohei Enju <[email protected]>
[ Upstream commit 6daa2893f323981c7894c68440823326e93a7d61 ]
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were:
i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4where rss_{key,lut}_size / 4 is the number of dwords, so the last valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <= accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed the bounds.
[1] KASAN splat about rss_key_size off-by-one
BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800
Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: iavf iavf_watchdog_task
Call Trace:
<TASK>
dump_stack_lvl+0x6f/0xb0
print_report+0x170/0x4f3
kasan_report+0xe1/0x1a0
iavf_config_rss+0x619/0x800
iavf_watchdog_task+0x2be7/0x3230
process_one_work+0x7fd/0x1420
worker_thread+0x4d1/0xd40
kthread+0x344/0x660
ret_from_fork+0x249/0x320
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 63:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x7f/0x90
__kmalloc_noprof+0x246/0x6f0
iavf_watchdog_task+0x28fc/0x3230
process_one_work+0x7fd/0x1420
worker_thread+0x4d1/0xd40
kthread+0x344/0x660
ret_from_fork+0x249/0x320
ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes to the right of
allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50
flags: 0x200000000000000(node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
>ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
^
ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc--- drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/iavf/iavf_main.c +2 -2
@@ -1262,11 +1262,11 @@ static int iavf_config_rss_reg(struct iavf_adapter *adapter)u16 i; dw = (u32 *)adapter->rss_key; -for (i =0 ; i <= adapter->rss_key_size /4 ; i++) +for (i =0 ; i < adapter->rss_key_size /4 ; i++)wr32 (hw,IAVF_VFQF_HKEY (i), dw[i]); dw = (u32 *)adapter->rss_lut; -for (i =0 ; i <= adapter->rss_lut_size /4 ; i++) +for (i =0 ; i < adapter->rss_lut_size /4 ; i++)wr32 (hw,IAVF_VFQF_HLUT (i), dw[i]);iavf_flush (hw);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 273/451 crypto: seqiv - Do not use req->iv after crypto_aead_encrypt
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
[ Upstream commit 50fdb78b7c0bcc550910ef69c0984e751cac72fa ]
As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.
Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.
--- crypto/seqiv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
crypto/seqiv.c +5 -3
@@ -51,6 +51,7 @@ static int seqiv_aead_encrypt(struct aead_request *req)struct aead_geniv_ctx *ctx =crypto_aead_ctx (geniv);struct aead_request *subreq =aead_request_ctx (req);crypto_completion_t compl; +bool unaligned_info;void *data;u8 *info;unsigned int ivsize =8 ;
@@ -80,8 +81,9 @@ static int seqiv_aead_encrypt(struct aead_request *req)return err; } -if (unlikely (!IS_ALIGNED ((unsigned long )info, -crypto_aead_alignmask (geniv) +1 ))) { + unaligned_info = !IS_ALIGNED ((unsigned long )info, +crypto_aead_alignmask (geniv) +1 ); +if (unlikely (unaligned_info)) { info =kmemdup (req->iv, ivsize, req->base.flags &CRYPTO_TFM_REQ_MAY_SLEEP ?GFP_KERNEL :GFP_ATOMIC );
@@ -101,7 +103,7 @@ static int seqiv_aead_encrypt(struct aead_request *req)scatterwalk_map_and_copy (info, req->dst, req->assoclen, ivsize,1 ); err =crypto_aead_encrypt (subreq); -if (unlikely (info != req->iv)) +if (unlikely (unaligned_info))seqiv_aead_encrypt_complete2 (req, err);return err; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 274/451 net: mdio: aspeed: move reg accessing part into separate functions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Potin Lai <[email protected]>
[ Upstream commit 737ca352569e744bf753b4522a6f91b120a734f1 ]
Add aspeed_mdio_op() and aseed_mdio_get_data() for register accessing.
aspeed_mdio_op() handles operations, write command to control register, then check and wait operations is finished (bit 31 is cleared).
aseed_mdio_get_data() fetchs the result value of operation from data register.
Stable-dep-of: d1a1a4bade4b ("net: mdio: aspeed: add dummy read to avoid read-after-write issue")
--- drivers/net/mdio/mdio-aspeed.c | 70 ++++++++++++++++++---------------- 1 file changed, 38 insertions(+), 32 deletions(-)
drivers/net/mdio/mdio-aspeed.c +38 -32
@@ -39,34 +39,35 @@ struct aspeed_mdio {void __iomem *base; }; -static int aspeed_mdio_read (struct mii_bus *bus,int addr,int regnum) +static int aspeed_mdio_op (struct mii_bus *bus,u8 st,u8 op,u8 phyad,u8 regad, +u16 data) {struct aspeed_mdio *ctx = bus->priv;u32 ctrl; -u32 data; -int rc; -dev_dbg (&bus->dev,"%s: addr: %d, regnum: %d\n" , __func__, addr, - regnum); - -/* Just clause 22 for the moment */ -if (regnum &MII_ADDR_C45 ) -return -EOPNOTSUPP ; +dev_dbg (&bus->dev,"%s: st: %u op: %u, phyad: %u, regad: %u, data: %u\n" , + __func__, st, op, phyad, regad, data); ctrl =ASPEED_MDIO_CTRL_FIRE - |FIELD_PREP (ASPEED_MDIO_CTRL_ST ,ASPEED_MDIO_CTRL_ST_C22 ) - |FIELD_PREP (ASPEED_MDIO_CTRL_OP ,MDIO_C22_OP_READ ) - |FIELD_PREP (ASPEED_MDIO_CTRL_PHYAD , addr) - |FIELD_PREP (ASPEED_MDIO_CTRL_REGAD , regnum); + |FIELD_PREP (ASPEED_MDIO_CTRL_ST , st) + |FIELD_PREP (ASPEED_MDIO_CTRL_OP , op) + |FIELD_PREP (ASPEED_MDIO_CTRL_PHYAD , phyad) + |FIELD_PREP (ASPEED_MDIO_CTRL_REGAD , regad) + |FIELD_PREP (ASPEED_MDIO_DATA_MIIRDATA , data);iowrite32 (ctrl, ctx->base +ASPEED_MDIO_CTRL ); - rc =readl_poll_timeout (ctx->base +ASPEED_MDIO_CTRL , ctrl, +return readl_poll_timeout (ctx->base +ASPEED_MDIO_CTRL , ctrl, !(ctrl &ASPEED_MDIO_CTRL_FIRE ),ASPEED_MDIO_INTERVAL_US ,ASPEED_MDIO_TIMEOUT_US ); -if (rc <0 ) -return rc; +} + +static int aspeed_mdio_get_data (struct mii_bus *bus) +{ +struct aspeed_mdio *ctx = bus->priv; +int rc; +u32 data; rc = readl_poll_timeout(ctx->base + ASPEED_MDIO_DATA, data, data & ASPEED_MDIO_DATA_IDLE,
@@ -78,31 +79,36 @@ static int aspeed_mdio_read(struct mii_bus *bus, int addr, int regnum)return FIELD_GET (ASPEED_MDIO_DATA_MIIRDATA , data); } -static int aspeed_mdio_write (struct mii_bus *bus,int addr,int regnum,u16 val) +static int aspeed_mdio_read (struct mii_bus *bus,int addr,int regnum) { -struct aspeed_mdio *ctx = bus->priv; -u32 ctrl; +int rc; -dev_dbg (&bus->dev,"%s: addr: %d, regnum: %d, val: 0x%x\n" , - __func__, addr, regnum, val); +dev_dbg (&bus->dev,"%s: addr: %d, regnum: %d\n" , __func__, addr, + regnum);/* Just clause 22 for the moment */ if (regnum &MII_ADDR_C45 )return -EOPNOTSUPP ; - ctrl =ASPEED_MDIO_CTRL_FIRE - |FIELD_PREP (ASPEED_MDIO_CTRL_ST ,ASPEED_MDIO_CTRL_ST_C22 ) - |FIELD_PREP (ASPEED_MDIO_CTRL_OP ,MDIO_C22_OP_WRITE ) - |FIELD_PREP (ASPEED_MDIO_CTRL_PHYAD , addr) - |FIELD_PREP (ASPEED_MDIO_CTRL_REGAD , regnum) - |FIELD_PREP (ASPEED_MDIO_CTRL_MIIWDATA , val); + rc =aspeed_mdio_op (bus,ASPEED_MDIO_CTRL_ST_C22 ,MDIO_C22_OP_READ , + addr, regnum,0 ); +if (rc <0 ) +return rc; -iowrite32 (ctrl, ctx->base +ASPEED_MDIO_CTRL ); +return aspeed_mdio_get_data (bus); +} -return readl_poll_timeout (ctx->base +ASPEED_MDIO_CTRL , ctrl, - !(ctrl &ASPEED_MDIO_CTRL_FIRE ), -ASPEED_MDIO_INTERVAL_US , -ASPEED_MDIO_TIMEOUT_US ); +static int aspeed_mdio_write (struct mii_bus *bus,int addr,int regnum,u16 val) +{ +dev_dbg (&bus->dev,"%s: addr: %d, regnum: %d, val: 0x%x\n" , + __func__, addr, regnum, val); + +/* Just clause 22 for the moment */ +if (regnum &MII_ADDR_C45 ) +return -EOPNOTSUPP ; + +return aspeed_mdio_op (bus,ASPEED_MDIO_CTRL_ST_C22 ,MDIO_C22_OP_WRITE , + addr, regnum, val); }static int aspeed_mdio_probe (struct platform_device *pdev)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 275/451 net: mdio: aspeed: add dummy read to avoid read-after-write issue
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacky Chou <[email protected]>
[ Upstream commit d1a1a4bade4b20c0858d0b2f81d2611de055f675 ]
The Aspeed MDIO controller may return incorrect data when a read operation follows immediately after a write. Due to a controller bug, the subsequent read can latch stale data, causing the polling logic to terminate earlier than expected.
To work around this hardware issue, insert a dummy read after each write operation. This ensures that the next actual read returns the correct data and prevents premature polling exit.
This workaround has been verified to stabilize MDIO transactions on affected Aspeed platforms.
--- drivers/net/mdio/mdio-aspeed.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/mdio/mdio-aspeed.c +7 -0
@@ -57,6 +57,13 @@ static int aspeed_mdio_op(struct mii_bus *bus, u8 st, u8 op, u8 phyad, u8 regad,iowrite32 (ctrl, ctx->base +ASPEED_MDIO_CTRL ); +/* Workaround for read-after-write issue. +* The controller may return stale data if a read follows immediately +* after a write. A dummy read forces the hardware to update its +* internal state, ensuring that the next real read returns correct data. +*/ +ioread32 (ctx->base +ASPEED_MDIO_CTRL ); + return readl_poll_timeout(ctx->base + ASPEED_MDIO_CTRL, ctrl, !(ctrl & ASPEED_MDIO_CTRL_FIRE), ASPEED_MDIO_INTERVAL_US,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 276/451 net: openvswitch: Avoid needlessly taking the RTNL on vport destroy
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toke Høiland-Jørgensen <[email protected]>
[ Upstream commit 5498227676303e3ffa9a3a46214af96bc3e81314 ]
The openvswitch teardown code will immediately call ovs_netdev_detach_dev() in response to a NETDEV_UNREGISTER notification. It will then start the dp_notify_work workqueue, which will later end up calling the vport destroy() callback. This callback takes the RTNL to do another ovs_netdev_detach_port(), which in this case is unnecessary. This causes extra pressure on the RTNL, in some cases leading to "unregister_netdevice: waiting for XX to become free" warnings on teardown.
We can straight-forwardly avoid the extra RTNL lock acquisition by checking the device flags before taking the lock, and skip the locking altogether if the IFF_OVS_DATAPATH flag has already been unset.
--- net/openvswitch/vport-netdev.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
net/openvswitch/vport-netdev.c +13 -4
@@ -155,10 +155,19 @@ void ovs_netdev_detach_dev(struct vport *vport)static void netdev_destroy (struct vport *vport) { -rtnl_lock (); -if (netif_is_ovs_port (vport->dev)) -ovs_netdev_detach_dev (vport); -rtnl_unlock (); +/* When called from ovs_db_notify_wq() after a dp_device_event(), the +* port has already been detached, so we can avoid taking the RTNL by +* checking this first. +*/ +if (netif_is_ovs_port (vport->dev)) { +rtnl_lock (); +/* Check again while holding the lock to ensure we don't race +* with the netdev notifier and detach twice. +*/ +if (netif_is_ovs_port (vport->dev)) +ovs_netdev_detach_dev (vport); +rtnl_unlock (); + }call_rcu (&vport->rcu, vport_netdev_free); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 277/451 ip6_gre: make ip6gre_header() robust
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit db5b4e39c4e63700c68a7e65fc4e1f1375273476 ]
Over the years, syzbot found many ways to crash the kernel in ip6gre_header() [1].
This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ip6gre device.
[1]
skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0
------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
--- net/ipv6/ip6_gre.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
net/ipv6/ip6_gre.c +8 -1
@@ -1382,9 +1382,16 @@ static int ip6gre_header(struct sk_buff *skb, struct net_device *dev, {struct ip6_tnl *t =netdev_priv (dev);struct ipv6hdr *ipv6h; +int needed;__be16 *p; - ipv6h =skb_push (skb, t->hlen +sizeof (*ipv6h)); + needed = t->hlen +sizeof (*ipv6h); +if (skb_headroom (skb) < needed && +pskb_expand_head (skb,HH_DATA_ALIGN (needed -skb_headroom (skb)), +0 ,GFP_ATOMIC )) +return -needed; + + ipv6h =skb_push (skb, needed);ip6_flow_hdr (ipv6h,0 ,ip6_make_flowlabel (dev_net (dev), skb, t->fl.u.ip6.flowlabel, true, &t->fl.u.ip6));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 278/451 platform/x86: msi-laptop: add missing sysfs_remove_group()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Fourier <[email protected]>
[ Upstream commit 1461209cf813b6ee6d40f29b96b544587df6d2b1 ]
A sysfs group is created in msi_init() when old_ec_model is enabled, but never removed. Remove the msipf_old_attribute_group in that case.
--- drivers/platform/x86/msi-laptop.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/platform/x86/msi-laptop.c +3 -0
@@ -1146,6 +1146,9 @@ static void __exit msi_cleanup(void)sysfs_remove_group (&msipf_device->dev.kobj, &msipf_attribute_group);if (!quirks->old_ec_model && threeg_exists)device_remove_file (&msipf_device->dev, &dev_attr_threeg); +if (quirks->old_ec_model) +sysfs_remove_group (&msipf_device->dev.kobj, + &msipf_old_attribute_group);platform_device_unregister (msipf_device);platform_driver_unregister (&msipf_driver);backlight_device_unregister (msibl_device);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 279/451 platform/x86: ibm_rtl: fix EBDA signature search pointer arithmetic
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junrui Luo <[email protected]>
[ Upstream commit 15dd100349b8526cbdf2de0ce3e72e700eb6c208 ]
The ibm_rtl_init() function searches for the signature but has a pointer arithmetic error. The loop counter suggests searching at 4-byte intervals but the implementation only advances by 1 byte per iteration.
Fix by properly advancing the pointer by sizeof(unsigned int) bytes each iteration.
--- drivers/platform/x86/ibm_rtl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/ibm_rtl.c +1 -1
@@ -262,7 +262,7 @@ static int __init ibm_rtl_init(void) {/* search for the _RTL_ signature at the start of the table */ for (i =0 ; i < ebda_size/sizeof (unsigned int ); i++) {struct ibm_rtl_table __iomem * tmp; - tmp = (struct ibm_rtl_table __iomem *) (ebda_map+i); + tmp = (struct ibm_rtl_table __iomem *) (ebda_map + i*sizeof (unsigned int ));if ((readq (&tmp->signature) &RTL_MASK ) ==RTL_SIGNATURE ) {phys_addr_t addr;unsigned int plen;
Signature · 1 line
2.51.0