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

[PATCH net v2] batman-adv: fix OOB read/write in network-coding decode

by Stanislav Fort

batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing. Fixes: 2df5278b0267 ("batman-adv: network coding - receive coded packets and decode them") Cc: stable(a)vger.kernel.org Reported-by: Stanislav Fort <disclosure(a)aisle.com> Signed-off-by: Stanislav Fort <disclosure(a)aisle.com> --- net/batman-adv/network-coding.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/batman-adv/network-coding.c b/net/batman-adv/network-coding.c index 9f56308779cc..af97d077369f 100644 --- a/net/batman-adv/network-coding.c +++ b/net/batman-adv/network-coding.c @@ -1687,7 +1687,12 @@ batadv_nc_skb_decode_packet(struct batadv_priv *bat_priv, struct sk_buff *skb, coding_len = ntohs(coded_packet_tmp.coded_len); - if (coding_len > skb->len) + /* ensure dst buffer is large enough (payload only) */ + if (coding_len + h_size > skb->len) + return NULL; + + /* ensure src buffer is large enough (payload only) */ + if (coding_len + h_size > nc_packet->skb->len) return NULL; /* Here the magic is reversed: -- 2.39.3 (Apple Git-146)

1 week, 2 days

2
1
0 0

[PATCH 0/3] clk: samsung: exynos990: Fix USB clock support

by Denzeel Oliva

Hi, Small fixes for Exynos990 HSI0 USB clocks: Add missing LHS_ACEL clock ID and implementation, plus two missing USB clock registers. Without these, USB connections fail with errors like device descriptor read timeouts and address response issues. These changes ensure proper USB operation by adding critical missing clock definitions. Denzeel Oliva Signed-off-by: Denzeel Oliva <wachiturroxd150(a)gmail.com> Signed-off-by: Denzeel Oliva <wachiturroxd150(a)gmail.com> --- Denzeel Oliva (3): dt-bindings: clock: exynos990: Add LHS_ACEL clock ID for HSI0 block clk: samsung: exynos990: Add LHS_ACEL gate clock for HSI0 and update CLK_NR_TOP clk: samsung: exynos990: Add missing USB clock registers to HSI0 drivers/clk/samsung/clk-exynos990.c | 8 +++++++- include/dt-bindings/clock/samsung,exynos990.h | 1 + 2 files changed, 8 insertions(+), 1 deletion(-) --- base-commit: e0edfc39b62e35dfb6d669b1189fa268147345ef change-id: 20250830-usb-c8d352f5de9f Best regards, -- Denzeel Oliva <wachiturroxd150(a)gmail.com>

1 week, 3 days

2
4
0 0

[PATCH v7 02/12] i2c: rtl9300: ensure data length is within supported range

by Jonas Jelonek

Add an explicit check for the xfer length to 'rtl9300_i2c_config_xfer' to ensure the data length isn't within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour. This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATA_WIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 <= len <= 16. Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to: (len - 1) & 0xf and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes. For completeness, also add a quirk for the zero length. [1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2 Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Cc: <stable(a)vger.kernel.org> # v6.13+ Signed-off-by: Jonas Jelonek <jelonek.jonas(a)gmail.com> Tested-by: Sven Eckelmann <sven(a)narfation.org> Reviewed-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> # On RTL9302C based board Tested-by: Markus Stockhausen <markus.stockhausen(a)gmx.de> --- drivers/i2c/busses/i2c-rtl9300.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c index 19c367703eaf..ebd4a85e1bde 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -99,6 +99,9 @@ static int rtl9300_i2c_config_xfer(struct rtl9300_i2c *i2c, struct rtl9300_i2c_c { u32 val, mask; + if (len < 1 || len > 16) + return -EINVAL; + val = chan->bus_freq << RTL9300_I2C_MST_CTRL2_SCL_FREQ_OFS; mask = RTL9300_I2C_MST_CTRL2_SCL_FREQ_MASK; @@ -352,7 +355,7 @@ static const struct i2c_algorithm rtl9300_i2c_algo = { }; static struct i2c_adapter_quirks rtl9300_i2c_quirks = { - .flags = I2C_AQ_NO_CLK_STRETCH, + .flags = I2C_AQ_NO_CLK_STRETCH | I2C_AQ_NO_ZERO_LEN, .max_read_len = 16, .max_write_len = 16, }; -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v7 01/12] i2c: rtl9300: fix channel number bound check

by Jonas Jelonek

Fix the current check for number of channels (child nodes in the device tree). Before, this was: if (device_get_child_node_count(dev) >= RTL9300_I2C_MUX_NCHAN) RTL9300_I2C_MUX_NCHAN gives the maximum number of channels so checking with '>=' isn't correct because it doesn't allow the last channel number. Thus, fix it to: if (device_get_child_node_count(dev) > RTL9300_I2C_MUX_NCHAN) Issue occured on a TP-Link TL-ST1008F v2.0 device (8 SFP+ ports) and fix is tested there. Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Cc: <stable(a)vger.kernel.org> # v6.13+ Signed-off-by: Jonas Jelonek <jelonek.jonas(a)gmail.com> Tested-by: Sven Eckelmann <sven(a)narfation.org> Reviewed-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> # On RTL9302C based board Tested-by: Markus Stockhausen <markus.stockhausen(a)gmx.de> --- drivers/i2c/busses/i2c-rtl9300.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c index 4b215f9a24e6..19c367703eaf 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -382,7 +382,7 @@ static int rtl9300_i2c_probe(struct platform_device *pdev) platform_set_drvdata(pdev, i2c); - if (device_get_child_node_count(dev) >= RTL9300_I2C_MUX_NCHAN) + if (device_get_child_node_count(dev) > RTL9300_I2C_MUX_NCHAN) return dev_err_probe(dev, -EINVAL, "Too many channels\n"); device_for_each_child_node(dev, child) { -- 2.48.1

1 week, 3 days

1
0
0 0

New September Order. 15508 Sunday, August 31, 2025 at 11:07:52 AM

by Info - Albinayah 957

Hi Stable, Please provide a quote for your products: Include: 1.Pricing (per unit) 2.Delivery cost & timeline 3.Quote expiry date Deadline: September Thanks! Kamal Prasad Albinayah Trading

1 week, 3 days

1
0
0 0

[PATCH 6.6 0/8] Backport sched/schedutil fixes and depend patch series

by Wentao Guan

Our user report a bug that his cpu keep the min cpu freq, bisect to commit ada8d7fa0ad49a2a078f97f7f6e02d24d3c357a3 ("sched/cpufreq: Rework schedutil governor performance estimation") and test the fix e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 ("sched/fair: Fix frequency selection for non-invariant case") works. And backport the "stable-deps-of" series: "consolidate and cleanup CPU capacity" Link: https://lore.kernel.org/all/20231211104855.558096-1-vincent.guittot@linaro.… PS: commit 50b813b147e9eb6546a1fc49d4e703e6d23691f2 in series ("cpufreq/cppc: Move and rename cppc_cpufreq_{perf_to_khz|khz_to_perf}()") merged in v6.6.59 as 33e89c16cea0882bb05c585fa13236b730dd0efa Vincent Guittot (8): sched/topology: Add a new arch_scale_freq_ref() method cpufreq: Use the fixed and coherent frequency for scaling capacity cpufreq/schedutil: Use a fixed reference frequency energy_model: Use a fixed reference frequency cpufreq/cppc: Set the frequency used for computing the capacity arm64/amu: Use capacity_ref_freq() to set AMU ratio topology: Set capacity_freq_ref in all cases sched/fair: Fix frequency selection for non-invariant case arch/arm/include/asm/topology.h | 1 + arch/arm64/include/asm/topology.h | 1 + arch/arm64/kernel/topology.c | 26 ++++++------ arch/riscv/include/asm/topology.h | 1 + drivers/base/arch_topology.c | 69 ++++++++++++++++++++----------- drivers/cpufreq/cpufreq.c | 4 +- include/linux/arch_topology.h | 8 ++++ include/linux/cpufreq.h | 1 + include/linux/energy_model.h | 6 +-- include/linux/sched/topology.h | 8 ++++ kernel/sched/cpufreq_schedutil.c | 30 +++++++++++++- 11 files changed, 111 insertions(+), 44 deletions(-) -- 2.20.1

1 week, 3 days

3
12
0 0

[PATCH v2] scsi: lpfc: Fix buffer free/clear order in deferred receive path

by John Evans

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same. Fixes: 472e146d1cf3 ("scsi: lpfc: Correct upcalling nvmet_fc transport during io done downcall") Cc: stable(a)vger.kernel.org Signed-off-by: John Evans <evans1210144(a)gmail.com> --- v2: * Rework locking to read and clear the buffer pointer atomically, as suggested by Justin Tee. --- drivers/scsi/lpfc/lpfc_nvmet.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c index fba2e62027b7..4cfc928bcf2d 100644 --- a/drivers/scsi/lpfc/lpfc_nvmet.c +++ b/drivers/scsi/lpfc/lpfc_nvmet.c @@ -1243,7 +1243,7 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_target_port *tgtport, struct lpfc_nvmet_tgtport *tgtp; struct lpfc_async_xchg_ctx *ctxp = container_of(rsp, struct lpfc_async_xchg_ctx, hdlrctx.fcp_req); - struct rqb_dmabuf *nvmebuf = ctxp->rqb_buffer; + struct rqb_dmabuf *nvmebuf; struct lpfc_hba *phba = ctxp->phba; unsigned long iflag; @@ -1251,13 +1251,18 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_target_port *tgtport, lpfc_nvmeio_data(phba, "NVMET DEFERRCV: xri x%x sz %d CPU %02x\n", ctxp->oxid, ctxp->size, raw_smp_processor_id()); + spin_lock_irqsave(&ctxp->ctxlock, iflag); + nvmebuf = ctxp->rqb_buffer; if (!nvmebuf) { + spin_unlock_irqrestore(&ctxp->ctxlock, iflag); lpfc_printf_log(phba, KERN_INFO, LOG_NVME_IOERR, "6425 Defer rcv: no buffer oxid x%x: " "flg %x ste %x\n", ctxp->oxid, ctxp->flag, ctxp->state); return; } + ctxp->rqb_buffer = NULL; + spin_unlock_irqrestore(&ctxp->ctxlock, iflag); tgtp = phba->targetport->private; if (tgtp) @@ -1265,9 +1270,6 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_target_port *tgtport, /* Free the nvmebuf since a new buffer already replaced it */ nvmebuf->hrq->rqbp->rqb_free_buffer(phba, nvmebuf); - spin_lock_irqsave(&ctxp->ctxlock, iflag); - ctxp->rqb_buffer = NULL; - spin_unlock_irqrestore(&ctxp->ctxlock, iflag); } /** -- 2.43.0

1 week, 3 days

3
2
0 0

[regression] Wireguard fragmentation fails with VXLAN since 8930424777e4 ("tunnels: Accept PACKET_HOST skb_tunnel_check_pmtu().") causing network timeouts

by Salvatore Bonaccorso

Hi, Charles Bordet reported the following issue (full context in https://bugs.debian.org/1108860) > Dear Maintainer, > > What led up to the situation? > We run a production environment using Debian 12 VMs, with a network > topology involving VXLAN tunnels encapsulated inside Wireguard > interfaces. This setup has worked reliably for over a year, with MTU set > to 1500 on all interfaces except the Wireguard interface (set to 1420). > Wireguard kernel fragmentation allowed this configuration to function > without issues, even though the effective path MTU is lower than 1500. > > What exactly did you do (or not do) that was effective (or ineffective)? > We performed a routine system upgrade, updating all packages include the > kernel. After the upgrade, we observed severe network issues (timeouts, > very slow HTTP/HTTPS, and apt update failures) on all VMs behind the > router. SSH and small-packet traffic continued to work. > > To diagnose, we: > > * Restored a backup (with the previous kernel): the problem disappeared. > * Repeated the upgrade, confirming the issue reappeared. > * Systematically tested each kernel version from 6.1.124-1 up to > 6.1.140-1. The problem first appears with kernel 6.1.135-1; all earlier > versions work as expected. > * Kernel version from the backports (6.12.32-1) did not resolve the > problem. > > What was the outcome of this action? > > * With kernel 6.1.135-1 or later, network timeouts occur for > large-packet protocols (HTTP, apt, etc.), while SSH and small-packet > protocols work. > * With kernel 6.1.133-1 or earlier, everything works as expected. > > What outcome did you expect instead? > We expected the network to function as before, with Wireguard handling > fragmentation transparently and no application-level timeouts, > regardless of the kernel version. While triaging the issue we found that the commit 8930424777e4 ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu()." introduces the issue and Charles confirmed that the issue was present as well in 6.12.35 and 6.15.4 (other version up could potentially still be affected, but we wanted to check it is not a 6.1.y specific regression). Reverthing the commit fixes Charles' issue. Does that ring a bell? Regards, Salvatore

1 week, 3 days

3
3
0 0

[PATCH] net: dsa: mv88e6xxx: Fix fwnode reference leaks in mv88e6xxx_port_setup_leds

by Miaoqian Lin

Fix multiple fwnode reference leaks: 1. The function calls fwnode_get_named_child_node() to get the "leds" node, but never calls fwnode_handle_put(leds) to release this reference. 2. Within the fwnode_for_each_child_node() loop, the early return paths that don't properly release the "led" fwnode reference. This fix follows the same pattern as commit d029edefed39 ("net dsa: qca8k: fix usages of device_get_named_child_node()") Fixes: 94a2a84f5e9e ("net: dsa: mv88e6xxx: Support LED control") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/net/dsa/mv88e6xxx/leds.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/net/dsa/mv88e6xxx/leds.c b/drivers/net/dsa/mv88e6xxx/leds.c index 1c88bfaea46b..dcc765066f9c 100644 --- a/drivers/net/dsa/mv88e6xxx/leds.c +++ b/drivers/net/dsa/mv88e6xxx/leds.c @@ -779,6 +779,8 @@ int mv88e6xxx_port_setup_leds(struct mv88e6xxx_chip *chip, int port) continue; if (led_num > 1) { dev_err(dev, "invalid LED specified port %d\n", port); + fwnode_handle_put(led); + fwnode_handle_put(leds); return -EINVAL; } @@ -823,17 +825,23 @@ int mv88e6xxx_port_setup_leds(struct mv88e6xxx_chip *chip, int port) init_data.devname_mandatory = true; init_data.devicename = kasprintf(GFP_KERNEL, "%s:0%d:0%d", chip->info->name, port, led_num); - if (!init_data.devicename) + if (!init_data.devicename) { + fwnode_handle_put(led); + fwnode_handle_put(leds); return -ENOMEM; + } ret = devm_led_classdev_register_ext(dev, l, &init_data); kfree(init_data.devicename); if (ret) { dev_err(dev, "Failed to init LED %d for port %d", led_num, port); + fwnode_handle_put(led); + fwnode_handle_put(leds); return ret; } } + fwnode_handle_put(leds); return 0; } -- 2.35.1

1 week, 3 days

2
1
0 0

[PATCH 1/2] ALSA: hda: tas2781: fix tas2563 EFI data endianness

by Gergo Koteles

Before conversion to unify the calibration data management, the tas2563_apply_calib() function performed the big endian conversion and wrote the calibration data to the device. The writing is now done by the common tasdev_load_calibrated_data() function, but without conversion. Put the values into the calibration data buffer with the expected endianness. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Cc: <stable(a)vger.kernel.org> Signed-off-by: Gergo Koteles <soyer(a)irl.hu> --- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index e34b17f0c9b9..1eac751ab2a6 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -310,6 +310,7 @@ static int tas2563_save_calibration(struct tas2781_hda *h) struct cali_reg *r = &cd->cali_reg_array; unsigned int offset = 0; unsigned char *data; + __be32 bedata; efi_status_t status; unsigned int attr; int ret, i, j, k; @@ -351,6 +352,8 @@ static int tas2563_save_calibration(struct tas2781_hda *h) i, j, status); return -EINVAL; } + bedata = cpu_to_be32(*(uint32_t *)&data[offset]); + memcpy(&data[offset], &bedata, sizeof(bedata)); offset += TAS2563_CAL_DATA_SIZE; } } -- 2.51.0

1 week, 4 days

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror