February 2025 - Linux-stable-mirror

Re: [PATCH] net: fix uninitialised access in mii_nway_restart()

by Qasim Ijaz

On Tue, Feb 18, 2025 at 02:10:08AM +0100, Andrew Lunn wrote: > On Tue, Feb 18, 2025 at 12:24:43AM +0000, Qasim Ijaz wrote: > > In mii_nway_restart() during the line: > > > > bmcr = mii->mdio_read(mii->dev, mii->phy_id, MII_BMCR); > > > > The code attempts to call mii->mdio_read which is ch9200_mdio_read(). > > > > ch9200_mdio_read() utilises a local buffer, which is initialised > > with control_read(): > > > > unsigned char buff[2]; > > > > However buff is conditionally initialised inside control_read(): > > > > if (err == size) { > > memcpy(data, buf, size); > > } > > > > If the condition of "err == size" is not met, then buff remains > > uninitialised. Once this happens the uninitialised buff is accessed > > and returned during ch9200_mdio_read(): > > > > return (buff[0] | buff[1] << 8); > > > > The problem stems from the fact that ch9200_mdio_read() ignores the > > return value of control_read(), leading to uinit-access of buff. > > > > To fix this we should check the return value of control_read() > > and return early on error. > > What about get_mac_address()? > > If you find a bug, it is a good idea to look around and see if there > are any more instances of the same bug. I could be wrong, but it seems > like get_mac_address() suffers from the same problem? Thank you for the feedback Andrew. I checked get_mac_address() before sending this patch and to me it looks like it does check the return value of control_read(). It accumulates the return value of each control_read() call into rd_mac_len and then checks if it not equal to what is expected (ETH_ALEN which is 6), I believe each call should return 2. > > Andrew

1 month, 1 week

2
3
0 0

Apply 3 commits for 6.13.y

by Miguel Ojeda

Hi Greg, Sasha, Please consider applying the following commits for 6.13.y: 27c7518e7f1c ("rust: finish using custom FFI integer types") 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") 9b98be76855f ("rust: cleanup unnecessary casts") They should apply cleanly. This backports the custom FFI integer types, which in turn solves a build failure under `CONFIG_RUST_FW_LOADER_ABSTRACTIONS=y`. I will have to send something similar to 6.12.y, but it requires more commits -- I may do the `alloc` backport first we discussed the other day. Thanks! Cheers, Miguel

1 month, 1 week

4
5
0 0

[PATCH v2] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN

by Günther Noack

With this, processes without CAP_SYS_ADMIN are able to use TIOCLINUX with subcode TIOCL_SETSEL, in the selection modes TIOCL_SETPOINTER, TIOCL_SELCLEAR and TIOCL_SELMOUSEREPORT. TIOCL_SETSEL was previously changed to require CAP_SYS_ADMIN, as this IOCTL let callers change the selection buffer and could be used to simulate keypresses. These three TIOCL_SETSEL selection modes, however, are safe to use, as they do not modify the selection buffer. This fixes a mouse support regression that affected Emacs (invisible mouse cursor). Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/ee3ec63269b43b34e1c90dd8c9743bf8@finder.org Fixes: 8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-paste subcommands") Signed-off-by: Günther Noack <gnoack(a)google.com> --- Changes in V2: * Removed comment in vt.c (per Greg's suggestion) * CC'd stable@ * I *kept* the CAP_SYS_ADMIN check *after* copy_from_user(), with the reasoning that: 1. I do not see a good alternative to reorder the code here. We need the data from copy_from_user() in order to know whether the CAP_SYS_ADMIN check even needs to be performed. 2. A previous get_user() from an adjacent memory region already worked (making this a very unlikely failure) I would still appreciate a more formal Tested-by from Hanno (hint, hint) :) --- drivers/tty/vt/selection.c | 14 ++++++++++++++ drivers/tty/vt/vt.c | 2 -- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index 564341f1a74f..0bd6544e30a6 100644 --- a/drivers/tty/vt/selection.c +++ b/drivers/tty/vt/selection.c @@ -192,6 +192,20 @@ int set_selection_user(const struct tiocl_selection __user *sel, if (copy_from_user(&v, sel, sizeof(*sel))) return -EFAULT; + /* + * TIOCL_SELCLEAR, TIOCL_SELPOINTER and TIOCL_SELMOUSEREPORT are OK to + * use without CAP_SYS_ADMIN as they do not modify the selection. + */ + switch (v.sel_mode) { + case TIOCL_SELCLEAR: + case TIOCL_SELPOINTER: + case TIOCL_SELMOUSEREPORT: + break; + default: + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + } + return set_selection_kernel(&v, tty); } diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 96842ce817af..be5564ed8c01 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -3345,8 +3345,6 @@ int tioclinux(struct tty_struct *tty, unsigned long arg) switch (type) { case TIOCL_SETSEL: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; return set_selection_user(param, tty); case TIOCL_PASTESEL: if (!capable(CAP_SYS_ADMIN)) -- 2.47.1.613.gc27f4b7a9f-goog

1 month, 1 week

6
13
0 0

[PATCH v2] arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix serdes_ln_ctrl reg-masks

by Siddharth Vadapalli

Commit under Fixes added the 'idle-states' property for SERDES4 lane muxes without defining the corresponding register offsets and masks for it in the 'mux-reg-masks' property within the 'serdes_ln_ctrl' node. Fix this. Fixes: 7287d423f138 ("arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux") Cc: stable(a)vger.kernel.org Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Patch is based on commit 76544811c850 Merge tag 'drm-fixes-2025-02-28' of https://gitlab.freedesktop.org/drm/kernel of the master branch of Mainline Linux. v1: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250227061643.… Changes since v1: - Updated offsets to begin from 0x40 instead of 0x30. This is because SERDES3 is not present in J784S4. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi index 83bbf94b58d1..51cb8f3fd1c8 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi @@ -84,7 +84,9 @@ serdes_ln_ctrl: mux-controller@4080 { <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ - <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ + <0x28 0x3>, <0x2c 0x3>, /* SERDES2 lane2/3 select */ + <0x40 0x3>, <0x44 0x3>, /* SERDES4 lane0/1 select */ + <0x48 0x3>, <0x4c 0x3>; /* SERDES4 lane2/3 select */ idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>, <J784S4_SERDES0_LANE2_IP3_UNUSED>, -- 2.34.1

1 month, 1 week

2
1
0 0

FAILED: patch "[PATCH] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 879f70382ff3e92fc854589ada3453e3f5f5b601 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025022418-clergyman-hacker-f7f7@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 879f70382ff3e92fc854589ada3453e3f5f5b601 Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak(a)intel.com> Date: Fri, 14 Feb 2025 16:19:51 +0200 Subject: [PATCH] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro The format of the port width field in the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the x3 lane mode for HDMI FRL has a different encoding in the two registers. To account for this use the TRANS_DDI_FUNC_CTL's own port width macro. Cc: <stable(a)vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Imre Deak <imre.deak(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.… (cherry picked from commit 76120b3a304aec28fef4910204b81a12db8974da) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index c977b74f82f0..82bf6c654de2 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -809,8 +809,8 @@ gen11_dsi_configure_transcoder(struct intel_encoder *encoder, /* select data lane width */ tmp = intel_de_read(display, TRANS_DDI_FUNC_CTL(display, dsi_trans)); - tmp &= ~DDI_PORT_WIDTH_MASK; - tmp |= DDI_PORT_WIDTH(intel_dsi->lane_count); + tmp &= ~TRANS_DDI_PORT_WIDTH_MASK; + tmp |= TRANS_DDI_PORT_WIDTH(intel_dsi->lane_count); /* select input pipe */ tmp &= ~TRANS_DDI_EDP_INPUT_MASK;

1 month, 1 week

4
5
0 0

[PATCH v1 2/2] mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq

by Uladzislau Rezki (Sony)

Currently kvfree_rcu() APIs use a system workqueue which is "system_unbound_wq" to driver RCU machinery to reclaim a memory. Recently, it has been noted that the following kernel warning can be observed: <snip> workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 Workqueue: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? timer_recalc_next_expiry+0x190/0x190 ? check_flush_dependency+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 worker_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- <snip> To address this switch to use of independent WQ_MEM_RECLAIM workqueue, so the rules are not violated from workqueue framework point of view. Apart of that, since kvfree_rcu() does reclaim memory it is worth to go with WQ_MEM_RECLAIM type of wq because it is designed for this purpose. Cc: <stable(a)vger.kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Keith Busch <kbusch(a)kernel.org> Closes: https://www.spinics.net/lists/kernel/msg5563270.html Fixes: 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()"), Reported-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> --- mm/slab_common.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 4030907b6b7d..4c9f0a87f733 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1304,6 +1304,8 @@ module_param(rcu_min_cached_objs, int, 0444); static int rcu_delay_page_cache_fill_msec = 5000; module_param(rcu_delay_page_cache_fill_msec, int, 0444); +static struct workqueue_struct *rcu_reclaim_wq; + /* Maximum number of jiffies to wait before draining a batch. */ #define KFREE_DRAIN_JIFFIES (5 * HZ) #define KFREE_N_BATCHES 2 @@ -1632,10 +1634,10 @@ __schedule_delayed_monitor_work(struct kfree_rcu_cpu *krcp) if (delayed_work_pending(&krcp->monitor_work)) { delay_left = krcp->monitor_work.timer.expires - jiffies; if (delay < delay_left) - mod_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + mod_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); return; } - queue_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + queue_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); } static void @@ -1733,7 +1735,7 @@ kvfree_rcu_queue_batch(struct kfree_rcu_cpu *krcp) // "free channels", the batch can handle. Break // the loop since it is done with this CPU thus // queuing an RCU work is _always_ success here. - queued = queue_rcu_work(system_unbound_wq, &krwp->rcu_work); + queued = queue_rcu_work(rcu_reclaim_wq, &krwp->rcu_work); WARN_ON_ONCE(!queued); break; } @@ -1883,7 +1885,7 @@ run_page_cache_worker(struct kfree_rcu_cpu *krcp) if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING && !atomic_xchg(&krcp->work_in_progress, 1)) { if (atomic_read(&krcp->backoff_page_cache_fill)) { - queue_delayed_work(system_unbound_wq, + queue_delayed_work(rcu_reclaim_wq, &krcp->page_cache_work, msecs_to_jiffies(rcu_delay_page_cache_fill_msec)); } else { @@ -2120,6 +2122,10 @@ void __init kvfree_rcu_init(void) int i, j; struct shrinker *kfree_rcu_shrinker; + rcu_reclaim_wq = alloc_workqueue("kvfree_rcu_reclaim", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0); + WARN_ON(!rcu_reclaim_wq); + /* Clamp it to [0:100] seconds interval. */ if (rcu_delay_page_cache_fill_msec < 0 || rcu_delay_page_cache_fill_msec > 100 * MSEC_PER_SEC) { -- 2.39.5

1 month, 1 week

5
5
0 0

[PATCH] arm64: tegra: delete the Orin NX/Nano suspend key

by Ivy Huang

