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

[PATCH 5.10] codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()

by Denis Arefev

From: Cong Wang <xiyou.wangcong(a)gmail.com> commit 342debc12183b51773b3345ba267e9263bdfaaef upstream. After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250403211636.166257-1-xiyou.wangcong@gmail.com Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2025-37798 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-37798 --- net/sched/sch_codel.c | 5 +---- net/sched/sch_fq_codel.c | 6 ++---- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c index d99c7386e24e..0d4228bfd1a0 100644 --- a/net/sched/sch_codel.c +++ b/net/sched/sch_codel.c @@ -95,10 +95,7 @@ static struct sk_buff *codel_qdisc_dequeue(struct Qdisc *sch) &q->stats, qdisc_pkt_len, codel_get_enqueue_time, drop_func, dequeue_func); - /* We cant call qdisc_tree_reduce_backlog() if our qlen is 0, - * or HTB crashes. Defer it for next round. - */ - if (q->stats.drop_count && sch->q.qlen) { + if (q->stats.drop_count) { qdisc_tree_reduce_backlog(sch, q->stats.drop_count, q->stats.drop_len); q->stats.drop_count = 0; q->stats.drop_len = 0; diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c index 60dbc549e991..3c1efe360def 100644 --- a/net/sched/sch_fq_codel.c +++ b/net/sched/sch_fq_codel.c @@ -314,10 +314,8 @@ static struct sk_buff *fq_codel_dequeue(struct Qdisc *sch) } qdisc_bstats_update(sch, skb); flow->deficit -= qdisc_pkt_len(skb); - /* We cant call qdisc_tree_reduce_backlog() if our qlen is 0, - * or HTB crashes. Defer it for next round. - */ - if (q->cstats.drop_count && sch->q.qlen) { + + if (q->cstats.drop_count) { qdisc_tree_reduce_backlog(sch, q->cstats.drop_count, q->cstats.drop_len); q->cstats.drop_count = 0; -- 2.43.0

3 months

1
0
0 0

[PATCH 5.10] cifs: fix potential memory leaks in session setup

by Denis Arefev

From: Paulo Alcantara <pc(a)cjr.nz> commit 2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f upstream. Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. Signed-off-by: Paulo Alcantara (SUSE) <pc(a)cjr.nz> Signed-off-by: Steve French <stfrench(a)microsoft.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2023-53008 Link: https://nvd.nist.gov/vuln/detail/CVE-2023-53008 --- fs/cifs/cifsencrypt.c | 1 + fs/cifs/sess.c | 2 ++ fs/cifs/smb2pdu.c | 1 + 3 files changed, 4 insertions(+) diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c index 9daa256f69d4..c75bcdc987e0 100644 --- a/fs/cifs/cifsencrypt.c +++ b/fs/cifs/cifsencrypt.c @@ -371,6 +371,7 @@ build_avpair_blob(struct cifs_ses *ses, const struct nls_table *nls_cp) * ( for NTLMSSP_AV_NB_DOMAIN_NAME followed by NTLMSSP_AV_EOL ) + * unicode length of a netbios domain name */ + kfree_sensitive(ses->auth_key.response); ses->auth_key.len = size + 2 * dlen; ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL); if (!ses->auth_key.response) { diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c index cf6fd138d8d5..d4e215674597 100644 --- a/fs/cifs/sess.c +++ b/fs/cifs/sess.c @@ -601,6 +601,7 @@ int decode_ntlmssp_challenge(char *bcc_ptr, int blob_len, return -EINVAL; } if (tilen) { + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(bcc_ptr + tioffset, tilen, GFP_KERNEL); if (!ses->auth_key.response) { @@ -1335,6 +1336,7 @@ sess_auth_kerberos(struct sess_data *sess_data) goto out_put_spnego_key; } + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(msg->data, msg->sesskey_len, GFP_KERNEL); if (!ses->auth_key.response) { diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 4197096e7fdb..15f9faa1e20a 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -1360,6 +1360,7 @@ SMB2_auth_kerberos(struct SMB2_sess_data *sess_data) /* keep session key if binding */ if (!ses->binding) { + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(msg->data, msg->sesskey_len, GFP_KERNEL); if (!ses->auth_key.response) { -- 2.43.0

3 months

1
0
0 0

Request for backporting rtla fix into 6.15-stable

by Tomas Glozar

Hello, Please pull the following upstream patch to 6.15-stable: 8020361d51ee "rtla: Define _GNU_SOURCE in timerlat_bpf.c" This fixes an rtla bug that was introduced in 6.15 and was expected to be merged into 6.15, hence it was not tagged with Cc: stable, but did not make it. Thanks, Tomas

3 months

1
0
0 0

[PATCH 5.10] sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers

by Denis Arefev

From: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> commit fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 upstream. When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ Link: https://lkml.kernel.org/r/20241113042544.19095-1-qun-wei.lin@mediatek.com Signed-off-by: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> Cc: Andrew Yang <andrew.yang(a)mediatek.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: Casper Li <casper.li(a)mediatek.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Chinwen Chang <chinwen.chang(a)mediatek.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-53128 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-53128 --- include/linux/sched/task_stack.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h index 879a5c8f930b..7aa1235a5bbe 100644 --- a/include/linux/sched/task_stack.h +++ b/include/linux/sched/task_stack.h @@ -8,6 +8,8 @@ #include <linux/sched.h> #include <linux/magic.h> +#include <linux/refcount.h> +#include <linux/kasan.h> #ifdef CONFIG_THREAD_INFO_IN_TASK @@ -86,6 +88,7 @@ static inline int object_is_on_stack(const void *obj) { void *stack = task_stack_page(current); + obj = kasan_reset_tag(obj); return (obj >= stack) && (obj < (stack + THREAD_SIZE)); } -- 2.43.0

3 months

1
0
0 0

[PATCH v2] ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP Victus 15-fa1xxx

by edip＠medip.dev

From: Edip Hazuri <edip(a)medip.dev> The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. v2: - add new entries according to (PCI) SSID order - link to v1: https://lore.kernel.org/linux-sound/20250607105051.41162-1-edip@medip.dev/#R Cc: <stable(a)vger.kernel.org> Signed-off-by: Edip Hazuri <edip(a)medip.dev> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cd0d7ba73..c70bee626 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10787,6 +10787,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8b97, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8bb3, "HP Slim OMEN", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bb4, "HP Slim OMEN", ALC287_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x103c, 0x8bc8, "HP Victus 15-fa1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bcd, "HP Omen 16-xd0xxx", ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bdd, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bde, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), @@ -10840,6 +10841,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8c91, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8c96, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8c97, "HP ZBook", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c9c, "HP Victus 16-s1xxx (MB 8C9C)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8ca1, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8ca2, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8ca4, "HP ZBook Fury", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), -- 2.49.0

3 months

2
1
0 0

[PATCH] platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL

by Srinivas Pandruvada

Address a Smatch static checker warning regarding an unchecked dereference in the function call: set_cdie_id(i, cluster_info, plat_info) when plat_info is NULL. Instead of addressing this one case, in general if plat_info is NULL then it can cause other issues. For example in a two package system it will give warning for duplicate sysfs entry as package ID will be always zero for both packages when creating string for attribute group name. plat_info is derived from TPMI ID TPMI_BUS_INFO, which is integral to the core TPMI design. Therefore, it should not be NULL on a production platform. Consequently, the module should fail to load if plat_info is NULL. Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/platform-driver-x86/aEKvGCLd1qmX04Tc@stanley.mounta… Fixes: 8a54e2253e4c ("platform/x86/intel-uncore-freq: Uncore frequency control via TPMI") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- .../x86/intel/uncore-frequency/uncore-frequency-tpmi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c index 1c7b2f2716ca..44d9948ed224 100644 --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c @@ -511,10 +511,13 @@ static int uncore_probe(struct auxiliary_device *auxdev, const struct auxiliary_ /* Get the package ID from the TPMI core */ plat_info = tpmi_get_platform_data(auxdev); - if (plat_info) - pkg = plat_info->package_id; - else + if (unlikely(!plat_info)) { dev_info(&auxdev->dev, "Platform information is NULL\n"); + ret = -ENODEV; + goto err_rem_common; + } + + pkg = plat_info->package_id; for (i = 0; i < num_resources; ++i) { struct tpmi_uncore_power_domain_info *pd_info; -- 2.49.0

3 months

2
1
0 0

[PATCH] ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP Victus 15-fa1xxx

by edip＠medip.dev

From: Edip Hazuri <edip(a)medip.dev> The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. Cc: <stable(a)vger.kernel.org> Signed-off-by: Edip Hazuri <edip(a)medip.dev> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cd0d7ba73..1e07da9c6 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10733,6 +10733,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8a0f, "HP Pavilion 14-ec1xxx", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8a20, "HP Laptop 15s-fq5xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), SND_PCI_QUIRK(0x103c, 0x8a25, "HP Victus 16-d1xxx (MB 8A25)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), + SND_PCI_QUIRK(0x103c, 0x8c9c, "HP Victus 16-s1xxx (MB 8C9C)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8a28, "HP Envy 13", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a29, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a2a, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), @@ -10805,6 +10806,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8c16, "HP Spectre x360 2-in-1 Laptop 16-aa0xxx", ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX), SND_PCI_QUIRK(0x103c, 0x8c17, "HP Spectre 16", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8c21, "HP Pavilion Plus Laptop 14-ey0XXX", ALC245_FIXUP_HP_X360_MUTE_LEDS), + SND_PCI_QUIRK(0x103c, 0x8bc8, "HP Victus 15-fa1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8c30, "HP Victus 15-fb1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8c46, "HP EliteBook 830 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8c47, "HP EliteBook 840 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), -- 2.49.0

3 months

2
1
0 0

Re: [External] Re: [PATCH v7 1/4] serial: 8250: fix panic due to PSLVERR

by yunhui cui

Hi, On Fri, Jun 6, 2025 at 6:40 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > On Wed, May 28, 2025 at 02:26:06PM +0800, Yunhui Cui wrote: > > When the PSLVERR_RESP_EN parameter is set to 1, the device generates > > an error response if an attempt is made to read an empty RBR (Receive > > Buffer Register) while the FIFO is enabled. > > > > In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, > > UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes > > dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter > > function enables the FIFO via serial_out(p, UART_FCR, p->fcr). > > Execution proceeds to the serial_port_in(port, UART_RX). > > This satisfies the PSLVERR trigger condition. > > > > When another CPU (e.g., using printk()) is accessing the UART (UART > > is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == > > (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter > > dw8250_force_idle(). > > > > Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock > > to fix this issue. > > > > Panic backtrace: > > [ 0.442336] Oops - unknown exception [#1] > > [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a > > [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e > > ... > > [ 0.442416] console_on_rootfs+0x26/0x70 > > > > Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") > > Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ > > Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> > > --- > > drivers/tty/serial/8250/8250_port.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > > index 6d7b8c4667c9c..07fe818dffa34 100644 > > --- a/drivers/tty/serial/8250/8250_port.c > > +++ b/drivers/tty/serial/8250/8250_port.c > > @@ -2376,9 +2376,10 @@ int serial8250_do_startup(struct uart_port *port) > > /* > > * Now, initialize the UART > > */ > > - serial_port_out(port, UART_LCR, UART_LCR_WLEN8); > > > > uart_port_lock_irqsave(port, &flags); > > + serial_port_out(port, UART_LCR, UART_LCR_WLEN8); > > + > > if (up->port.flags & UPF_FOURPORT) { > > if (!up->port.irq) > > up->port.mctrl |= TIOCM_OUT1; > > -- > > 2.39.5 > > > > > > Hi, > > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him > a patch that has triggered this response. He used to manually respond > to these common problems, but in order to save his sanity (he kept > writing the same thing over and over, yet to different people), I was > created. Hopefully you will not take offence and will fix the problem > in your patch and resubmit it so that it can be accepted into the Linux > kernel tree. > > You are receiving this message because of the following common error(s) > as indicated below: > > - You have marked a patch with a "Fixes:" tag for a commit that is in an > older released kernel, yet you do not have a cc: stable line in the > signed-off-by area at all, which means that the patch will not be > applied to any older kernel releases. To properly fix this, please > follow the documented rules in the > Documentation/process/stable-kernel-rules.rst file for how to resolve > this. Okay, update under v8. > > If you wish to discuss this problem further, or you have questions about > how to resolve this issue, please feel free to respond to this email and > Greg will reply once he has dug out from the pending patches received > from other developers. > > thanks, > > greg k-h's patch email bot Thanks, Yunhui

3 months

1
0
0 0

[PATCH 5.10 00/14] backport for CVE-2025-37948 and CVE-2025-37963

by Pu Lehui

From: Pu Lehui <pulehui(a)huawei.com> The backport mainly refers to the merge tag [0], and the corresponding patches are: arm64: proton-pack: Add new CPUs 'k' values for branch mitigation arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: proton-pack: Expose whether the branchy loop k value arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: insn: Add support for encoding DSB Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [0] Douglas Anderson (3): arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe list arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists Hou Tao (2): arm64: move AARCH64_BREAK_FAULT into insn-def.h arm64: insn: add encoders for atomic operations James Morse (6): arm64: insn: Add support for encoding DSB arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: proton-pack: Expose whether the branchy loop k value arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: proton-pack: Add new CPUs 'k' values for branch mitigation Julien Thierry (1): arm64: insn: Add barrier encodings Liu Song (1): arm64: spectre: increase parameters that can be used to turn off bhb mitigation individually Will Deacon (1): arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays .../admin-guide/kernel-parameters.txt | 5 + arch/arm64/include/asm/cputype.h | 2 + arch/arm64/include/asm/debug-monitors.h | 12 - arch/arm64/include/asm/insn.h | 114 +++++++++- arch/arm64/include/asm/spectre.h | 4 +- arch/arm64/kernel/insn.c | 199 +++++++++++++++-- arch/arm64/kernel/proton-pack.c | 206 +++++++++++------- arch/arm64/net/bpf_jit.h | 11 +- arch/arm64/net/bpf_jit_comp.c | 58 ++++- 9 files changed, 488 insertions(+), 123 deletions(-) -- 2.34.1

3 months

2
28
0 0

[PATCH 5.15 0/9] backport for CVE-2025-37948 and CVE-2025-37963

by Pu Lehui

From: Pu Lehui <pulehui(a)huawei.com> The backport mainly refers to the merge tag [0], and the corresponding patches are: arm64: proton-pack: Add new CPUs 'k' values for branch mitigation arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: proton-pack: Expose whether the branchy loop k value arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: insn: Add support for encoding DSB Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [0] Hou Tao (2): arm64: move AARCH64_BREAK_FAULT into insn-def.h arm64: insn: add encoders for atomic operations James Morse (6): arm64: insn: Add support for encoding DSB arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: proton-pack: Expose whether the branchy loop k value arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: proton-pack: Add new CPUs 'k' values for branch mitigation Liu Song (1): arm64: spectre: increase parameters that can be used to turn off bhb mitigation individually .../admin-guide/kernel-parameters.txt | 5 + arch/arm64/include/asm/cputype.h | 2 + arch/arm64/include/asm/debug-monitors.h | 12 -- arch/arm64/include/asm/insn-def.h | 14 ++ arch/arm64/include/asm/insn.h | 81 ++++++- arch/arm64/include/asm/spectre.h | 3 + arch/arm64/kernel/proton-pack.c | 21 +- arch/arm64/lib/insn.c | 199 ++++++++++++++++-- arch/arm64/net/bpf_jit.h | 11 +- arch/arm64/net/bpf_jit_comp.c | 58 ++++- 10 files changed, 366 insertions(+), 40 deletions(-) -- 2.34.1

3 months

2
18
0 0

Mobile World Congress Shanghai 2025 (Verified) Attendee's List!

by Delilah Murray

Hi, We're excited to offer exclusive access to the “Mobile World Congress Shanghai 2025” Visitor Contact List. Event Recap:- Date: 18 - 20 Jun 2025 Location: Shanghai, China Registrants Counts: 42,276 Visitors Contacts Data Fields Available: Individual Email Address, Cell Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more. This list gives you a direct line to your ideal audience—no gatekeepers, no guesswork. If you're interested in the list, just reply "Send me Pricing" or sample? Best regards, Delilah Murray Sr. Marketing Manager Prefer not to receive these emails? Just reply “NOT INTERESTED”.

3 months

1
0
0 0

[PATCH AUTOSEL 6.15 01/10] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index f2a2be8467c66..d4058b623e9c4 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2874,7 +2874,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2903,6 +2903,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2925,9 +2946,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3085,28 +3108,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

2
11
0 0

[PATCH AUTOSEL 6.14 01/10] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index f2a2be8467c66..d4058b623e9c4 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2874,7 +2874,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2903,6 +2903,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2925,9 +2946,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3085,28 +3108,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

2
11
0 0

[PATCH AUTOSEL 6.12 01/10] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 08d9a7cfba8cd..815ee5a74901e 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2870,7 +2870,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2897,6 +2897,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2919,9 +2940,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3079,28 +3102,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

2
11
0 0

[PATCH AUTOSEL 6.6 1/8] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9bd817427a345..af360ba237a37 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2861,7 +2861,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2888,6 +2888,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2910,9 +2931,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3070,28 +3093,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

2
8
0 0

[PATCH AUTOSEL 6.1 1/5] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9b1ba4aedbce7..c591255335058 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2685,7 +2685,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2712,6 +2712,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { if ((req->CreateOptions & FILE_DIRECTORY_FILE_LE) && *(char *)req->Buffer == '\\') { @@ -2743,9 +2764,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -2860,28 +2883,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

2
5
0 0

[PATCH] net: core: fix UNIX-STREAM alignment in /proc/net/protocols

by moyuanhao3676＠163.com

From: MoYuanhao <moyuanhao3676(a)163.com> Widen protocol name column from %-9s to %-11s to properly display UNIX-STREAM and keep table alignment. before modification： console:/ # cat /proc/net/protocols protocol size sockets memory press maxhdr slab module cl co di ac io in de sh ss gs se re sp bi br ha uh gp em PPPOL2TP 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n HIDP 808 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n BNEP 808 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n RFCOMM 840 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n KEY 864 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PACKET 1536 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PINGv6 1184 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n RAWv6 1184 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n UDPLITEv6 1344 0 0 NI 0 yes kernel y y y n y y y n y y y y n n n y y y n UDPv6 1344 0 0 NI 0 yes kernel y y y n y y y n y y y y n n n y y y n TCPv6 2352 0 0 no 320 yes kernel y y y y y y y y y y y y y n y y y y y PPTP 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PPPOE 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n UNIX-STREAM 1024 29 -1 NI 0 yes kernel y n n n n n n n n n n n n n n n y n n UNIX 1024 193 -1 NI 0 yes kernel y n n n n n n n n n n n n n n n n n n UDP-Lite 1152 0 0 NI 0 yes kernel y y y n y y y n y y y y y n n y y y n PING 976 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n RAW 984 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n UDP 1152 0 0 NI 0 yes kernel y y y n y y y n y y y y y n n y y y n TCP 2192 0 0 no 320 yes kernel y y y y y y y y y y y y y n y y y y y SCO 848 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n L2CAP 824 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n HCI 888 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n NETLINK 1104 18 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n after modification: console:/ # cat /proc/net/protocols protocol size sockets memory press maxhdr slab module cl co di ac io in de sh ss gs se re sp bi br ha uh gp em PPPOL2TP 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n HIDP 808 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n BNEP 808 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n RFCOMM 840 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n KEY 864 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PACKET 1536 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PINGv6 1184 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n RAWv6 1184 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n UDPLITEv6 1344 0 0 NI 0 yes kernel y y y n y y y n y y y y n n n y y y n UDPv6 1344 0 0 NI 0 yes kernel y y y n y y y n y y y y n n n y y y n TCPv6 2352 0 0 no 320 yes kernel y y y y y y y y y y y y y n y y y y y PPTP 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n PPPOE 920 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n UNIX-STREAM 1024 29 -1 NI 0 yes kernel y n n n n n n n n n n n n n n n y n n UNIX 1024 193 -1 NI 0 yes kernel y n n n n n n n n n n n n n n n n n n UDP-Lite 1152 0 0 NI 0 yes kernel y y y n y y y n y y y y y n n y y y n PING 976 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n RAW 984 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n UDP 1152 0 0 NI 0 yes kernel y y y n y y y n y y y y y n n y y y n TCP 2192 0 0 no 320 yes kernel y y y y y y y y y y y y y n y y y y y SCO 848 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n L2CAP 824 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n HCI 888 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n NETLINK 1104 18 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: MoYuanhao <moyuanhao3676(a)163.com> --- net/core/sock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 3b409bc8ef6d..d2de5459e94f 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -4284,7 +4284,7 @@ static const char *sock_prot_memory_pressure(struct proto *proto) static void proto_seq_printf(struct seq_file *seq, struct proto *proto) { - seq_printf(seq, "%-9s %4u %6d %6ld %-3s %6u %-3s %-10s " + seq_printf(seq, "%-11s %4u %6d %6ld %-3s %6u %-3s %-10s " "%2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c %2c\n", proto->name, proto->obj_size, @@ -4317,7 +4317,7 @@ static void proto_seq_printf(struct seq_file *seq, struct proto *proto) static int proto_seq_show(struct seq_file *seq, void *v) { if (v == &proto_list) - seq_printf(seq, "%-9s %-4s %-8s %-6s %-5s %-7s %-4s %-10s %s", + seq_printf(seq, "%-11s %-4s %-8s %-6s %-5s %-7s %-4s %-10s %s", "protocol", "size", "sockets", -- 2.34.1

3 months

3
2
0 0

[PATCH AUTOSEL 5.4 1/2] Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices"

by Sasha Levin

From: Lukas Wunner <lukas(a)wunner.de> [ Upstream commit 3be5fa236649da6404f1bca1491bf02d4b0d5cce ] Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") changed IRQ handling on PCI driver probing. It inadvertently broke resume from system sleep on AMD platforms: https://lore.kernel.org/r/20150926164651.GA3640@pd.tnic/ This was fixed by two independent commits: * 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled") * cbbc00be2ce3 ("iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices") The breaking change and one of these two fixes were subsequently reverted: * fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"") * 6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"") This rendered the second fix unnecessary, so revert it as well. It used the match_driver flag in struct pci_dev, which is internal to the PCI core and not supposed to be touched by arbitrary drivers. Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Acked-by: Joerg Roedel <jroedel(a)suse.de> Link: https://patch.msgid.link/9a3ddff5cc49512044f963ba0904347bd404094d.174557234… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. **Extensive Analysis:** **1. Context and Purpose:** This commit is part of a coordinated series of reverts addressing regressions introduced by commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") which broke system suspend/resume on AMD platforms in v4.3. The original issue was fixed by two independent commits, one of which (cbbc00be2ce3) added the line `iommu->dev->match_driver = false;` to prevent other PCI drivers from binding to IOMMU devices. **2. Code Change Analysis:** The commit removes exactly one line from `drivers/iommu/amd/init.c:2034`: ```c /* Prevent binding other PCI device drivers to IOMMU devices */ iommu->dev->match_driver = false; ``` This line was setting the `match_driver` field of `struct pci_dev`, which the commit message correctly identifies as "internal to the PCI core and not supposed to be touched by arbitrary drivers." **3. Why This Should Be Backported:** **a) Part of Coordinated Fix Series:** This revert is the logical completion of a series of reverts that fixed major regressions. Looking at the similar commits provided as examples: - Similar Commit #1 (YES): Revert of x86/PCI pcibios-irq allocation - Similar Commit #2 (YES): Revert of PCI IRQ management helpers - Similar Commit #5 (YES): Revert of the original problematic pcibios_alloc_irq implementation All these related reverts were marked for backporting, making this commit part of the same logical fix series. **b) Removes Inappropriate Code:** The commit eliminates code that violates kernel design principles by accessing internal PCI core structures from a driver. The `match_driver` field is not meant to be manipulated by individual drivers. **c) Cleanup After Main Fix:** Once the root cause (commit 991de2e59090) was reverted by commit 6c777e8799a9, the workaround became unnecessary. Keeping unnecessary workaround code, especially code that inappropriately accesses internal structures, is problematic. **d) Minimal Risk:** The change is extremely small and low-risk - it simply removes one line that was setting an internal field inappropriately. **e) Consistency and Completeness:** Since the other reverts in this series addressing the 991de2e59090 regressions were backported, this should be included for consistency and to ensure the cleanup is complete. **4. Stable Tree Criteria Met:** - ✅ Fixes inappropriate driver behavior (accessing internal PCI structures) - ✅ Small and contained change - ✅ Part of a series addressing known regressions - ✅ Minimal risk of introducing new issues - ✅ Consistent with backporting decisions for related commits The commit represents necessary cleanup after a coordinated regression fix and should be backported to maintain consistency with the related reverts and to remove code that inappropriately accesses internal kernel structures. drivers/iommu/amd_iommu_init.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index de29512c75ccc..cd17deeedf349 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -1751,9 +1751,6 @@ static int __init iommu_init_pci(struct amd_iommu *iommu) if (!iommu->dev) return -ENODEV; - /* Prevent binding other PCI device drivers to IOMMU devices */ - iommu->dev->match_driver = false; - /* ACPI _PRT won't have an IRQ for IOMMU */ iommu->dev->irq_managed = 1; -- 2.39.5

3 months

1
1
0 0

[PATCH AUTOSEL 5.10 1/2] Revert "iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices"

by Sasha Levin

From: Lukas Wunner <lukas(a)wunner.de> [ Upstream commit 3be5fa236649da6404f1bca1491bf02d4b0d5cce ] Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") changed IRQ handling on PCI driver probing. It inadvertently broke resume from system sleep on AMD platforms: https://lore.kernel.org/r/20150926164651.GA3640@pd.tnic/ This was fixed by two independent commits: * 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled") * cbbc00be2ce3 ("iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices") The breaking change and one of these two fixes were subsequently reverted: * fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"") * 6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"") This rendered the second fix unnecessary, so revert it as well. It used the match_driver flag in struct pci_dev, which is internal to the PCI core and not supposed to be touched by arbitrary drivers. Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Acked-by: Joerg Roedel <jroedel(a)suse.de> Link: https://patch.msgid.link/9a3ddff5cc49512044f963ba0904347bd404094d.174557234… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. **Extensive Analysis:** **1. Context and Purpose:** This commit is part of a coordinated series of reverts addressing regressions introduced by commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") which broke system suspend/resume on AMD platforms in v4.3. The original issue was fixed by two independent commits, one of which (cbbc00be2ce3) added the line `iommu->dev->match_driver = false;` to prevent other PCI drivers from binding to IOMMU devices. **2. Code Change Analysis:** The commit removes exactly one line from `drivers/iommu/amd/init.c:2034`: ```c /* Prevent binding other PCI device drivers to IOMMU devices */ iommu->dev->match_driver = false; ``` This line was setting the `match_driver` field of `struct pci_dev`, which the commit message correctly identifies as "internal to the PCI core and not supposed to be touched by arbitrary drivers." **3. Why This Should Be Backported:** **a) Part of Coordinated Fix Series:** This revert is the logical completion of a series of reverts that fixed major regressions. Looking at the similar commits provided as examples: - Similar Commit #1 (YES): Revert of x86/PCI pcibios-irq allocation - Similar Commit #2 (YES): Revert of PCI IRQ management helpers - Similar Commit #5 (YES): Revert of the original problematic pcibios_alloc_irq implementation All these related reverts were marked for backporting, making this commit part of the same logical fix series. **b) Removes Inappropriate Code:** The commit eliminates code that violates kernel design principles by accessing internal PCI core structures from a driver. The `match_driver` field is not meant to be manipulated by individual drivers. **c) Cleanup After Main Fix:** Once the root cause (commit 991de2e59090) was reverted by commit 6c777e8799a9, the workaround became unnecessary. Keeping unnecessary workaround code, especially code that inappropriately accesses internal structures, is problematic. **d) Minimal Risk:** The change is extremely small and low-risk - it simply removes one line that was setting an internal field inappropriately. **e) Consistency and Completeness:** Since the other reverts in this series addressing the 991de2e59090 regressions were backported, this should be included for consistency and to ensure the cleanup is complete. **4. Stable Tree Criteria Met:** - ✅ Fixes inappropriate driver behavior (accessing internal PCI structures) - ✅ Small and contained change - ✅ Part of a series addressing known regressions - ✅ Minimal risk of introducing new issues - ✅ Consistent with backporting decisions for related commits The commit represents necessary cleanup after a coordinated regression fix and should be backported to maintain consistency with the related reverts and to remove code that inappropriately accesses internal kernel structures. drivers/iommu/amd/init.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index e09391ab3deb0..752edbf529f5f 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1876,9 +1876,6 @@ static int __init iommu_init_pci(struct amd_iommu *iommu) if (!iommu->dev) return -ENODEV; - /* Prevent binding other PCI device drivers to IOMMU devices */ - iommu->dev->match_driver = false; - /* ACPI _PRT won't have an IRQ for IOMMU */ iommu->dev->irq_managed = 1; -- 2.39.5

3 months

1
1
0 0

[PATCH AUTOSEL 5.15 1/3] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-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> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/ksmbd/smb2pdu.c | 53 +++++++++++++++++++++++----------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index b21601c0a457c..76334a983cd25 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -2679,7 +2679,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2706,6 +2706,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { if ((req->CreateOptions & FILE_DIRECTORY_FILE_LE) && *(char *)req->Buffer == '\\') { @@ -2737,9 +2758,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -2854,28 +2877,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

3 months

1
2
0 0

[PATCH 6.15.y 0/2] rtc: backport support for handling dates before 1970

by Uwe Kleine-König

Hello, as described in the commit log of the two commits the rtc-mt6397 driver relies on these fixes as soon as it should store dates later than 2027-12-31. On one of the patches has a Fixes line, so this submission is done to ensure that both patches are backported. The patches sent in reply to this mail are (trivial) backports to v6.15.1, they should get backported to the older stable kernels, too, to (somewhat) ensure that in 2028 no surprises happen. `git am` is able to apply the patches as is to 6.14.y, 6.12.y, 6.6.y, 6.1.y and 5.15.y. 5.10 and 5.4 need an adaption, I didn't look into that yet but can follow up with backports for these. The two fixes were accompanied by 3 test updates: 46351921cbe1 ("rtc: test: Emit the seconds-since-1970 value instead of days-since-1970") da62b49830f8 ("rtc: test: Also test time and wday outcome of rtc_time64_to_tm()") ccb2dba3c19f ("rtc: test: Test date conversion for dates starting in 1900") that cover one of the patches. Would you consider it sensible to backport these, too? Best regards Uwe Alexandre Mergnat (2): rtc: Make rtc_time64_to_tm() support dates before 1970 rtc: Fix offset calculation for .start_secs < 0 drivers/rtc/class.c | 2 +- drivers/rtc/lib.c | 24 +++++++++++++++++++----- 2 files changed, 20 insertions(+), 6 deletions(-) base-commit: 3ef49626da6dd67013fc2cf0a4e4c9e158bb59f7 -- 2.47.2

3 months

3
5
0 0

+ mm-close-theoretical-race-where-stale-tlb-entries-could-linger.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: close theoretical race where stale TLB entries could linger has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-close-theoretical-race-where-stale-tlb-entries-could-linger.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: mm: close theoretical race where stale TLB entries could linger Date: Fri, 6 Jun 2025 10:28:07 +0100 Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") described a theoretical race as such: """ Nadav Amit identified a theoretical race between page reclaim and mprotect due to TLB flushes being batched outside of the PTL being held. He described the race as follows: CPU0 CPU1 ---- ---- user accesses memory using RW PTE [PTE now cached in TLB] try_to_unmap_one() ==> ptep_get_and_clear() ==> set_tlb_ubc_flush_pending() mprotect(addr, PROT_READ) ==> change_pte_range() ==> [ PTE non-present - no flush ] user writes using cached RW PTE ... try_to_unmap_flush() The same type of race exists for reads when protecting for PROT_NONE and also exists for operations that can leave an old TLB entry behind such as munmap, mremap and madvise. """ The solution was to introduce flush_tlb_batched_pending() and call it under the PTL from mprotect/madvise/munmap/mremap to complete any pending tlb flushes. However, while madvise_free_pte_range() and madvise_cold_or_pageout_pte_range() were both retro-fitted to call flush_tlb_batched_pending() immediately after initially acquiring the PTL, they both temporarily release the PTL to split a large folio if they stumble upon one. In this case, where re-acquiring the PTL flush_tlb_batched_pending() must be called again, but it previously was not. Let's fix that. There are 2 Fixes: tags here: the first is the commit that fixed madvise_free_pte_range(). The second is the commit that added madvise_cold_or_pageout_pte_range(), which looks like it copy/pasted the faulty pattern from madvise_free_pte_range(). This is a theoretical bug discovered during code review. Link: https://lkml.kernel.org/r/20250606092809.4194056-1-ryan.roberts@arm.com Fixes: 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Reviewed-by: Jann Horn <jannh(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mel Gorman <mgorman <mgorman(a)suse.de> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/madvise.c~mm-close-theoretical-race-where-stale-tlb-entries-could-linger +++ a/mm/madvise.c @@ -508,6 +508,7 @@ restart: pte_offset_map_lock(mm, pmd, addr, &ptl); if (!start_pte) break; + flush_tlb_batched_pending(mm); arch_enter_lazy_mmu_mode(); if (!err) nr = 0; @@ -741,6 +742,7 @@ static int madvise_free_pte_range(pmd_t start_pte = pte; if (!start_pte) break; + flush_tlb_batched_pending(mm); arch_enter_lazy_mmu_mode(); if (!err) nr = 0; _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-close-theoretical-race-where-stale-tlb-entries-could-linger.patch

3 months

1
0
0 0

+ mm-vma-reset-vma-iterator-on-commit_merge-oom-failure.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/vma: reset VMA iterator on commit_merge() OOM failure has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-vma-reset-vma-iterator-on-commit_merge-oom-failure.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: mm/vma: reset VMA iterator on commit_merge() OOM failure Date: Fri, 6 Jun 2025 13:50:32 +0100 While an OOM failure in commit_merge() isn't really feasible due to the allocation which might fail (a maple tree pre-allocation) being 'too small to fail', we do need to handle this case correctly regardless. In vma_merge_existing_range(), we can theoretically encounter failures which result in an OOM error in two ways - firstly dup_anon_vma() might fail with an OOM error, and secondly commit_merge() failing, ultimately, to pre-allocate a maple tree node. The abort logic for dup_anon_vma() resets the VMA iterator to the initial range, ensuring that any logic looping on this iterator will correctly proceed to the next VMA. However the commit_merge() abort logic does not do the same thing. This resulted in a syzbot report occurring because mlockall() iterates through VMAs, is tolerant of errors, but ended up with an incorrect previous VMA being specified due to incorrect iterator state. While making this change, it became apparent we are duplicating logic - the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom option on modify/merge, use in uffd release") duplicates the vmg->give_up_on_oom check in both abort branches. Additionally, we observe that we can perform the anon_dup check safely on dup_anon_vma() failure, as this will not be modified should this call fail. Finally, we need to reset the iterator in both cases, so now we can simply use the exact same code to abort for both. We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to be otherwise and it allows us to implement the abort check more neatly. Link: https://lkml.kernel.org/r/20250606125032.164249-1-lorenzo.stoakes@oracle.com Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reported-by: syzbot+d16409ea9ecc16ed261a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6842cc67.a00a0220.29ac89.003b.GAE@google.c… Reviewed-by: Pedro Falcato <pfalcato(a)suse.de> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vma.c | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) --- a/mm/vma.c~mm-vma-reset-vma-iterator-on-commit_merge-oom-failure +++ a/mm/vma.c @@ -961,26 +961,9 @@ static __must_check struct vm_area_struc err = dup_anon_vma(next, middle, &anon_dup); } - if (err) + if (err || commit_merge(vmg)) goto abort; - err = commit_merge(vmg); - if (err) { - VM_WARN_ON(err != -ENOMEM); - - if (anon_dup) - unlink_anon_vmas(anon_dup); - - /* - * We've cleaned up any cloned anon_vma's, no VMAs have been - * modified, no harm no foul if the user requests that we not - * report this and just give up, leaving the VMAs unmerged. - */ - if (!vmg->give_up_on_oom) - vmg->state = VMA_MERGE_ERROR_NOMEM; - return NULL; - } - khugepaged_enter_vma(vmg->target, vmg->flags); vmg->state = VMA_MERGE_SUCCESS; return vmg->target; @@ -989,6 +972,9 @@ abort: vma_iter_set(vmg->vmi, start); vma_iter_load(vmg->vmi); + if (anon_dup) + unlink_anon_vmas(anon_dup); + /* * This means we have failed to clone anon_vma's correctly, but no * actual changes to VMAs have occurred, so no harm no foul - if the _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are mm-vma-reset-vma-iterator-on-commit_merge-oom-failure.patch docs-mm-expand-vma-doc-to-highlight-pte-freeing-non-vma-traversal.patch mm-ksm-have-ksm-vma-checks-not-require-a-vma-pointer.patch mm-ksm-refer-to-special-vmas-via-vm_special-in-ksm_compatible.patch mm-prevent-ksm-from-breaking-vma-merging-for-new-vmas.patch tools-testing-selftests-add-vma-merge-tests-for-ksm-merge.patch mm-pagewalk-split-walk_page_range_novma-into-kernel-user-parts.patch

3 months

1
0
0 0

[PATCH v2] iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush

by Sean Nyekjaer

fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Cc: stable(a)vger.kernel.org Suggested-by: David Lechner <dlechner(a)baylibre.com> Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> --- Changes in v2: - As per David's suggestion; switched to use synchronize_irq() instead. - Link to v1: https://lore.kernel.org/r/20250524-fxlsrace-v1-1-dec506dc87ae@geanix.com --- drivers/iio/accel/fxls8962af-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/accel/fxls8962af-core.c b/drivers/iio/accel/fxls8962af-core.c index 6d23da3e7aa22c61f2d9348bb91d70cc5719a732..f2558fba491dffa78b26d47d2cd9f1f4d9811f54 100644 --- a/drivers/iio/accel/fxls8962af-core.c +++ b/drivers/iio/accel/fxls8962af-core.c @@ -866,6 +866,8 @@ static int fxls8962af_buffer_predisable(struct iio_dev *indio_dev) if (ret) return ret; + synchronize_irq(data->irq); + ret = __fxls8962af_fifo_set_mode(data, false); if (data->enable_event) --- base-commit: 5c3fcb36c92443a9a037683626a2e43d8825f783 change-id: 20250524-fxlsrace-f4d20e29fb29 Best regards, -- Sean Nyekjaer <sean(a)geanix.com>

3 months, 1 week

3
3
0 0

[PATCH 6.11 1/1] PCI/ASPM: Disable L1 before disabling L1 PM Substates

by Macpaul Lin

From: Ajay Agarwal <ajayagarwal(a)google.com> [ Upstream commit 7447990137bf06b2aeecad9c6081e01a9f47f2aa ] PCIe r6.2, sec 5.5.4, requires that: If setting either or both of the enable bits for ASPM L1 PM Substates, both ports must be configured as described in this section while ASPM L1 is disabled. Previously, pcie_config_aspm_l1ss() assumed that "setting enable bits" meant "setting them to 1", and it configured L1SS as follows: - Clear L1SS enable bits - Disable L1 - Configure L1SS enable bits as required - Enable L1 if required With this sequence, when disabling L1SS on an ARM A-core with a Synopsys DesignWare PCIe core, the CPU occasionally hangs when reading PCI_L1SS_CTL1, leading to a reboot when the CPU watchdog expires. Move the L1 disable to the caller (pcie_config_aspm_link(), where L1 was already enabled) so L1 is always disabled while updating the L1SS bits: - Disable L1 - Clear L1SS enable bits - Configure L1SS enable bits as required - Enable L1 if required Change pcie_aspm_cap_init() similarly. Link: https://lore.kernel.org/r/20241007032917.872262-1-ajayagarwal@google.com Signed-off-by: Ajay Agarwal <ajayagarwal(a)google.com> [bhelgaas: comments, commit log, compute L1SS setting before config access] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Johnny-CC Chang <Johnny-CC.Chang(a)mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com> --- drivers/pci/pcie/aspm.c | 92 ++++++++++++++++++++++------------------- 1 file changed, 50 insertions(+), 42 deletions(-) diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index cee2365e54b8..e943691bc931 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -805,6 +805,15 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) pcie_capability_read_word(parent, PCI_EXP_LNKCTL, &parent_lnkctl); pcie_capability_read_word(child, PCI_EXP_LNKCTL, &child_lnkctl); + /* Disable L0s/L1 before updating L1SS config */ + if (FIELD_GET(PCI_EXP_LNKCTL_ASPMC, child_lnkctl) || + FIELD_GET(PCI_EXP_LNKCTL_ASPMC, parent_lnkctl)) { + pcie_capability_write_word(child, PCI_EXP_LNKCTL, + child_lnkctl & ~PCI_EXP_LNKCTL_ASPMC); + pcie_capability_write_word(parent, PCI_EXP_LNKCTL, + parent_lnkctl & ~PCI_EXP_LNKCTL_ASPMC); + } + /* * Setup L0s state * @@ -829,6 +838,13 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) aspm_l1ss_init(link); + /* Restore L0s/L1 if they were enabled */ + if (FIELD_GET(PCI_EXP_LNKCTL_ASPMC, child_lnkctl) || + FIELD_GET(PCI_EXP_LNKCTL_ASPMC, parent_lnkctl)) { + pcie_capability_write_word(parent, PCI_EXP_LNKCTL, parent_lnkctl); + pcie_capability_write_word(child, PCI_EXP_LNKCTL, child_lnkctl); + } + /* Save default state */ link->aspm_default = link->aspm_enabled; @@ -845,25 +861,28 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) } } -/* Configure the ASPM L1 substates */ +/* Configure the ASPM L1 substates. Caller must disable L1 first. */ static void pcie_config_aspm_l1ss(struct pcie_link_state *link, u32 state) { - u32 val, enable_req; + u32 val; struct pci_dev *child = link->downstream, *parent = link->pdev; - enable_req = (link->aspm_enabled ^ state) & state; + val = 0; + if (state & PCIE_LINK_STATE_L1_1) + val |= PCI_L1SS_CTL1_ASPM_L1_1; + if (state & PCIE_LINK_STATE_L1_2) + val |= PCI_L1SS_CTL1_ASPM_L1_2; + if (state & PCIE_LINK_STATE_L1_1_PCIPM) + val |= PCI_L1SS_CTL1_PCIPM_L1_1; + if (state & PCIE_LINK_STATE_L1_2_PCIPM) + val |= PCI_L1SS_CTL1_PCIPM_L1_2; /* - * Here are the rules specified in the PCIe spec for enabling L1SS: - * - When enabling L1.x, enable bit at parent first, then at child - * - When disabling L1.x, disable bit at child first, then at parent - * - When enabling ASPM L1.x, need to disable L1 - * (at child followed by parent). - * - The ASPM/PCIPM L1.2 must be disabled while programming timing + * PCIe r6.2, sec 5.5.4, rules for enabling L1 PM Substates: + * - Clear L1.x enable bits at child first, then at parent + * - Set L1.x enable bits at parent first, then at child + * - ASPM/PCIPM L1.2 must be disabled while programming timing * parameters - * - * To keep it simple, disable all L1SS bits first, and later enable - * what is needed. */ /* Disable all L1 substates */ @@ -871,26 +890,6 @@ static void pcie_config_aspm_l1ss(struct pcie_link_state *link, u32 state) PCI_L1SS_CTL1_L1SS_MASK, 0); pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1, PCI_L1SS_CTL1_L1SS_MASK, 0); - /* - * If needed, disable L1, and it gets enabled later - * in pcie_config_aspm_link(). - */ - if (enable_req & (PCIE_LINK_STATE_L1_1 | PCIE_LINK_STATE_L1_2)) { - pcie_capability_clear_word(child, PCI_EXP_LNKCTL, - PCI_EXP_LNKCTL_ASPM_L1); - pcie_capability_clear_word(parent, PCI_EXP_LNKCTL, - PCI_EXP_LNKCTL_ASPM_L1); - } - - val = 0; - if (state & PCIE_LINK_STATE_L1_1) - val |= PCI_L1SS_CTL1_ASPM_L1_1; - if (state & PCIE_LINK_STATE_L1_2) - val |= PCI_L1SS_CTL1_ASPM_L1_2; - if (state & PCIE_LINK_STATE_L1_1_PCIPM) - val |= PCI_L1SS_CTL1_PCIPM_L1_1; - if (state & PCIE_LINK_STATE_L1_2_PCIPM) - val |= PCI_L1SS_CTL1_PCIPM_L1_2; /* Enable what we need to enable */ pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1, @@ -937,21 +936,30 @@ static void pcie_config_aspm_link(struct pcie_link_state *link, u32 state) dwstream |= PCI_EXP_LNKCTL_ASPM_L1; } + /* + * Per PCIe r6.2, sec 5.5.4, setting either or both of the enable + * bits for ASPM L1 PM Substates must be done while ASPM L1 is + * disabled. Disable L1 here and apply new configuration after L1SS + * configuration has been completed. + * + * Per sec 7.5.3.7, when disabling ASPM L1, software must disable + * it in the Downstream component prior to disabling it in the + * Upstream component, and ASPM L1 must be enabled in the Upstream + * component prior to enabling it in the Downstream component. + * + * Sec 7.5.3.7 also recommends programming the same ASPM Control + * value for all functions of a multi-function device. + */ + list_for_each_entry(child, &linkbus->devices, bus_list) + pcie_config_aspm_dev(child, 0); + pcie_config_aspm_dev(parent, 0); + if (link->aspm_capable & PCIE_LINK_STATE_L1SS) pcie_config_aspm_l1ss(link, state); - /* - * Spec 2.0 suggests all functions should be configured the - * same setting for ASPM. Enabling ASPM L1 should be done in - * upstream component first and then downstream, and vice - * versa for disabling ASPM L1. Spec doesn't mention L0S. - */ - if (state & PCIE_LINK_STATE_L1) - pcie_config_aspm_dev(parent, upstream); + pcie_config_aspm_dev(parent, upstream); list_for_each_entry(child, &linkbus->devices, bus_list) pcie_config_aspm_dev(child, dwstream); - if (!(state & PCIE_LINK_STATE_L1)) - pcie_config_aspm_dev(parent, upstream); link->aspm_enabled = state; -- 2.45.2

3 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror