November 2023 - Linux-stable-mirror

[PATCH 5.10] Backport the fix for CVE-2023-25012 to kernel v5.10

by He Gao

This is the fix of CVE-2023-25012 for kernel v5.10. Upstream commit: https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc867605… The affected code is in io_uring/io_uring.c instead of io_uring/fdinfo.c for v5.10. So the patch applies the same change to io_uring/io_uring.c. Thanks! He Jens Axboe (1): io_uring/fdinfo: lock SQ thread while retrieving thread cpu/pid io_uring/io_uring.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) -- 2.42.0.869.gea05f2083d-goog

1 year, 11 months

1
1
0 0

[v6.6][PATCH] eventfs: Check for NULL ef in eventfs_set_attr()

by Steven Rostedt

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> The top level events directory dentry does not have a d_fsdata set to a eventfs_file pointer. This dentry is still passed to eventfs_set_attr(). It can not assume that the d_fsdata is set. Check for that. Link: https://lore.kernel.org/all/20231112104158.6638-1-milian.wolff@kdab.com/ Fixes: 9aaee3eebc91 ("eventfs: Save ownership and mode") Reported-by: Milian Wolff <milian.wolff(a)kdab.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- Note: This only affects 6.6 as the code in 6.7 here was rewritten. I tested 6.7 and it does not have this bug. fs/tracefs/event_inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c index 5fcfb634fec2..efbdc47c74dc 100644 --- a/fs/tracefs/event_inode.c +++ b/fs/tracefs/event_inode.c @@ -113,14 +113,14 @@ static int eventfs_set_attr(struct mnt_idmap *idmap, struct dentry *dentry, mutex_lock(&eventfs_mutex); ef = dentry->d_fsdata; - if (ef->is_freed) { + if (ef && ef->is_freed) { /* Do not allow changes if the event is about to be removed. */ mutex_unlock(&eventfs_mutex); return -ENODEV; } ret = simple_setattr(idmap, dentry, iattr); - if (!ret) + if (!ret && ef) update_attr(ef, iattr); mutex_unlock(&eventfs_mutex); return ret; -- 2.42.0

1 year, 11 months

3
3
0 0

[PATCH 1/1] driver core: Remove warning on driver unbinding

by Herve Codina

During driver unbinding, __device_links_no_driver() can raise the following warning: --- 8< --- WARNING: CPU: 0 PID: 166 at drivers/base/core.c:1426 __device_links_no_driver+0xac/0xb4 ... Call trace: __device_links_no_driver+0xac/0xb4 device_links_driver_cleanup+0xa8/0xf0 device_release_driver_internal+0x204/0x240 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x158/0x414 platform_device_del.part.0+0x1c/0x88 platform_device_unregister+0x24/0x40 of_platform_device_destroy+0xfc/0x10c device_for_each_child_reverse+0x64/0xb4 devm_of_platform_populate_release+0x4c/0x84 release_nodes+0x5c/0x90 devres_release_all+0x8c/0xdc device_unbind_cleanup+0x18/0x68 device_release_driver_internal+0x20c/0x240 device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xf0/0x240 driver_detach+0x50/0x9c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 ... --- 8< --- This warning is raised because, during device removal, we unlink a consumer while its supplier links.status is DL_DEV_UNBINDING. Even if the link is not a SYNC_STATE_ONLY, the warning should not appear in that case. Filter out this warning in case of the supplier driver is unbinding. Fixes: 8c3e315d4296 ("driver core: Update device link status correctly for SYNC_STATE_ONLY links") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/base/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 17f2568e0a79..f4b09691998e 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1423,7 +1423,8 @@ static void __device_links_no_driver(struct device *dev) if (link->supplier->links.status == DL_DEV_DRIVER_BOUND) { WRITE_ONCE(link->status, DL_STATE_AVAILABLE); } else { - WARN_ON(!(link->flags & DL_FLAG_SYNC_STATE_ONLY)); + WARN_ON(!(link->flags & DL_FLAG_SYNC_STATE_ONLY) && + link->supplier->links.status != DL_DEV_UNBINDING); WRITE_ONCE(link->status, DL_STATE_DORMANT); } } -- 2.41.0

1 year, 11 months

2
2
0 0

[PATCH 1/1] driver core: Avoid using fwnode in __fwnode_link_del()

by Herve Codina

A refcount issue can appeared in __fwnode_link_del() due to the pr_debug() call: WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x191/0x1c0 ? srso_alias_return_thunk+0x5/0x7f ? prb_read_valid+0x1b/0x30 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 kobject_get+0x68/0x70 of_node_get+0x1e/0x30 of_fwnode_get+0x28/0x40 fwnode_full_name_string+0x34/0x90 fwnode_string+0xdb/0x140 vsnprintf+0x17b/0x630 va_format.isra.0+0x71/0x130 vsnprintf+0x17b/0x630 vprintk_store+0x162/0x4d0 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? try_to_wake_up+0x9c/0x620 ? rwsem_mark_wake+0x1b2/0x310 vprintk_emit+0xe4/0x2b0 _printk+0x5c/0x80 __dynamic_pr_debug+0x131/0x160 ? srso_alias_return_thunk+0x5/0x7f __fwnode_link_del+0x25/0xa0 fwnode_links_purge+0x39/0xb0 of_node_release+0xd9/0x180 kobject_put+0x7b/0x190 ... Indeed, an of_node is destroyed and so, of_node_release() is called because the of_node refcount reached 0. of_node_release() calls fwnode_links_purge() to purge the links and ended with __fwnode_link_del() calls. __fwnode_link_del calls pr_debug() to print the fwnodes (of_nodes) involved in the link and so this call is done while one of them is no more available (ie the one related to the of_node_release() call) Remove the pr_debug() call to avoid the use of the links fwnode while destroying the fwnode itself. Fixes: ebd6823af378 ("driver core: Add debug logs when fwnode links are added/deleted") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/base/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index f4b09691998e..62088c663014 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -109,8 +109,6 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) */ static void __fwnode_link_del(struct fwnode_link *link) { - pr_debug("%pfwf Dropping the fwnode link to %pfwf\n", - link->consumer, link->supplier); list_del(&link->s_hook); list_del(&link->c_hook); kfree(link); -- 2.41.0

1 year, 11 months

2
2
0 0

+ parisc-fix-mmap_base-calculation-when-stack-grows-upwards.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: parisc: fix mmap_base calculation when stack grows upwards has been added to the -mm mm-hotfixes-unstable branch. Its filename is parisc-fix-mmap_base-calculation-when-stack-grows-upwards.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: Helge Deller <deller(a)gmx.de> Subject: parisc: fix mmap_base calculation when stack grows upwards Date: Mon, 13 Nov 2023 11:12:57 +0100 Matoro reported various userspace crashes on the parisc platform with kernel 6.6 and bisected it to commit 3033cd430768 ("parisc: Use generic mmap top-down layout and brk randomization"). That commit switched parisc to use the common infrastructure to calculate mmap_base, but missed that the mmap_base() function takes care for architectures where the stack grows downwards only. Fix the mmap_base() calculation to include the stack-grows-upwards case and thus fix the userspace crashes on parisc. Link: https://lkml.kernel.org/r/ZVH2qeS1bG7/1J/l@p100 Fixes: 3033cd430768 ("parisc: Use generic mmap top-down layout and brk randomization") Signed-off-by: Helge Deller <deller(a)gmx.de> Reported-by: matoro <matoro_mailinglist_kernel(a)matoro.tk> Tested-by: matoro <matoro_mailinglist_kernel(a)matoro.tk> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/parisc/Kconfig | 6 +++--- arch/parisc/include/asm/elf.h | 10 +--------- arch/parisc/include/asm/processor.h | 2 ++ arch/parisc/kernel/sys_parisc.c | 2 +- mm/util.c | 10 ++++++++++ 5 files changed, 17 insertions(+), 13 deletions(-) --- a/arch/parisc/include/asm/elf.h~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/include/asm/elf.h @@ -349,15 +349,7 @@ struct pt_regs; /* forward declaration.. #define ELF_HWCAP 0 -/* Masks for stack and mmap randomization */ -#define BRK_RND_MASK (is_32bit_task() ? 0x07ffUL : 0x3ffffUL) -#define MMAP_RND_MASK (is_32bit_task() ? 0x1fffUL : 0x3ffffUL) -#define STACK_RND_MASK MMAP_RND_MASK - -struct mm_struct; -extern unsigned long arch_randomize_brk(struct mm_struct *); -#define arch_randomize_brk arch_randomize_brk - +#define STACK_RND_MASK 0x7ff /* 8MB of VA */ #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1 struct linux_binprm; --- a/arch/parisc/include/asm/processor.h~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/include/asm/processor.h @@ -47,6 +47,8 @@ #ifndef __ASSEMBLY__ +struct rlimit; +unsigned long mmap_upper_limit(struct rlimit *rlim_stack); unsigned long calc_max_stack_size(unsigned long stack_max); /* --- a/arch/parisc/Kconfig~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/Kconfig @@ -140,11 +140,11 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN default 8 config ARCH_MMAP_RND_BITS_MAX - default 24 if 64BIT - default 17 + default 18 if 64BIT + default 13 config ARCH_MMAP_RND_COMPAT_BITS_MAX - default 17 + default 13 # unless you want to implement ACPI on PA-RISC ... ;-) config PM --- a/arch/parisc/kernel/sys_parisc.c~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/arch/parisc/kernel/sys_parisc.c @@ -77,7 +77,7 @@ unsigned long calc_max_stack_size(unsign * indicating that "current" should be used instead of a passed-in * value from the exec bprm as done with arch_pick_mmap_layout(). */ -static unsigned long mmap_upper_limit(struct rlimit *rlim_stack) +unsigned long mmap_upper_limit(struct rlimit *rlim_stack) { unsigned long stack_base; --- a/mm/util.c~parisc-fix-mmap_base-calculation-when-stack-grows-upwards +++ a/mm/util.c @@ -414,6 +414,15 @@ static int mmap_is_legacy(struct rlimit static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) { +#ifdef CONFIG_STACK_GROWSUP + /* + * For an upwards growing stack the calculation is much simpler. + * Memory for the maximum stack size is reserved at the top of the + * task. mmap_base starts directly below the stack and grows + * downwards. + */ + return PAGE_ALIGN_DOWN(mmap_upper_limit(rlim_stack) - rnd); +#else unsigned long gap = rlim_stack->rlim_cur; unsigned long pad = stack_guard_gap; @@ -431,6 +440,7 @@ static unsigned long mmap_base(unsigned gap = MAX_GAP; return PAGE_ALIGN(STACK_TOP - gap - rnd); +#endif } void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack) _ Patches currently in -mm which might be from deller(a)gmx.de are parisc-fix-mmap_base-calculation-when-stack-grows-upwards.patch

1 year, 11 months

1
0
0 0

[PATCH v2] mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response

by Ronald Monthero

Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec fsl,ifc-nand 7e800000.nand: Controller is not responding main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l (detected by 1, t=2102 jiffies, g=7729, q=754) task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000 [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2) [<8064bb01>] (schedule) from [<8064dacd>] [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>] [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>] [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>] [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0) Cc: stable(a)vger.kernel.org Signed-off-by: Ronald Monthero <debug.penguin32(a)gmail.com> --- drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c index 20bb1e0cb5eb..42f8ea46b6a8 100644 --- a/drivers/mtd/nand/raw/fsl_ifc_nand.c +++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c @@ -21,7 +21,7 @@ #define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */ -#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum number of mSecs to wait for IFC NAND Machine */ struct fsl_ifc_ctrl; -- 2.34.1

1 year, 11 months

2
2
0 0

[PATCH net,v4, 2/3] hv_netvsc: Fix race of register_netdevice_notifier and VF register

by Haiyang Zhang

If VF NIC is registered earlier, NETDEV_REGISTER event is replayed, but NETDEV_POST_INIT is not. Move register_netdevice_notifier() earlier, so the call back function is set before probing. Cc: stable(a)vger.kernel.org Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()") Reported-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> --- v3: Divide it into two patches, suggested by Jakub Kicinski. v2: Fix rtnl_unlock() in error handling as found by Wojciech Drewek. --- drivers/net/hyperv/netvsc_drv.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 5e528a76f5f5..1d1491da303b 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2793,11 +2793,14 @@ static int __init netvsc_drv_init(void) } netvsc_ring_bytes = ring_size * PAGE_SIZE; + register_netdevice_notifier(&netvsc_netdev_notifier); + ret = vmbus_driver_register(&netvsc_drv); - if (ret) + if (ret) { + unregister_netdevice_notifier(&netvsc_netdev_notifier); return ret; + } - register_netdevice_notifier(&netvsc_netdev_notifier); return 0; } -- 2.25.1

1 year, 11 months

3
3
0 0

Re: Patch "fbdev: omapfb: Drop unused remove function" has been added to the 6.6-stable tree

by Uwe Kleine-König

On Sun, Nov 12, 2023 at 11:36:02PM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > fbdev: omapfb: Drop unused remove function > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > fbdev-omapfb-drop-unused-remove-function.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit a772de6bea2f5a9b5dad8afe0d9145fd8ee62564 > Author: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Date: Fri Nov 3 18:35:58 2023 +0100 > > fbdev: omapfb: Drop unused remove function > > [ Upstream commit fc6699d62f5f4facc3e934efd25892fc36050b70 ] > > OMAP2_VRFB is a bool, so the vrfb driver can never be compiled as a > module. With that __exit_p(vrfb_remove) always evaluates to NULL and > vrfb_remove() is unused. > > If the driver was compilable as a module, it would fail to build because > the type of vrfb_remove() isn't compatible with struct > platform_driver::remove(). (The former returns void, the latter int.) > > Fixes: aa1e49a3752f ("OMAPDSS: VRFB: add omap_vrfb_supported()") > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > Signed-off-by: Helge Deller <deller(a)gmx.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> While it doesn't hurt to backport this patch, I guess it also doesn't give any benefit (apart from increasing my patch count in stable :-). This commit just removes code that was thrown away by the compiler before. So I'd not backport it. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

1 year, 11 months

2
1
0 0

[git:media_stage/master] media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled Author: Hans de Goede <hdegoede(a)redhat.com> Date: Tue Oct 10 12:24:58 2023 +0200 Since the stream API is still experimental it is currently locked away behind the internal, default disabled, v4l2_subdev_enable_streams_api flag. Advertising V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled confuses userspace. E.g. it causes the following libcamera error: ERROR SimplePipeline simple.cpp:1497 Failed to reset routes for /dev/v4l-subdev1: Inappropriate ioctl for device Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled to avoid problems like this. Reported-by: Dennis Bonke <admin(a)dennisbonke.com> Fixes: 9a6b5bf4c1bb ("media: add V4L2_SUBDEV_CAP_STREAMS") Cc: stable(a)vger.kernel.org # for >= 6.3 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/v4l2-core/v4l2-subdev.c | 7 +++++++ 1 file changed, 7 insertions(+) --- diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index b92348ad61f6..31752c06d1f0 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -502,6 +502,13 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, V4L2_SUBDEV_CLIENT_CAP_STREAMS; int rval; + /* + * If the streams API is not enabled, remove V4L2_SUBDEV_CAP_STREAMS. + * Remove this when the API is no longer experimental. + */ + if (!v4l2_subdev_enable_streams_api) + streams_subdev = false; + switch (cmd) { case VIDIOC_SUBDEV_QUERYCAP: { struct v4l2_subdev_capability *cap = arg;

1 year, 11 months

1
0
0 0

[PATCH net] ppp: limit MRU to 64K

by Willem de Bruijn

From: Willem de Bruijn <willemb(a)google.com> ppp_sync_ioctl allows setting device MRU, but does not sanity check this input. Limit to a sane upper bound of 64KB. No implementation I could find generates larger than 64KB frames. RFC 2823 mentions an upper bound of PPP over SDL of 64KB based on the 16-bit length field. Other protocols will be smaller, such as PPPoE (9KB jumbo frame) and PPPoA (18190 maximum CPCS-SDU size, RFC 2364). PPTP and L2TP encapsulate in IP. Syzbot managed to trigger alloc warning in __alloc_pages: if (WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)) WARNING: CPU: 1 PID: 37 at mm/page_alloc.c:4544 __alloc_pages+0x3ab/0x4a0 mm/page_alloc.c:4544 __alloc_skb+0x12b/0x330 net/core/skbuff.c:651 __netdev_alloc_skb+0x72/0x3f0 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3225 [inline] dev_alloc_skb include/linux/skbuff.h:3238 [inline] ppp_sync_input drivers/net/ppp/ppp_synctty.c:669 [inline] ppp_sync_receive+0xff/0x680 drivers/net/ppp/ppp_synctty.c:334 tty_ldisc_receive_buf+0x14c/0x180 drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x70/0xb0 drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x261/0x780 drivers/tty/tty_buffer.c:494 process_one_work+0x884/0x15c0 kernel/workqueue.c:2630 With call ioctl$PPPIOCSMRU1(r1, 0x40047452, &(0x7f0000000100)=0x5e6417a8) Similar code exists in other drivers that implement ppp_channel_ops ioctl PPPIOCSMRU. Those might also be in scope. Notably excluded from this are pppol2tp_ioctl and pppoe_ioctl. This code goes back to the start of git history. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+6177e1f90d92583bcc58(a)syzkaller.appspotmail.com Signed-off-by: Willem de Bruijn <willemb(a)google.com> --- drivers/net/ppp/ppp_synctty.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c index ea261a628786..52d05ce4a281 100644 --- a/drivers/net/ppp/ppp_synctty.c +++ b/drivers/net/ppp/ppp_synctty.c @@ -453,6 +453,10 @@ ppp_sync_ioctl(struct ppp_channel *chan, unsigned int cmd, unsigned long arg) case PPPIOCSMRU: if (get_user(val, (int __user *) argp)) break; + if (val > U16_MAX) { + err = -EINVAL; + break; + } if (val < PPP_MRU) val = PPP_MRU; ap->mru = val; -- 2.43.0.rc0.421.g78406f8d94-goog

1 year, 11 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2023