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

[PATCH 6.6.y] f2fs: fix to avoid overflow while left shift operation

by Rajani Kantha

From: Chao Yu <chao(a)kernel.org> [ Upstream commit 0fe1c6bec54ea68ed8c987b3890f2296364e77bb ] Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation. Fixes: 3265d3db1f16 ("f2fs: support partial truncation on compressed inode") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> [ Modification: Using rpages[i]->index instead of folio->index due to it was changed since commit:1cda5bc0b2fe ("f2fs: Use a folio in f2fs_truncate_partial_cluster()") on 6.14 ] Signed-off-by: Rajani Kantha <681739313(a)139.com> --- fs/f2fs/compress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c index e962de4ecaa2..c3b2f78ca4e3 100644 --- a/fs/f2fs/compress.c +++ b/fs/f2fs/compress.c @@ -1209,7 +1209,7 @@ int f2fs_truncate_partial_cluster(struct inode *inode, u64 from, bool lock) int i; for (i = cluster_size - 1; i >= 0; i--) { - loff_t start = rpages[i]->index << PAGE_SHIFT; + loff_t start = (loff_t)rpages[i]->index << PAGE_SHIFT; if (from <= start) { zero_user_segment(rpages[i], 0, PAGE_SIZE); -- 2.17.1

1 day, 8 hours

1
0
0 0

[PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

by Selvarasu Ganesan

The below “No resource for ep” warning appears when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous StartTransfer on the same endpoint is still in progress. The gadget functions drivers can invoke `usb_ep_enable` (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from dwc3 driver. To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided. ------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Removed change-id. - Updated commit message. Link to v1: https://lore.kernel.org/linux-usb/20251117152812.622-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1f67fb6aead5..8d3caa71ea12 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -963,8 +963,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */ - if (usb_endpoint_xfer_bulk(desc) || - usb_endpoint_xfer_int(desc)) { + if ((usb_endpoint_xfer_bulk(desc) || + usb_endpoint_xfer_int(desc)) && + !(dep->flags & DWC3_EP_TRANSFER_STARTED)) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma; -- 2.34.1

1 day, 8 hours

3
10
0 0

stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

by Sergey Senozhatsky

Hi, We are observing a performance regression on one of our arm64 boards. We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 ("sched/cpufreq: Rework schedutil governor performance estimation"). UI speedometer benchmark: w/commit: 395 +/-38 w/o commit: 439 +/-14

1 day, 9 hours

3
3
0 0

FAILED: patch "[PATCH] mm/mm_init: fix hash table order logging in" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0d6c356dd6547adac2b06b461528e3573f52d953 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112032-parted-progeny-cd9e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0d6c356dd6547adac2b06b461528e3573f52d953 Mon Sep 17 00:00:00 2001 From: "Isaac J. Manjarres" <isaacmanjarres(a)google.com> Date: Tue, 28 Oct 2025 12:10:12 -0700 Subject: [PATCH] mm/mm_init: fix hash table order logging in alloc_large_system_hash() When emitting the order of the allocation for a hash table, alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log base 2 of the allocation size. This is not correct if the allocation size is smaller than a page, and yields a negative value for the order as seen below: TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear) Use get_order() to compute the order when emitting the hash table information to correctly handle cases where the allocation size is smaller than a page: TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear) Link: https://lkml.kernel.org/r/20251028191020.413002-1-isaacmanjarres@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/mm_init.c b/mm/mm_init.c index 3db2dea7db4c..7712d887b696 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename, panic("Failed to allocate %s hash table\n", tablename); pr_info("%s hash table entries: %ld (order: %d, %lu bytes, %s)\n", - tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size, + tablename, 1UL << log2qty, get_order(size), size, virt ? (huge ? "vmalloc hugepage" : "vmalloc") : "linear"); if (_hash_shift)

1 day, 9 hours

4
5
0 0

[PATCH] NFC: Fix error handling in nfc_genl_dump_targets

by Ma Ke

nfc_genl_dump_targets() increments the device reference count via nfc_get_device() but fails to decrement it properly. nfc_get_device() calls class_find_device() which internally calls get_device() to increment the reference count. No corresponding put_device() is made to decrement the reference count. Add proper reference count decrementing using nfc_put_device() when the dump operation completes or encounters an error, ensuring balanced reference counting. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 4d12b8b129f1 ("NFC: add nfc generic netlink interface") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- net/nfc/netlink.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c index a18e2c503da6..9ae138ee91dd 100644 --- a/net/nfc/netlink.c +++ b/net/nfc/netlink.c @@ -159,6 +159,11 @@ static int nfc_genl_dump_targets(struct sk_buff *skb, cb->args[0] = i; + if (rc < 0 || i >= dev->n_targets) { + nfc_put_device(dev); + cb->args[1] = 0; + } + return skb->len; } -- 2.17.1

1 day, 9 hours

1
0
0 0

FAILED: patch "[PATCH] net: netpoll: fix incorrect refcount handling causing" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112011-candied-surrogate-885f@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Fri, 7 Nov 2025 06:03:37 -0800 Subject: [PATCH] net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <stable(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/core/netpoll.c b/net/core/netpoll.c index c85f740065fc..331764845e8f 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -811,6 +811,10 @@ static void __netpoll_cleanup(struct netpoll *np) if (!npinfo) return; + /* At this point, there is a single npinfo instance per netdevice, and + * its refcnt tracks how many netpoll structures are linked to it. We + * only perform npinfo cleanup when the refcnt decrements to zero. + */ if (refcount_dec_and_test(&npinfo->refcnt)) { const struct net_device_ops *ops; @@ -820,8 +824,7 @@ static void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } skb_pool_flush(np); }

1 day, 9 hours

2
1
0 0

FAILED: patch "[PATCH] ASoC: da7213: Use component driver suspend/resume" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.17.y git checkout FETCH_HEAD git cherry-pick -x 249d96b492efb7a773296ab2c62179918301c146 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112057-rubble-coleslaw-6ad1@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 249d96b492efb7a773296ab2c62179918301c146 Mon Sep 17 00:00:00 2001 From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Date: Tue, 4 Nov 2025 13:49:14 +0200 Subject: [PATCH] ASoC: da7213: Use component driver suspend/resume Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), and snd_soc_pm_ops is associated with the soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between the soc_driver and the DA7213 codec driver, the power management subsystem does not enforce a specific suspend/resume order between the DA7213 driver and the soc_driver. Because of this, the different codec component functionalities, called from snd_soc_resume() to reconfigure various functions, can race with the DA7213 struct dev_pm_ops::resume function, leading to misapplied configuration. This occasionally results in clipped sound. Fix this by dropping the struct dev_pm_ops::{suspend, resume} and use instead struct snd_soc_component_driver::{suspend, resume}. This ensures the proper configuration sequence is handled by the ASoC subsystem. Cc: stable(a)vger.kernel.org Fixes: 431e040065c8 ("ASoC: da7213: Add suspend to RAM support") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Link: https://patch.msgid.link/20251104114914.2060603-1-claudiu.beznea.uj@bp.rene… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c index ae89260ca215..3420011da444 100644 --- a/sound/soc/codecs/da7213.c +++ b/sound/soc/codecs/da7213.c @@ -2124,11 +2124,50 @@ static int da7213_probe(struct snd_soc_component *component) return 0; } +static int da7213_runtime_suspend(struct device *dev) +{ + struct da7213_priv *da7213 = dev_get_drvdata(dev); + + regcache_cache_only(da7213->regmap, true); + regcache_mark_dirty(da7213->regmap); + regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); + + return 0; +} + +static int da7213_runtime_resume(struct device *dev) +{ + struct da7213_priv *da7213 = dev_get_drvdata(dev); + int ret; + + ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); + if (ret < 0) + return ret; + regcache_cache_only(da7213->regmap, false); + return regcache_sync(da7213->regmap); +} + +static int da7213_suspend(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + return da7213_runtime_suspend(da7213->dev); +} + +static int da7213_resume(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + return da7213_runtime_resume(da7213->dev); +} + static const struct snd_soc_component_driver soc_component_dev_da7213 = { .probe = da7213_probe, .set_bias_level = da7213_set_bias_level, .controls = da7213_snd_controls, .num_controls = ARRAY_SIZE(da7213_snd_controls), + .suspend = da7213_suspend, + .resume = da7213_resume, .dapm_widgets = da7213_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(da7213_dapm_widgets), .dapm_routes = da7213_audio_map, @@ -2175,6 +2214,8 @@ static int da7213_i2c_probe(struct i2c_client *i2c) if (!da7213->fin_min_rate) return -EINVAL; + da7213->dev = &i2c->dev; + i2c_set_clientdata(i2c, da7213); /* Get required supplies */ @@ -2224,31 +2265,9 @@ static void da7213_i2c_remove(struct i2c_client *i2c) pm_runtime_disable(&i2c->dev); } -static int da7213_runtime_suspend(struct device *dev) -{ - struct da7213_priv *da7213 = dev_get_drvdata(dev); - - regcache_cache_only(da7213->regmap, true); - regcache_mark_dirty(da7213->regmap); - regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); - - return 0; -} - -static int da7213_runtime_resume(struct device *dev) -{ - struct da7213_priv *da7213 = dev_get_drvdata(dev); - int ret; - - ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); - if (ret < 0) - return ret; - regcache_cache_only(da7213->regmap, false); - return regcache_sync(da7213->regmap); -} - -static DEFINE_RUNTIME_DEV_PM_OPS(da7213_pm, da7213_runtime_suspend, - da7213_runtime_resume, NULL); +static const struct dev_pm_ops da7213_pm = { + RUNTIME_PM_OPS(da7213_runtime_suspend, da7213_runtime_resume, NULL) +}; static const struct i2c_device_id da7213_i2c_id[] = { { "da7213" }, diff --git a/sound/soc/codecs/da7213.h b/sound/soc/codecs/da7213.h index b9ab791d6b88..29cbf0eb6124 100644 --- a/sound/soc/codecs/da7213.h +++ b/sound/soc/codecs/da7213.h @@ -595,6 +595,7 @@ enum da7213_supplies { /* Codec private data */ struct da7213_priv { struct regmap *regmap; + struct device *dev; struct mutex ctrl_lock; struct regulator_bulk_data supplies[DA7213_NUM_SUPPLIES]; struct clk *mclk;

1 day, 9 hours

2
2
0 0

FAILED: patch "[PATCH] net: netpoll: fix incorrect refcount handling causing" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112010-elm-hardwired-dce7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Fri, 7 Nov 2025 06:03:37 -0800 Subject: [PATCH] net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <stable(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/core/netpoll.c b/net/core/netpoll.c index c85f740065fc..331764845e8f 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -811,6 +811,10 @@ static void __netpoll_cleanup(struct netpoll *np) if (!npinfo) return; + /* At this point, there is a single npinfo instance per netdevice, and + * its refcnt tracks how many netpoll structures are linked to it. We + * only perform npinfo cleanup when the refcnt decrements to zero. + */ if (refcount_dec_and_test(&npinfo->refcnt)) { const struct net_device_ops *ops; @@ -820,8 +824,7 @@ static void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } skb_pool_flush(np); }

1 day, 10 hours

2
1
0 0

【要確認】本人確認が必要な状況が発生しています

by サポートセンター

━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Amazon.co.jp カスタマーサービス ━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【重要】アカウント利用に関する確認のお願い平素より Amazon.co.jp サービスをご利用いただき、誠にありがとうございます。お客様のアカウントにおいて、通常とは異なる操作が検出されました。安全のため、本人確認が必要な状況となっております。確認が完了するまで、一部のサービスが制限される場合があります。 ◆ 確認が必要となった理由 ※最近のアカウントアクセスに不審な操作が検出されました。 ※不正利用防止および取引保護のため、本人確認が必要です。 ◆ 手続きの流れ下記リンクより本人確認ページを開いてください。指示に従い、必要事項をご入力ください。完了後、制限されていた機能が通常通りご利用いただけます。 ▼ 本人確認はこちら https://zombie-pc.com/wpiaqhkf8 ◆ ご注意事項 ※確認が行われない場合、アカウントの一時制限が継続されます。 ※セキュリティ向上のため、パスワード変更や二段階認証の設定を推奨します。 ※身に覚えのない取引や不審な操作がある場合は、速やかにカスタマーサービスへご連絡ください。このメールはアカウント保護を目的として自動送信されています。ご返信いただいてもお答えできませんのでご了承ください。 ※ 2025 Amazon Japan G.K. / Amazon.co.jp ━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1 day, 10 hours

1
0
0 0

FAILED: patch "[PATCH] net: netpoll: fix incorrect refcount handling causing" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112008-harddisk-preseason-c83e@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 Mon Sep 17 00:00:00 2001 From: Breno Leitao <leitao(a)debian.org> Date: Fri, 7 Nov 2025 06:03:37 -0800 Subject: [PATCH] net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <stable(a)vger.kernel.org> # 3.17.x Cc: Jay Vosburgh <jv(a)jvosburgh.net> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@deb… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/core/netpoll.c b/net/core/netpoll.c index c85f740065fc..331764845e8f 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -811,6 +811,10 @@ static void __netpoll_cleanup(struct netpoll *np) if (!npinfo) return; + /* At this point, there is a single npinfo instance per netdevice, and + * its refcnt tracks how many netpoll structures are linked to it. We + * only perform npinfo cleanup when the refcnt decrements to zero. + */ if (refcount_dec_and_test(&npinfo->refcnt)) { const struct net_device_ops *ops; @@ -820,8 +824,7 @@ static void __netpoll_cleanup(struct netpoll *np) RCU_INIT_POINTER(np->dev->npinfo, NULL); call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info); - } else - RCU_INIT_POINTER(np->dev->npinfo, NULL); + } skb_pool_flush(np); }

1 day, 10 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror