April 2025 - Linux-stable-mirror

[PATCH 6.6.y 1/2] usb: typec: fix potential array underflow in ucsi_ccg_sync_control()

by bin.lan.cn＠windriver.com

From: Dan Carpenter <dan.carpenter(a)linaro.org> [ Upstream commit e56aac6e5a25630645607b6856d4b2a17b2311a5 ] The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/c69ef0b3-61b0-4dde-98dd-97b97f81d912@stanley.moun… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Minor context change fixed. 13f2ec3115c8 ("usb: typec: ucsi: simplify command sending API") rename ucsi_ccg_sync_write to ucsi_ccg_sync_control in v6.11, so this patch is applied in ucsi_ccg_sync_write in v6.6.] Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Build test passed. --- drivers/usb/typec/ucsi/ucsi_ccg.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c b/drivers/usb/typec/ucsi/ucsi_ccg.c index 7c7f388aac96..3ef02d35bfbe 100644 --- a/drivers/usb/typec/ucsi/ucsi_ccg.c +++ b/drivers/usb/typec/ucsi/ucsi_ccg.c @@ -585,6 +585,10 @@ static int ucsi_ccg_sync_write(struct ucsi *ucsi, unsigned int offset, uc->has_multiple_dp) { con_index = (uc->last_cmd_sent >> 16) & UCSI_CMD_CONNECTOR_MASK; + if (con_index == 0) { + ret = -EINVAL; + goto unlock; + } con = &uc->ucsi->connector[con_index - 1]; ucsi_ccg_update_set_new_cam_cmd(uc, con, (u64 *)val); } @@ -600,6 +604,7 @@ static int ucsi_ccg_sync_write(struct ucsi *ucsi, unsigned int offset, err_clear_bit: clear_bit(DEV_CMD_PENDING, &uc->flags); pm_runtime_put_sync(uc->dev); +unlock: mutex_unlock(&uc->lock); return ret; -- 2.34.1

2 months, 1 week

2
3
0 0

[PATCH 6.6.y] btrfs: fix qgroup reserve leaks in cow_file_range

by jianqi.ren.cn＠windriver.com

From: Boris Burkov <boris(a)bur.io> [ Upstream commit 30479f31d44d47ed00ae0c7453d9b253537005b2 ] In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent. Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we *do* clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path. This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked Cases 2 and 3 in the out_reserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfs_free_qgroup_data. Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Boris Burkov <boris(a)bur.io> Signed-off-by: David Sterba <dsterba(a)suse.com> [Minor conflict resolved due to code context change.] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Verified the build test --- fs/btrfs/inode.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index cedffa567a75..fc127182067b 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1546,6 +1546,7 @@ static noinline int cow_file_range(struct btrfs_inode *inode, locked_page, clear_bits, page_ops); + btrfs_qgroup_free_data(inode, NULL, start, cur_alloc_size, NULL); start += cur_alloc_size; } @@ -1559,6 +1560,7 @@ static noinline int cow_file_range(struct btrfs_inode *inode, clear_bits |= EXTENT_CLEAR_DATA_RESV; extent_clear_unlock_delalloc(inode, start, end, locked_page, clear_bits, page_ops); + btrfs_qgroup_free_data(inode, NULL, start, cur_alloc_size, NULL); } return ret; } @@ -2222,13 +2224,15 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode, */ if (cow_start != (u64)-1) cur_offset = cow_start; - if (cur_offset < end) + if (cur_offset < end) { extent_clear_unlock_delalloc(inode, cur_offset, end, locked_page, EXTENT_LOCKED | EXTENT_DELALLOC | EXTENT_DEFRAG | EXTENT_DO_ACCOUNTING, PAGE_UNLOCK | PAGE_START_WRITEBACK | PAGE_END_WRITEBACK); + btrfs_qgroup_free_data(inode, NULL, cur_offset, end - cur_offset + 1, NULL); + } btrfs_free_path(path); return ret; } -- 2.34.1

2 months, 1 week

2
1
0 0

[PATCH 5.15.y] smb: client: fix potential UAF in is_valid_oplock_break()

by Cliff Liu

From: Paulo Alcantara <pc(a)manguebit.com> [ Upstream commit 69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29 ] Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. Cc: stable(a)vger.kernel.org Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> [Minor context change fixed] Signed-off-by: Cliff Liu <donghua.liu(a)windriver.com> Signed-off-by: He Zhe <Zhe.He(a)windriver.com> --- Verified the build test. --- fs/cifs/misc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c index 33328eae03d7..c7e2bf7a0a0d 100644 --- a/fs/cifs/misc.c +++ b/fs/cifs/misc.c @@ -464,6 +464,8 @@ is_valid_oplock_break(char *buffer, struct TCP_Server_Info *srv) spin_lock(&cifs_tcp_ses_lock); list_for_each(tmp, &srv->smb_ses_list) { ses = list_entry(tmp, struct cifs_ses, smb_ses_list); + if (cifs_ses_exiting(ses)) + continue; list_for_each(tmp1, &ses->tcon_list) { tcon = list_entry(tmp1, struct cifs_tcon, tcon_list); if (tcon->tid != buf->Tid) -- 2.34.1

2 months, 1 week

2
1
0 0

[REQUEST] efi backport for 6.6+

by Hamza Mahfooz

Hi, Please include commit ec4696925da6 ("efi/libstub: Bump up EFI_MMAP_NR_SLACK_SLOTS to 32") in kernel 6.6+, it allows us to be able to boot some arm64 efi machines without any workarounds. Thanks, Hamza

2 months, 1 week

1
0
0 0

[PATCH] Revert "PCI: Avoid reset when disabled via sysfs"

by Alex Williamson

This reverts commit 479380efe1625e251008d24b2810283db60d6fcd. The reset_method attribute on a PCI device is only intended to manage the availability of function scoped resets for a device. It was never intended to restrict resets targeting the bus or slot. In introducing a restriction that each device must support function level reset by testing pci_reset_supported(), we essentially create a catch-22, that a device must have a function scope reset in order to support bus/slot reset, when we use bus/slot reset to effect a reset of a device that does not support a function scoped reset, especially multi-function devices. This breaks the majority of uses cases where vfio-pci uses bus/slot resets to manage multifunction devices that do not support function scoped resets. Fixes: 479380efe162 ("PCI: Avoid reset when disabled via sysfs") Reported-by: Cal Peake <cp(a)absolutedigital.net> Link: https://lore.kernel.org/all/808e1111-27b7-f35b-6d5c-5b275e73677b@absolutedi… Cc: stable(a)vger.kernel.org Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- drivers/pci/pci.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 4d7c9f64ea24..e77d5b53c0ce 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5429,8 +5429,6 @@ static bool pci_bus_resettable(struct pci_bus *bus) return false; list_for_each_entry(dev, &bus->devices, bus_list) { - if (!pci_reset_supported(dev)) - return false; if (dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET || (dev->subordinate && !pci_bus_resettable(dev->subordinate))) return false; @@ -5507,8 +5505,6 @@ static bool pci_slot_resettable(struct pci_slot *slot) list_for_each_entry(dev, &slot->bus->devices, bus_list) { if (!dev->slot || dev->slot != slot) continue; - if (!pci_reset_supported(dev)) - return false; if (dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET || (dev->subordinate && !pci_bus_resettable(dev->subordinate))) return false; -- 2.48.1

2 months, 1 week

3
2
0 0

[PATCH] Bluetooth: vhci: Avoid needless snprintf() calls

by Kees Cook

Avoid double-copying of string literals. Use a "const char *" for each string instead of copying from .rodata into stack and then into the skb. We can go directly from .rodata to the skb. This also works around a Clang bug (that has since been fixed[1]). Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401250927.1poZERd6-lkp@intel.com/ Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support") Link: https://github.com/llvm/llvm-project/commit/ea2e66aa8b6e363b89df66dc44275a0… [1] Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <kees(a)kernel.org> --- Cc: Marcel Holtmann <marcel(a)holtmann.org> Cc: Luiz Augusto von Dentz <luiz.dentz(a)gmail.com> Cc: Josh Poimboeuf <jpoimboe(a)kernel.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: linux-bluetooth(a)vger.kernel.org --- drivers/bluetooth/hci_vhci.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c index 7651321d351c..9ac22e4a070b 100644 --- a/drivers/bluetooth/hci_vhci.c +++ b/drivers/bluetooth/hci_vhci.c @@ -289,18 +289,18 @@ static void vhci_coredump(struct hci_dev *hdev) static void vhci_coredump_hdr(struct hci_dev *hdev, struct sk_buff *skb) { - char buf[80]; + const char *buf; - snprintf(buf, sizeof(buf), "Controller Name: vhci_ctrl\n"); + buf = "Controller Name: vhci_ctrl\n"; skb_put_data(skb, buf, strlen(buf)); - snprintf(buf, sizeof(buf), "Firmware Version: vhci_fw\n"); + buf = "Firmware Version: vhci_fw\n"; skb_put_data(skb, buf, strlen(buf)); - snprintf(buf, sizeof(buf), "Driver: vhci_drv\n"); + buf = "Driver: vhci_drv\n"; skb_put_data(skb, buf, strlen(buf)); - snprintf(buf, sizeof(buf), "Vendor: vhci\n"); + buf = "Vendor: vhci\n"; skb_put_data(skb, buf, strlen(buf)); } -- 2.34.1

2 months, 1 week

4
3
0 0

[PATCH v3] loop: LOOP_SET_FD: send uevents for partitions

by Thomas Weißschuh

Remove the suppression of the uevents before scanning for partitions. The partitions inherit their suppression settings from their parent device, which lead to the uevents being dropped. This is similar to the same changes for LOOP_CONFIGURE done in commit bb430b694226 ("loop: LOOP_CONFIGURE: send uevents for partitions"). Fixes: 498ef5c777d9 ("loop: suppress uevents while reconfiguring the device") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Changes in v3: - Rebase onto block/block-6.15 - Drop already applied patch "loop: properly send KOBJ_CHANGED uevent for disk device" - Add patch to fix partition uevents for LOOP_SET_FD - Link to v2: https://lore.kernel.org/r/20250415-loop-uevent-changed-v2-1-0c4e6a923b2a@li… Changes in v2: - Use correct Fixes tag - Rework commit message slightly - Rebase onto v6.15-rc1 - Link to v1: https://lore.kernel.org/r/20250317-loop-uevent-changed-v1-1-cb29cb91b62d@li… --- drivers/block/loop.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 3be7f00e7fc740da2745ffbccfcebe53eef2ddaa..e9ec7a45f3f2d1dd2a82b3506f3740089a20ae05 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -662,12 +662,12 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev, * dependency. */ fput(old_file); + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); if (partscan) loop_reread_partitions(lo); error = 0; done: - dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); kobject_uevent(&disk_to_dev(lo->lo_disk)->kobj, KOBJ_CHANGE); return error; @@ -675,6 +675,7 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev, loop_global_unlock(lo, is_loop); out_putf: fput(file); + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); goto done; } --- base-commit: 7ed2a771b5fb3edee9c4608181235c30b40bb042 change-id: 20250307-loop-uevent-changed-aa3690f43e03 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

2 months, 1 week

3
2
0 0

Re: [regression 6.1.y] Regression from 476c1dfefab8 ("mm: Don't pin ZERO_PAGE in pin_user_pages()") with pci-passthrough for both KVM VMs and booting in xen DomU

by Salvatore Bonaccorso

[resent with correct stable(a)vger.kernel.org list] On Tue, Apr 15, 2025 at 08:59:19PM +0200, Salvatore Bonaccorso wrote: > Hi > > [Apologies if this has been reported already but I have not found an > already filled corresponding report] > > After updating from the 6.1.129 based version to 6.1.133, various > users have reported that their VMs do not boot anymore up (both KVM > and under Xen) if pci-passthrough is involved. The reports are at: > > https://bugs.debian.org/1102889 > https://bugs.debian.org/1102914 > https://bugs.debian.org/1103153 > > Milan Broz bisected the issues and found that the commit introducing > the problems can be tracked down to backport of c8070b787519 ("mm: > Don't pin ZERO_PAGE in pin_user_pages()") from 6.5-rc1 which got > backported as 476c1dfefab8 ("mm: Don't pin ZERO_PAGE in > pin_user_pages()") in 6.1.130. See https://bugs.debian.org/1102914#60 > > #regzbot introduced: 476c1dfefab8b98ae9c3e3ad283c2ac10d30c774 > > 476c1dfefab8b98ae9c3e3ad283c2ac10d30c774 is the first bad commit > commit 476c1dfefab8b98ae9c3e3ad283c2ac10d30c774 > Author: David Howells <dhowells(a)redhat.com> > Date: Fri May 26 22:41:40 2023 +0100 > > mm: Don't pin ZERO_PAGE in pin_user_pages() > > [ Upstream commit c8070b78751955e59b42457b974bea4a4fe00187 ] > > Make pin_user_pages*() leave a ZERO_PAGE unpinned if it extracts a pointer > to it from the page tables and make unpin_user_page*() correspondingly > ignore a ZERO_PAGE when unpinning. We don't want to risk overrunning a > zero page's refcount as we're only allowed ~2 million pins on it - > something that userspace can conceivably trigger. > > Add a pair of functions to test whether a page or a folio is a ZERO_PAGE. > > Signed-off-by: David Howells <dhowells(a)redhat.com> > cc: Christoph Hellwig <hch(a)infradead.org> > cc: David Hildenbrand <david(a)redhat.com> > cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > cc: Andrew Morton <akpm(a)linux-foundation.org> > cc: Jens Axboe <axboe(a)kernel.dk> > cc: Al Viro <viro(a)zeniv.linux.org.uk> > cc: Matthew Wilcox <willy(a)infradead.org> > cc: Jan Kara <jack(a)suse.cz> > cc: Jeff Layton <jlayton(a)kernel.org> > cc: Jason Gunthorpe <jgg(a)nvidia.com> > cc: Logan Gunthorpe <logang(a)deltatee.com> > cc: Hillf Danton <hdanton(a)sina.com> > cc: Christian Brauner <brauner(a)kernel.org> > cc: Linus Torvalds <torvalds(a)linux-foundation.org> > cc: linux-fsdevel(a)vger.kernel.org > cc: linux-block(a)vger.kernel.org > cc: linux-kernel(a)vger.kernel.org > cc: linux-mm(a)kvack.org > Reviewed-by: Lorenzo Stoakes <lstoakes(a)gmail.com> > Reviewed-by: Christoph Hellwig <hch(a)lst.de> > Acked-by: David Hildenbrand <david(a)redhat.com> > Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowells@redhat.com > Signed-off-by: Jens Axboe <axboe(a)kernel.dk> > Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > Documentation/core-api/pin_user_pages.rst | 6 ++++++ > include/linux/mm.h | 26 ++++++++++++++++++++++++-- > mm/gup.c | 31 ++++++++++++++++++++++++++++++- > 3 files changed, 60 insertions(+), 3 deletions(-) > > Milan verified that the issue persists in 6.1.134 so far and the patch > itself cannot be just reverted. > > The failures all have a similar pattern, when pci-passthrough is used > for a pci devide, for instance under qemu the bootup will fail with: > > qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:03:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}: VFIO_MAP_DMA failed: Cannot allocate memory > qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:03:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}: vfio 0000:03:00.0: failed to setup container > > (in the case as reported by Milan). > > Any ideas here? > > Regards, > Salvatore

2 months, 1 week

1
0
0 0

[PATCH] rust: kbuild: use `pound` to support GNU Make < 4.3

by Miguel Ojeda

GNU Make 4.3 changed the behavior of `#` inside commands in commit c6966b323811 ("[SV 20513] Un-escaped # are not comments in function invocations"): * WARNING: Backward-incompatibility! Number signs (#) appearing inside a macro reference or function invocation no longer introduce comments and should not be escaped with backslashes: thus a call such as: foo := $(shell echo '#') is legal. Previously the number sign needed to be escaped, for example: foo := $(shell echo '\#') Now this latter will resolve to "\#". If you want to write makefiles portable to both versions, assign the number sign to a variable: H := \# foo := $(shell echo '$H') This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. Unlike other commits in the kernel about this issue, such as commit 633174a7046e ("lib/raid6/test/Makefile: Use $(pound) instead of \# for Make 4.3"), that fixed the issue for newer GNU Makes, in our case it was the opposite, i.e. we need to fix it for the older ones: someone building with e.g. 4.2.1 gets the following error: scripts/Makefile.compiler:81: *** unterminated call to function 'call': missing ')'. Stop. Thus use the existing variable to fix it. Reported-by: moyi geek Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/near/51… Cc: stable(a)vger.kernel.org Fixes: e72a076c620f ("kbuild: fix issues with rustc-option") Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- scripts/Makefile.compiler | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler index 7ed7f92a7daa..f4fcc1eaaeae 100644 --- a/scripts/Makefile.compiler +++ b/scripts/Makefile.compiler @@ -79,7 +79,7 @@ ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3)) # Usage: MY_RUSTFLAGS += $(call __rustc-option,$(RUSTC),$(MY_RUSTFLAGS),-Cinstrument-coverage,-Zinstrument-coverage) # TODO: remove RUSTC_BOOTSTRAP=1 when we raise the minimum GNU Make version to 4.4 __rustc-option = $(call try-run,\ - echo '#![allow(missing_docs)]#![feature(no_core)]#![no_core]' | RUSTC_BOOTSTRAP=1\ + echo '$(pound)![allow(missing_docs)]$(pound)![feature(no_core)]$(pound)![no_core]' | RUSTC_BOOTSTRAP=1\ $(1) --sysroot=/dev/null $(filter-out --sysroot=/dev/null --target=%,$(2)) $(3)\ --crate-type=rlib --out-dir=$(TMPOUT) --emit=obj=- - >/dev/null,$(3),$(4)) base-commit: a3cd5f507b72c0532c3345b6913557efab34f405 -- 2.49.0

2 months, 1 week

4
4
0 0

+ lib-test_ubsanc-fix-panic-from-test_ubsan_out_of_bounds.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: lib/test_ubsan.c: fix panic from test_ubsan_out_of_bounds has been added to the -mm mm-hotfixes-unstable branch. Its filename is lib-test_ubsanc-fix-panic-from-test_ubsan_out_of_bounds.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: Mostafa Saleh <smostafa(a)google.com> Subject: lib/test_ubsan.c: fix panic from test_ubsan_out_of_bounds Date: Mon, 14 Apr 2025 21:36:48 +0000 Running lib_ubsan.ko on arm64 (without CONFIG_UBSAN_TRAP) panics the kernel [ 31.616546] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: test_ubsan_out_of_bounds+0x158/0x158 [test_ubsan] [ 31.646817] CPU: 3 UID: 0 PID: 179 Comm: insmod Not tainted 6.15.0-rc2 #1 PREEMPT [ 31.648153] Hardware name: linux,dummy-virt (DT) [ 31.648970] Call trace: [ 31.649345] show_stack+0x18/0x24 (C) [ 31.650960] dump_stack_lvl+0x40/0x84 [ 31.651559] dump_stack+0x18/0x24 [ 31.652264] panic+0x138/0x3b4 [ 31.652812] __ktime_get_real_seconds+0x0/0x10 [ 31.653540] test_ubsan_load_invalid_value+0x0/0xa8 [test_ubsan] [ 31.654388] init_module+0x24/0xff4 [test_ubsan] [ 31.655077] do_one_initcall+0xd4/0x280 [ 31.655680] do_init_module+0x58/0x2b4 That happens because the test corrupts other data in the stack: 400: d5384108 mrs x8, sp_el0 404: f9426d08 ldr x8, [x8, #1240] 408: f85f83a9 ldur x9, [x29, #-8] 40c: eb09011f cmp x8, x9 410: 54000301 b.ne 470 <test_ubsan_out_of_bounds+0x154> // b.any As there is no guarantee the compiler will order the local variables as declared in the module: volatile char above[4] = { }; /* Protect surrounding memory. */ volatile int arr[4]; volatile char below[4] = { }; /* Protect surrounding memory. */ So, instead of writing out-of-bound, we can read out-of-bound which still triggers UBSAN but doesn't corrupt the stack. Link: https://lkml.kernel.org/r/20250414213648.2660150-1-smostafa@google.com Fixes: 4a26f49b7b3d ubsan: ("expand tests and reporting") Signed-off-by: Mostafa Saleh <smostafa(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Macro Elver <elver(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/test_ubsan.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) --- a/lib/test_ubsan.c~lib-test_ubsanc-fix-panic-from-test_ubsan_out_of_bounds +++ a/lib/test_ubsan.c @@ -77,18 +77,15 @@ static void test_ubsan_shift_out_of_boun static void test_ubsan_out_of_bounds(void) { - volatile int i = 4, j = 5, k = -1; - volatile char above[4] = { }; /* Protect surrounding memory. */ + volatile int j = 5, k = -1; + volatile int scratch[4] = { }; volatile int arr[4]; - volatile char below[4] = { }; /* Protect surrounding memory. */ - - above[0] = below[0]; UBSAN_TEST(CONFIG_UBSAN_BOUNDS, "above"); - arr[j] = i; + scratch[1] = arr[j]; UBSAN_TEST(CONFIG_UBSAN_BOUNDS, "below"); - arr[k] = i; + scratch[2] = arr[k]; } enum ubsan_test_enum { _ Patches currently in -mm which might be from smostafa(a)google.com are lib-test_ubsanc-fix-panic-from-test_ubsan_out_of_bounds.patch

2 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025