From: Ninad Malwade <nmalwade(a)nvidia.com> As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available on this device family. It should not be used at all on Orin NX/Nano. Having this unused pin mapped as the suspend key can lead to unpredictable behavior for low power modes. Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" button. However, we cannot have two gpio-keys mapped to the same GPIO. Therefore delete the "suspend" key. Cc: stable(a)vger.kernel.org Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") Signed-off-by: Ninad Malwade <nmalwade(a)nvidia.com> Signed-off-by: Ivy Huang <yijuh(a)nvidia.com> --- arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi index 19340d13f789..41821354bbda 100644 --- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi @@ -227,13 +227,6 @@ wakeup-event-action = <EV_ACT_ASSERTED>; wakeup-source; }; - - key-suspend { - label = "Suspend"; - gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>; - linux,input-type = <EV_KEY>; - linux,code = <KEY_SLEEP>; - }; }; fan: pwm-fan { -- 2.17.1

1 month, 1 week

2
1
0 0

[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

by Stefan Eichenberger

From: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> When usb_control_msg is used in the get_bMaxPacketSize0 function, the USB pipe does not include the endpoint device number. This can cause failures when a usb hub port is reinitialized after encountering a bad cable connection. As a result, the system logs the following error messages: usb usb2-port1: cannot reset (err = -32) usb usb2-port1: Cannot enable. Maybe the USB cable is bad? usb usb2-port1: attempt power cycle usb 2-1: new high-speed USB device number 5 using ci_hdrc usb 2-1: device descriptor read/8, error -71 The problem began after commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads"). There usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the macro usb_rcvaddr0pipe, which does not include the endpoint device number. usb_get_device_descriptor, on the other hand, used the macro usb_rcvctrlpipe, which includes the endpoint device number. By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe instead of usb_rcvaddr0pipe, the issue can be resolved. This change will ensure that the endpoint device number is included in the USB pipe, preventing reinitialization failures. If the endpoint has not set the device number yet, it will still work because the device number is 0 in udev. Cc: stable(a)vger.kernel.org Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Signed-off-by: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> --- Before commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this proposed change, usb_rcvctrlpipe will be used which includes devnum for the pipe. I'm not sure if this might have some side effects. However, my understanding is that devnum is set to the right value (might also be 0 if not initialised) before get_bMaxPacketSize0 is called. Therefore, this should work but please let me know if I'm wrong on this. --- drivers/usb/core/hub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..59e38780f76d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev) EXPORT_SYMBOL_GPL(usb_ep0_reinit); #define usb_sndaddr0pipe() (PIPE_CONTROL << 30) -#define usb_rcvaddr0pipe() ((PIPE_CONTROL << 30) | USB_DIR_IN) static int hub_set_address(struct usb_device *udev, int devnum) { @@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev, for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) { /* Start with invalid values in case the transfer fails */ buf->bDescriptorType = buf->bMaxPacketSize0 = 0; - rc = usb_control_msg(udev, usb_rcvaddr0pipe(), + rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, size, -- 2.45.2

1 month, 1 week

3
4
0 0

[PATCH 5.10.y 0/3] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series backports three upstream commits: - 135ffc7 "bpf, vsock: Invoke proto::close on close()" - fcdd224 "vsock: Keep the binding until socket destruction" - 78dafe1 "vsock: Orphan socket after transport release" Although this version of the kernel does not support sockmap, I think backporting this patch can be useful to reduce conflicts in future backports [1]. It does not harm the system. The comment it introduces in the code can be misleading. I added some words in the commit to explain the situation. The other two commits are untouched, fixing a use-after free[2] and a null-ptr-deref[3] respectively. [1]https://lore.kernel.org/stable/f7lr3ftzo66sl6phlcygh4xx4spga4b6je37fhawjr… [2]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… Cheers, Luigi To: Stefano Garzarella <sgarzare(a)redhat.com> To: Michal Luczaj <mhal(a)rbox.co> To: stable(a)vger.kernel.org Signed-off-by: Luigi Leonardi <leonardi(a)redhat.com> --- Michal Luczaj (3): bpf, vsock: Invoke proto::close on close() vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 77 +++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 27 deletions(-) --- base-commit: f0a53361993a94f602df6f35e78149ad2ac12c89 change-id: 20250220-backport_fix_5_10-0ae85f834bc4 Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

1 month, 1 week

2
5
0 0

[PATCHv3 perf/core] uprobes: Harden uretprobe syscall trampoline check

by Jiri Olsa

Jann reported [1] possible issue when trampoline_check_ip returns address near the bottom of the address space that is allowed to call into the syscall if uretprobes are not set up. Though the mmap minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall checks for that. [1] https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341… Cc: Kees Cook <kees(a)kernel.org> Cc: Eyal Birger <eyal.birger(a)gmail.com> Cc: stable(a)vger.kernel.org Fixes: ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe") Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> Reviewed-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> --- v3 changes: - used ~0UL instead of -1 [Alexei] - used UPROBE_NO_TRAMPOLINE_VADDR in uprobe_get_trampoline_vaddr [Masami] - added unlikely [Andrii] - I kept the review/ack tags, because I think the change is basically the same, please scream otherwise arch/x86/kernel/uprobes.c | 14 +++++++++----- include/linux/uprobes.h | 2 ++ kernel/events/uprobes.c | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c index 5a952c5ea66b..9194695662b2 100644 --- a/arch/x86/kernel/uprobes.c +++ b/arch/x86/kernel/uprobes.c @@ -357,19 +357,23 @@ void *arch_uprobe_trampoline(unsigned long *psize) return &insn; } -static unsigned long trampoline_check_ip(void) +static unsigned long trampoline_check_ip(unsigned long tramp) { - unsigned long tramp = uprobe_get_trampoline_vaddr(); - return tramp + (uretprobe_syscall_check - uretprobe_trampoline_entry); } SYSCALL_DEFINE0(uretprobe) { struct pt_regs *regs = task_pt_regs(current); - unsigned long err, ip, sp, r11_cx_ax[3]; + unsigned long err, ip, sp, r11_cx_ax[3], tramp; + + /* If there's no trampoline, we are called from wrong place. */ + tramp = uprobe_get_trampoline_vaddr(); + if (unlikely(tramp == UPROBE_NO_TRAMPOLINE_VADDR)) + goto sigill; - if (regs->ip != trampoline_check_ip()) + /* Make sure the ip matches the only allowed sys_uretprobe caller. */ + if (unlikely(regs->ip != trampoline_check_ip(tramp))) goto sigill; err = copy_from_user(r11_cx_ax, (void __user *)regs->sp, sizeof(r11_cx_ax)); diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h index a40efdda9052..2e46b69ff0a6 100644 --- a/include/linux/uprobes.h +++ b/include/linux/uprobes.h @@ -39,6 +39,8 @@ struct page; #define MAX_URETPROBE_DEPTH 64 +#define UPROBE_NO_TRAMPOLINE_VADDR (~0UL) + struct uprobe_consumer { /* * handler() can return UPROBE_HANDLER_REMOVE to signal the need to diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 597b9e036e5f..c5d6307bc5bc 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -2156,8 +2156,8 @@ void uprobe_copy_process(struct task_struct *t, unsigned long flags) */ unsigned long uprobe_get_trampoline_vaddr(void) { + unsigned long trampoline_vaddr = UPROBE_NO_TRAMPOLINE_VADDR; struct xol_area *area; - unsigned long trampoline_vaddr = -1; /* Pairs with xol_add_vma() smp_store_release() */ area = READ_ONCE(current->mm->uprobes_state.xol_area); /* ^^^ */ -- 2.48.1

1 month, 1 week

7
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025