kcalloc_node() may fail. When the interrupter array allocation returns
NULL, subsequent code uses xhci->interrupters (e.g. in xhci_add_interrupter()
and in cleanup paths), leading to a potential NULL pointer dereference.
Check the allocation and bail out to the existing fail path to avoid
the NULL dereference.
Fixes: c99b38c412343 ("xhci: add support to allocate several interrupters")
Cc: stable(a)vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com>
---
drivers/usb/host/xhci-mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index d698095fc88d..da257856e864 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2505,7 +2505,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
"Allocating primary event ring");
xhci->interrupters = kcalloc_node(xhci->max_interrupters, sizeof(*xhci->interrupters),
flags, dev_to_node(dev));
-
+ if (!xhci->interrupters)
+ goto fail;
ir = xhci_alloc_interrupter(xhci, 0, flags);
if (!ir)
goto fail;
--
2.43.0
The function calls of_parse_phandle() which returns
a device node with an incremented reference count. When the bonded device
is not available, the function
returns NULL without releasing the reference, causing a reference leak.
Add of_node_put(np) to release the device node reference.
The of_node_put function handles NULL pointers.
Found through static analysis by reviewing the doc of of_parse_phandle()
and cross-checking its usage patterns across the codebase.
Fixes: 7625ee981af1 ("[media] media: platform: rcar_drif: Add DRIF support")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/media/platform/renesas/rcar_drif.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/renesas/rcar_drif.c b/drivers/media/platform/renesas/rcar_drif.c
index fc8b6bbef793..c5d676eb1091 100644
--- a/drivers/media/platform/renesas/rcar_drif.c
+++ b/drivers/media/platform/renesas/rcar_drif.c
@@ -1246,6 +1246,7 @@ static struct device_node *rcar_drif_bond_enabled(struct platform_device *p)
if (np && of_device_is_available(np))
return np;
+ of_node_put(np);
return NULL;
}
--
2.35.1
This kernel version doesn't build with GCC 15:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from arch/x86/realmode/rm/wakeup.h:11,
from arch/x86/realmode/rm/wakemain.c:2:
include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
11 | false = 0,
| ^~~~~
include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
30 | typedef _Bool bool;
| ^~~~
include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
include/linux/types.h:30:1: warning: useless type name in empty declaration
30 | typedef _Bool bool;
| ^~~~~~~
I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I
realised this fix was already done in an upstream commit, created before
the GCC 15 release and not mentioning the error I had. This is the first
patch.
When I was investigating my error, I noticed other commits were already
backported to v5.15. They were all adding -std=gnu11 in different
Makefiles. In their commit message, they were mentioning 'gnu11' was
picked to use the same as the one from the main Makefile. But this is
not the case in this kernel version. Patch 2 fixes that.
Finally, I noticed the documentation was not correct in this kernel
version: this is because a commit was backported to v5.15 while it was
not supposed to. Patch 3 fixes that.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
---
Alexey Dobriyan (1):
x86/boot: Compile boot code with -std=gnu11 too
Matthieu Baerts (NGI0) (2):
arch: back to -std=gnu89 in < v5.18
Revert "docs/process/howto: Replace C89 with C11"
Documentation/process/howto.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
Documentation/translations/ja_JP/howto.rst | 2 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
Documentation/translations/zh_CN/process/howto.rst | 2 +-
Documentation/translations/zh_TW/process/howto.rst | 2 +-
arch/parisc/boot/compressed/Makefile | 2 +-
arch/s390/Makefile | 2 +-
arch/s390/purgatory/Makefile | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/firmware/efi/libstub/Makefile | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
---
base-commit: 06cf22cc87e00b878c310d5441981b7750f04078
change-id: 20251017-v5-15-gcc-15-5ceda8ebe577
Best regards,
--
Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
Hi
We got in Debian a request to backport 3c591faadd8a ("Reapply "Revert
drm/amd/display: Enable Freesync Video Mode by default"") for the
kernel in Debian bookworm, based on 6.1.y stable series.
https://bugs.debian.org/1119232
While looking at he request, I noticed that the series of commits had
a bit of a convuluted history. AFAICT the story began with:
de05abe6b9d0 ("drm/amd/display: Enable Freesync Video Mode by
default"), this landed in 5.18-rc1 (and backported to v6.1.5,
v6.0.19).
This was then reverted with 4243c84aa082 ("Revert "drm/amd/display:
Enable Freesync Video Mode by default""), which landed in v6.3-rc1
(and in turn was backported to v6.1.53).
So far we are in sync.
The above was then reverted again, via 11b92df8a2f7 ("Revert "Revert
drm/amd/display: Enable Freesync Video Mode by default"") applied in
v6.5-rc1 and as well backported to v6.1.53 (so still in sync).
Now comes were we are diverging: 3c591faadd8a ("Reapply "Revert
drm/amd/display: Enable Freesync Video Mode by default"") got applied
later on, landing in v6.9-rc1 but *not* in 6.1.y anymore.
I suspect this one was not applied to 6.1.y because in meanwhile there
was a conflict to cherry-pick it cleanly due to context changes due to
3e094a287526 ("drm/amd/display: Use drm_connector in
create_stream_for_sink").
If this is correct, then the 6.1.y series can be brough in sync with
cherry-picking the commit and adjust the context around the change.
I'm attaching the proposed change.
Alex in particular, does that make sense?
Regards,
Salvatore
A malicious user could pass an arbitrarily bad value
to memdup_user_nul(), potentially causing kernel crash.
This follows the same pattern as commit ee76746387f6
("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
and commit 7ef4c19d245f
("smackfs: restrict bytes count in smackfs write functions")
Found via static analysis and code review.
Fixes: 183238ffb886 ("misc: eeprom/idt_89hpesx: Switch to memdup_user_nul() helper")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/misc/eeprom/idt_89hpesx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/misc/eeprom/idt_89hpesx.c b/drivers/misc/eeprom/idt_89hpesx.c
index 60c42170d147..b2e771bfc6da 100644
--- a/drivers/misc/eeprom/idt_89hpesx.c
+++ b/drivers/misc/eeprom/idt_89hpesx.c
@@ -907,6 +907,9 @@ static ssize_t idt_dbgfs_csr_write(struct file *filep, const char __user *ubuf,
if (*offp)
return 0;
+ if (count == 0 || count > PAGE_SIZE)
+ return -EINVAL;
+
/* Copy data from User-space */
buf = memdup_user_nul(ubuf, count);
if (IS_ERR(buf))
--
2.39.5 (Apple Git-154)
MAX77705 charger is most likely always a single device on the board,
however nothing stops board designers to have two of them, thus same
device driver could probe twice. Or user could manually try to probing
second time.
Device driver is not ready for that case, because it allocates
statically 'struct regmap_irq_chip' as non-const and stores during
probe in 'irq_drv_data' member a pointer to per-probe state
container ('struct max77705_charger_data'). devm_regmap_add_irq_chip()
does not make a copy of 'struct regmap_irq_chip' but stores the pointer.
Second probe - either successful or failure - would overwrite the
'irq_drv_data' from previous device probe, so interrupts would be
executed in a wrong context.
Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
---
Not tested on hardware
---
drivers/power/supply/max77705_charger.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/power/supply/max77705_charger.c b/drivers/power/supply/max77705_charger.c
index b1a227bf72e2..1044bf58aeac 100644
--- a/drivers/power/supply/max77705_charger.c
+++ b/drivers/power/supply/max77705_charger.c
@@ -60,7 +60,7 @@ static const struct regmap_irq max77705_charger_irqs[] = {
REGMAP_IRQ_REG_LINE(MAX77705_AICL_I, BITS_PER_BYTE),
};
-static struct regmap_irq_chip max77705_charger_irq_chip = {
+static const struct regmap_irq_chip max77705_charger_irq_chip = {
.name = "max77705-charger",
.status_base = MAX77705_CHG_REG_INT,
.mask_base = MAX77705_CHG_REG_INT_MASK,
@@ -567,6 +567,7 @@ static int max77705_charger_probe(struct i2c_client *i2c)
{
struct power_supply_config pscfg = {};
struct max77705_charger_data *chg;
+ struct regmap_irq_chip *chip_desc;
struct device *dev;
struct regmap_irq_chip_data *irq_data;
int ret;
@@ -580,6 +581,13 @@ static int max77705_charger_probe(struct i2c_client *i2c)
chg->dev = dev;
i2c_set_clientdata(i2c, chg);
+ chip_desc = devm_kmemdup(dev, &max77705_charger_irq_chip,
+ sizeof(max77705_charger_irq_chip),
+ GFP_KERNEL);
+ if (!chip_desc)
+ return -ENOMEM;
+ chip_desc->irq_drv_data = chg;
+
chg->regmap = devm_regmap_init_i2c(i2c, &max77705_chg_regmap_config);
if (IS_ERR(chg->regmap))
return PTR_ERR(chg->regmap);
@@ -599,11 +607,9 @@ static int max77705_charger_probe(struct i2c_client *i2c)
if (IS_ERR(chg->psy_chg))
return PTR_ERR(chg->psy_chg);
- max77705_charger_irq_chip.irq_drv_data = chg;
ret = devm_regmap_add_irq_chip(chg->dev, chg->regmap, i2c->irq,
IRQF_ONESHOT, 0,
- &max77705_charger_irq_chip,
- &irq_data);
+ chip_desc, &irq_data);
if (ret)
return dev_err_probe(dev, ret, "failed to add irq chip\n");
--
2.48.1
The ucsi_psy_get_current_max function defaults to 0.1A when it is not
clear how much current the partner device can support. But this does
not check the port is connected, and will report 0.1A max current when
nothing is connected. Update ucsi_psy_get_current_max to report 0A when
there is no connection.
v2 changes:
- added cc stable tag to commit message
Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default")
Cc: stable(a)vger.kernel.org
Signed-off-by: Jameson Thies <jthies(a)google.com>
Reviewed-by: Benson Leung <bleung(a)chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Tested-by: Kenneth R. Crudup <kenny(a)panix.com>
---
drivers/usb/typec/ucsi/psy.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c
index 62a9d68bb66d..8ae900c8c132 100644
--- a/drivers/usb/typec/ucsi/psy.c
+++ b/drivers/usb/typec/ucsi/psy.c
@@ -145,6 +145,11 @@ static int ucsi_psy_get_current_max(struct ucsi_connector *con,
{
u32 pdo;
+ if (!UCSI_CONSTAT(con, CONNECTED)) {
+ val->intval = 0;
+ return 0;
+ }
+
switch (UCSI_CONSTAT(con, PWR_OPMODE)) {
case UCSI_CONSTAT_PWR_OPMODE_PD:
if (con->num_pdos > 0) {
base-commit: e40b984b6c4ce3f80814f39f86f87b2a48f2e662
--
2.51.0.858.gf9c4a03a3a-goog