- Linux-stable-mirror - lists.linaro.org

[PATCH] mfd: altera-sysmgr: Fix device reference leak in altr_sysmgr_regmap_lookup_by_phandle

by Miaoqian Lin

driver_find_device_by_of_node() calls driver_find_device(), which calls get_device(). get_device() increments the device's reference count, so driver_find_device_by_of_node() returns a device with its reference count incremented. We need to release this reference after usage to avoid a reference leak. Add put_device(dev) after dev_get_drvdata() to fix the reference leak. Found via static analysis. Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/mfd/altera-sysmgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/altera-sysmgr.c b/drivers/mfd/altera-sysmgr.c index fb5f988e61f3..cb66b2fff536 100644 --- a/drivers/mfd/altera-sysmgr.c +++ b/drivers/mfd/altera-sysmgr.c @@ -116,6 +116,7 @@ struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np, return ERR_PTR(-EPROBE_DEFER); sysmgr = dev_get_drvdata(dev); + put_device(dev); return sysmgr->regmap; } -- 2.39.5 (Apple Git-154)

1 week, 2 days

1
0
0 0

[PATCH v2] f2fs: invalidate dentry cache on failed whiteout creation

by Deepanshu Kartikey

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() Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT") Reported-by: syzbot+632cf32276a9a564188d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=632cf32276a9a564188d Suggested-by: Chao Yu <chao(a)kernel.org> Link: https://lore.kernel.org/all/20251022233349.102728-1-kartikey406@gmail.com/ [v1] Cc: stable(a)vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- Changes in v2: - Added detailed explanation about VFS not calling d_move() in error path, resulting in new_dentry still pointing to inode with zeroed i_nlink (suggested by Chao Yu) - Added Fixes tag pointing to commit 7e01e7ad746b - Added Cc: stable(a)vger.kernel.org for backporting to stable kernels --- fs/f2fs/namei.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index b882771e4699..712479b7b93d 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -1053,9 +1053,11 @@ static int f2fs_rename(struct mnt_idmap *idmap, struct inode *old_dir, if (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); -- 2.43.0

1 week, 2 days

2
1
0 0

[PATCH] net: phy: motorcomm: Fix the issue in the code regarding the incorrect use of time units

by Yi Cong

From: Yi Cong <yicong(a)kylinos.cn> Currently, NS (nanoseconds) is being used, but according to the datasheet, the correct unit should be PS (picoseconds). Fixes: 4869a146cd60 ("net: phy: Add BIT macro for Motorcomm yt8521/yt8531 gigabit ethernet phy") Cc: stable(a)vger.kernel.org Signed-off-by: Yi Cong <yicong(a)kylinos.cn> --- drivers/net/phy/motorcomm.c | 102 ++++++++++++++++++------------------ 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c index a3593e663059..81491c71e75b 100644 --- a/drivers/net/phy/motorcomm.c +++ b/drivers/net/phy/motorcomm.c @@ -171,7 +171,7 @@ * 1b1 enable 1.9ns rxc clock delay */ #define YT8521_CCR_RXC_DLY_EN BIT(8) -#define YT8521_CCR_RXC_DLY_1_900_NS 1900 +#define YT8521_CCR_RXC_DLY_1_900_PS 1900 #define YT8521_CCR_MODE_SEL_MASK (BIT(2) | BIT(1) | BIT(0)) #define YT8521_CCR_MODE_UTP_TO_RGMII 0 @@ -196,22 +196,22 @@ #define YT8521_RC1R_RX_DELAY_MASK GENMASK(13, 10) #define YT8521_RC1R_FE_TX_DELAY_MASK GENMASK(7, 4) #define YT8521_RC1R_GE_TX_DELAY_MASK GENMASK(3, 0) -#define YT8521_RC1R_RGMII_0_000_NS 0 -#define YT8521_RC1R_RGMII_0_150_NS 1 -#define YT8521_RC1R_RGMII_0_300_NS 2 -#define YT8521_RC1R_RGMII_0_450_NS 3 -#define YT8521_RC1R_RGMII_0_600_NS 4 -#define YT8521_RC1R_RGMII_0_750_NS 5 -#define YT8521_RC1R_RGMII_0_900_NS 6 -#define YT8521_RC1R_RGMII_1_050_NS 7 -#define YT8521_RC1R_RGMII_1_200_NS 8 -#define YT8521_RC1R_RGMII_1_350_NS 9 -#define YT8521_RC1R_RGMII_1_500_NS 10 -#define YT8521_RC1R_RGMII_1_650_NS 11 -#define YT8521_RC1R_RGMII_1_800_NS 12 -#define YT8521_RC1R_RGMII_1_950_NS 13 -#define YT8521_RC1R_RGMII_2_100_NS 14 -#define YT8521_RC1R_RGMII_2_250_NS 15 +#define YT8521_RC1R_RGMII_0_000_PS 0 +#define YT8521_RC1R_RGMII_0_150_PS 1 +#define YT8521_RC1R_RGMII_0_300_PS 2 +#define YT8521_RC1R_RGMII_0_450_PS 3 +#define YT8521_RC1R_RGMII_0_600_PS 4 +#define YT8521_RC1R_RGMII_0_750_PS 5 +#define YT8521_RC1R_RGMII_0_900_PS 6 +#define YT8521_RC1R_RGMII_1_050_PS 7 +#define YT8521_RC1R_RGMII_1_200_PS 8 +#define YT8521_RC1R_RGMII_1_350_PS 9 +#define YT8521_RC1R_RGMII_1_500_PS 10 +#define YT8521_RC1R_RGMII_1_650_PS 11 +#define YT8521_RC1R_RGMII_1_800_PS 12 +#define YT8521_RC1R_RGMII_1_950_PS 13 +#define YT8521_RC1R_RGMII_2_100_PS 14 +#define YT8521_RC1R_RGMII_2_250_PS 15 /* LED CONFIG */ #define YT8521_MAX_LEDS 3 @@ -800,40 +800,40 @@ struct ytphy_cfg_reg_map { static const struct ytphy_cfg_reg_map ytphy_rgmii_delays[] = { /* for tx delay / rx delay with YT8521_CCR_RXC_DLY_EN is not set. */ - { 0, YT8521_RC1R_RGMII_0_000_NS }, - { 150, YT8521_RC1R_RGMII_0_150_NS }, - { 300, YT8521_RC1R_RGMII_0_300_NS }, - { 450, YT8521_RC1R_RGMII_0_450_NS }, - { 600, YT8521_RC1R_RGMII_0_600_NS }, - { 750, YT8521_RC1R_RGMII_0_750_NS }, - { 900, YT8521_RC1R_RGMII_0_900_NS }, - { 1050, YT8521_RC1R_RGMII_1_050_NS }, - { 1200, YT8521_RC1R_RGMII_1_200_NS }, - { 1350, YT8521_RC1R_RGMII_1_350_NS }, - { 1500, YT8521_RC1R_RGMII_1_500_NS }, - { 1650, YT8521_RC1R_RGMII_1_650_NS }, - { 1800, YT8521_RC1R_RGMII_1_800_NS }, - { 1950, YT8521_RC1R_RGMII_1_950_NS }, /* default tx/rx delay */ - { 2100, YT8521_RC1R_RGMII_2_100_NS }, - { 2250, YT8521_RC1R_RGMII_2_250_NS }, + { 0, YT8521_RC1R_RGMII_0_000_PS }, + { 150, YT8521_RC1R_RGMII_0_150_PS }, + { 300, YT8521_RC1R_RGMII_0_300_PS }, + { 450, YT8521_RC1R_RGMII_0_450_PS }, + { 600, YT8521_RC1R_RGMII_0_600_PS }, + { 750, YT8521_RC1R_RGMII_0_750_PS }, + { 900, YT8521_RC1R_RGMII_0_900_PS }, + { 1050, YT8521_RC1R_RGMII_1_050_PS }, + { 1200, YT8521_RC1R_RGMII_1_200_PS }, + { 1350, YT8521_RC1R_RGMII_1_350_PS }, + { 1500, YT8521_RC1R_RGMII_1_500_PS }, + { 1650, YT8521_RC1R_RGMII_1_650_PS }, + { 1800, YT8521_RC1R_RGMII_1_800_PS }, + { 1950, YT8521_RC1R_RGMII_1_950_PS }, /* default tx/rx delay */ + { 2100, YT8521_RC1R_RGMII_2_100_PS }, + { 2250, YT8521_RC1R_RGMII_2_250_PS }, /* only for rx delay with YT8521_CCR_RXC_DLY_EN is set. */ - { 0 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_000_NS }, - { 150 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_150_NS }, - { 300 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_300_NS }, - { 450 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_450_NS }, - { 600 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_600_NS }, - { 750 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_750_NS }, - { 900 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_900_NS }, - { 1050 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_050_NS }, - { 1200 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_200_NS }, - { 1350 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_350_NS }, - { 1500 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_500_NS }, - { 1650 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_650_NS }, - { 1800 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_800_NS }, - { 1950 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_950_NS }, - { 2100 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_2_100_NS }, - { 2250 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_2_250_NS } + { 0 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_000_PS }, + { 150 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_150_PS }, + { 300 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_300_PS }, + { 450 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_450_PS }, + { 600 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_600_PS }, + { 750 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_750_PS }, + { 900 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_900_PS }, + { 1050 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_050_PS }, + { 1200 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_200_PS }, + { 1350 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_350_PS }, + { 1500 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_500_PS }, + { 1650 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_650_PS }, + { 1800 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_800_PS }, + { 1950 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_950_PS }, + { 2100 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_2_100_PS }, + { 2250 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_2_250_PS } }; static u32 ytphy_get_delay_reg_value(struct phy_device *phydev, @@ -890,10 +890,10 @@ static int ytphy_rgmii_clk_delay_config(struct phy_device *phydev) rx_reg = ytphy_get_delay_reg_value(phydev, "rx-internal-delay-ps", ytphy_rgmii_delays, tb_size, &rxc_dly_en, - YT8521_RC1R_RGMII_1_950_NS); + YT8521_RC1R_RGMII_1_950_PS); tx_reg = ytphy_get_delay_reg_value(phydev, "tx-internal-delay-ps", ytphy_rgmii_delays, tb_size, NULL, - YT8521_RC1R_RGMII_1_950_NS); + YT8521_RC1R_RGMII_1_950_PS); switch (phydev->interface) { case PHY_INTERFACE_MODE_RGMII: -- 2.25.1

1 week, 2 days

1
0
0 0

[PATCH] clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src

by Heiko Stuebner

dclk_vop2_src currently has CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT flags set, which is vastly different than dclk_vop0_src or dclk_vop1_src, which have none of those. With these flags in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop these flags from dclk_vop2_src and make the flags the same as on dclk_vop0 and dclk_vop1. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable(a)vger.kernel.org Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/clk/rockchip/clk-rk3588.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c index 1694223f4f84..cf83242d1726 100644 --- a/drivers/clk/rockchip/clk-rk3588.c +++ b/drivers/clk/rockchip/clk-rk3588.c @@ -2094,7 +2094,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = { COMPOSITE(DCLK_VOP1_SRC, "dclk_vop1_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(111), 14, 2, MFLAGS, 9, 5, DFLAGS, RK3588_CLKGATE_CON(52), 11, GFLAGS), - COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, + COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(112), 5, 2, MFLAGS, 0, 5, DFLAGS, RK3588_CLKGATE_CON(52), 12, GFLAGS), COMPOSITE_NODIV(DCLK_VOP0, "dclk_vop0", dclk_vop0_p, -- 2.47.2

1 week, 2 days

5
8
0 0

[PATCH net 1/1] batman-adv: Release references to inactive interfaces

by Simon Wunderlich

From: Sven Eckelmann <sven(a)narfation.org> Trying to dump the originators or the neighbors via netlink for a meshif with an inactive primary interface is not allowed. The dump functions were checking this correctly but they didn't handle non-existing primary interfaces and existing _inactive_ interfaces differently. (Primary) batadv_hard_ifaces hold a references to a net_device. And accessing them is only allowed when either being in a RCU/spinlock protected section or when holding a valid reference to them. The netlink dump functions use the latter. But because the missing specific error handling for inactive primary interfaces, the reference was never dropped. This reference counting error was only detected when the interface should have been removed from the system: unregister_netdevice: waiting for batadv_slave_0 to become free. Usage count = 2 Cc: stable(a)vger.kernel.org Fixes: 6ecc4fd6c2f4 ("batman-adv: netlink: reduce duplicate code by returning interfaces") Reported-by: syzbot+881d65229ca4f9ae8c84(a)syzkaller.appspotmail.com Reported-by: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> --- net/batman-adv/originator.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index a464ff96b9291..ed89d7fd1e7f4 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -764,11 +764,16 @@ int batadv_hardif_neigh_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); @@ -1333,11 +1338,16 @@ int batadv_orig_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); -- 2.47.3

1 week, 2 days

2
1
0 0

[PATCH] riscv: Fix memory leak in module_frob_arch_sections()

by Miaoqian Lin

The current code directly overwrites the scratch pointer with the return value of kvrealloc(). If kvrealloc() fails and returns NULL, the original buffer becomes unreachable, causing a memory leak. Fix this by using a temporary variable to store kvrealloc()'s return value and only update the scratch pointer on success. Found via static anlaysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: be17c0df6795 ("riscv: module: Optimize PLT/GOT entry counting") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/riscv/kernel/module-sections.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/module-sections.c b/arch/riscv/kernel/module-sections.c index 75551ac6504c..1675cbad8619 100644 --- a/arch/riscv/kernel/module-sections.c +++ b/arch/riscv/kernel/module-sections.c @@ -119,6 +119,7 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, unsigned int num_plts = 0; unsigned int num_gots = 0; Elf_Rela *scratch = NULL; + Elf_Rela *new_scratch; size_t scratch_size = 0; int i; @@ -168,9 +169,12 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, scratch_size_needed = (num_scratch_relas + num_relas) * sizeof(*scratch); if (scratch_size_needed > scratch_size) { scratch_size = scratch_size_needed; - scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); - if (!scratch) + new_scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); + if (!new_scratch) { + kvfree(scratch); return -ENOMEM; + } + scratch = new_scratch; } for (size_t j = 0; j < num_relas; j++) -- 2.39.5 (Apple Git-154)

1 week, 2 days

2
1
0 0

[PATCH AUTOSEL 6.17-6.1] smb/server: fix possible memory leak in smb2_read()

by Sasha Levin

From: ZhangGuoDong <zhangguodong(a)kylinos.cn> [ Upstream commit 6fced056d2cc8d01b326e6fcfabaacb9850b71a4 ] Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree(). Co-developed-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ZhangGuoDong <zhangguodong(a)kylinos.cn> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## **Backport Status: YES** ### **Extensive Analysis** Based on comprehensive semantic code analysis and repository examination, this commit **should be backported** to stable kernel trees. --- ## **1. Code Change Analysis** The commit adds a single line to fix a memory leak in `fs/smb/server/smb2pdu.c`: ```c nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); // <-- Added line err = nbytes; goto out; } ``` **What was wrong:** Memory allocated at line 6821 (`aux_payload_buf = kvzalloc(ALIGN(length, 8), KSMBD_DEFAULT_GFP)`) was not freed when `ksmbd_vfs_read()` fails, while all other error paths properly call `kvfree()`. --- ## **2. Semantic Analysis Tools Used** ### **Tool 1: mcp__semcode__find_function** - Located `smb2_read()` in `fs/smb/server/smb2pdu.c:6727-6895` - Confirmed it's an SMB2 protocol handler (169 lines, 24 function calls) - Return type: `int` (returns error codes) ### **Tool 2: mcp__semcode__find_callers** - Result: No direct function callers - However, cross-referenced with `smb2ops.c:183` showing `smb2_read` is registered as a handler: `[SMB2_READ_HE] = { .proc = smb2_read }` - **Conclusion:** This is a protocol handler invoked by the SMB2 message dispatcher, meaning it's **directly user-triggerable** via network requests ### **Tool 3: mcp__semcode__find_calls** - Analyzed `ksmbd_vfs_read()` dependencies - Found it can fail with multiple error codes: `-EISDIR`, `-EACCES`, `-EAGAIN`, plus any errors from `kernel_read()` - **All of these failure paths trigger the memory leak** ### **Tool 4: git blame & git log** - Bug introduced: commit `e2f34481b24db2` (2021-03-16) - **4 years old!** - Recent modification: commit `06a025448b572c` (2024-11-30) changed allocation to `ALIGN(length, 8)` but didn't fix the leak - Found 15+ similar "memory leak" fixes in ksmbd history, indicating active maintenance --- ## **3. Impact Scope Analysis** ### **User Exposure: CRITICAL** - **Protocol Handler:** Any SMB client can trigger this by sending SMB2 READ requests - **Network-facing:** ksmbd is a kernel SMB server exposed to network clients - **No authentication required to trigger:** The error path can be reached even with permission errors ### **Trigger Conditions (from VFS analysis):** 1. **-EISDIR**: Client tries to read a directory 2. **-EACCES**: Permission denied (no FILE_READ_DATA or FILE_EXECUTE access) 3. **-EAGAIN**: File is locked by another process 4. **kernel_read() failures**: Various VFS/filesystem errors All of these are **easily triggerable** by malicious or misbehaving clients. ### **Memory Leak Severity: HIGH** - **Allocation size:** `ALIGN(length, 8)` where `length` is client- controlled - **Maximum per leak:** Up to `SMB3_MAX_IOSIZE` = **8 MB** (from smb2pdu.h:28) - **Default size:** `SMB21_DEFAULT_IOSIZE` = **1 MB** (from smb2pdu.h:25) - **Attack scenario:** An attacker could repeatedly: 1. Send READ requests for locked files (triggers -EAGAIN) 2. Each failed request leaks up to 8MB 3. 100 requests = 800MB leaked 4. Can exhaust server memory leading to **DoS** --- ## **4. Regression Risk Analysis** ### **Risk Level: VERY LOW** - **Change size:** Single line addition - **Operation:** Adding missing cleanup (defensive programming) - **No behavior change:** Only affects error path that already returns failure - **Idempotent:** `kvfree()` is safe to call and simply frees allocated memory - **No dependencies:** No API changes or external impact --- ## **5. Stable Tree Compliance** | Criterion | Status | Evidence | |-----------|--------|----------| | Fixes important bug | ✅ YES | Memory leak leading to potential DoS | | Small and contained | ✅ YES | 1 line change, single function | | No new features | ✅ YES | Pure bug fix | | No architectural changes | ✅ YES | No structural modifications | | Low regression risk | ✅ YES | Minimal, defensive change | | Confined to subsystem | ✅ YES | Only affects ksmbd | | User-facing impact | ✅ YES | Affects all ksmbd users | --- ## **6. Comparison with Similar Commits** Recent ksmbd fixes in the repository show similar patterns: - `379510a815cb2`: "fix possible refcount leak in smb2_sess_setup()" - `5929e98f3bb76`: "fix potential double free on smb2_read_pipe() error path" - `e523a26c05672`: "fix passing freed memory 'aux_payload_buf'" - `809d50d36e71b`: "fix memory leak in smb2_lock()" **All these are typical stable tree backport candidates** with similar characteristics (small resource leak fixes). --- ## **7. Missing Stable Tags** **Notable:** The commit lacks explicit stable tree tags: - ❌ No `Cc: stable(a)vger.kernel.org` - ❌ No `Fixes:` tag pointing to the original buggy commit However, this doesn't diminish backport worthiness - the technical merits clearly justify backporting. --- ## **Conclusion** This commit is an **excellent candidate for backporting** because: 1. **Security concern:** Remote memory exhaustion DoS vector 2. **Long-standing bug:** Present since ksmbd's introduction (4+ years) 3. **Wide impact:** Affects all ksmbd deployments 4. **Minimal risk:** Single-line defensive fix 5. **Clear bug fix:** Unambiguous resource leak on error path 6. **Pattern consistency:** Matches other successfully backported ksmbd fixes **Recommendation:** Backport to all active stable trees where ksmbd exists (5.15+). fs/smb/server/smb2pdu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 287200d7c0764..409b85af82e1c 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -6826,6 +6826,7 @@ int smb2_read(struct ksmbd_work *work) nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); err = nbytes; goto out; } -- 2.51.0

1 week, 2 days

1
25
0 0

[PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts

by Ravi Kumar Bandi

The pcie-xilinx-dma-pl driver does not enable INTx interrupts after initializing the port, preventing INTx interrupts from PCIe endpoints from flowing through the Xilinx XDMA root port bridge. This issue affects kernel 6.6.0 and later versions. This patch allows INTx interrupts generated by PCIe endpoints to flow through the root port. Tested the fix on a board with two endpoints generating INTx interrupts. Interrupts are properly detected and serviced. The /proc/interrupts output shows: [...] 32: 320 0 pl_dma:RC-Event 16 Level 400000000.axi-pcie, azdrv 52: 470 0 pl_dma:RC-Event 16 Level 500000000.axi-pcie, azdrv [...] Changes since v1:: - Fixed commit message per reviewer's comments Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ravi Kumar Bandi <ravib(a)amazon.com> --- drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c index b037c8f315e4..cc539292d10a 100644 --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c +++ b/drivers/pci/controller/pcie-xilinx-dma-pl.c @@ -659,6 +659,12 @@ static int xilinx_pl_dma_pcie_setup_irq(struct pl_dma_pcie *port) return err; } + /* Enable interrupts */ + pcie_write(port, XILINX_PCIE_DMA_IMR_ALL_MASK, + XILINX_PCIE_DMA_REG_IMR); + pcie_write(port, XILINX_PCIE_DMA_IDRN_MASK, + XILINX_PCIE_DMA_REG_IDRN_MASK); + return 0; } -- 2.47.3

1 week, 2 days

8
31
0 0

[PATCH] powerpc: Fix mprotect on book3s32

by Dave Vasilevsky via B4 Relay

From: Dave Vasilevsky <dave(a)vasilevsky.ca> On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 8 ++++++-- arch/powerpc/mm/book3s32/tlb.c | 6 ++++++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..b8c587ad2ea954f179246a57d6e86e45e91dcfdc 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -28,9 +29,12 @@ void _tlbia(void); */ static inline void tlb_flush(struct mmu_gather *tlb) { - /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) { + hash__flush_gather(tlb); + } else { + /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ _tlbia(); + } } static inline void flush_range(struct mm_struct *mm, unsigned long start, unsigned long end) diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..3da95ecfbbb296303082e378425e92a5fbdbfac8 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,9 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

1 week, 2 days

2
1
0 0

[PATCH v3 0/3] Fixes/improvements for SM6350 UFS

by Luca Weiss

Fix the order of the freq-table-hz property, then convert to OPP tables and add interconnect support for UFS for the SM6350 SoC. Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com> --- Changes in v3: - Actually pick up tags, sorry about that - Link to v2: https://lore.kernel.org/r/20251023-sm6350-ufs-things-v2-0-799d59178713@fair… Changes in v2: - Resend, pick up tags - Link to v1: https://lore.kernel.org/r/20250314-sm6350-ufs-things-v1-0-3600362cc52c@fair… --- Luca Weiss (3): arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS arm64: dts: qcom: sm6350: Add OPP table support to UFSHC arm64: dts: qcom: sm6350: Add interconnect support to UFS arch/arm64/boot/dts/qcom/sm6350.dtsi | 49 ++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 10 deletions(-) --- base-commit: a92c761bcac3d5042559107fa7679470727a4bcb change-id: 20250314-sm6350-ufs-things-53c5de9fec5e Best regards, -- Luca Weiss <luca.weiss(a)fairphone.com>

1 week, 2 days

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror