September 2024 - Linux-stable-mirror

[PATCH v3] zram: don't free statically defined names

by Andrey Skvortsov

When CONFIG_ZRAM_MULTI_COMP isn't set ZRAM_SECONDARY_COMP can hold default_compressor, because it's the same offset as ZRAM_PRIMARY_COMP, so we need to make sure that we don't attempt to kfree() the statically defined compressor name. This is detected by KASAN. ================================================================== Call trace: kfree+0x60/0x3a0 zram_destroy_comps+0x98/0x198 [zram] zram_reset_device+0x22c/0x4a8 [zram] reset_store+0x1bc/0x2d8 [zram] dev_attr_store+0x44/0x80 sysfs_kf_write+0xfc/0x188 kernfs_fop_write_iter+0x28c/0x428 vfs_write+0x4dc/0x9b8 ksys_write+0x100/0x1f8 __arm64_sys_write+0x74/0xb8 invoke_syscall+0xd8/0x260 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xc8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 ================================================================== Signed-off-by: Andrey Skvortsov <andrej.skvortzov(a)gmail.com> Fixes: 684826f8271a ("zram: free secondary algorithms names") Cc: <stable(a)vger.kernel.org> --- Changes in v2: - removed comment from source code about freeing statically defined compression - removed part of KASAN report from commit description - added information about CONFIG_ZRAM_MULTI_COMP into commit description Changes in v3: - modified commit description based on Sergey's comment - changed start for-loop to ZRAM_PRIMARY_COMP drivers/block/zram/zram_drv.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index c3d245617083d..ad9c9bc3ccfc5 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -2115,8 +2115,10 @@ static void zram_destroy_comps(struct zram *zram) zram->num_active_comps--; } - for (prio = ZRAM_SECONDARY_COMP; prio < ZRAM_MAX_COMPS; prio++) { - kfree(zram->comp_algs[prio]); + for (prio = ZRAM_PRIMARY_COMP; prio < ZRAM_MAX_COMPS; prio++) { + /* Do not free statically defined compression algorithms */ + if (zram->comp_algs[prio] != default_compressor) + kfree(zram->comp_algs[prio]); zram->comp_algs[prio] = NULL; } -- 2.45.2

1 year, 1 month

5
17
0 0

[regression] frozen usb mouse pointer at boot

by Linux regression tracking (Thorsten Leemhuis)

Hi, Thorsten here, the Linux kernel's regression tracker. I noticed a report about a linux-6.6.y regression in bugzilla.kernel.org that appears to be caused by this commit from Dan applied by Greg: 15fffc6a5624b1 ("driver core: Fix uevent_show() vs driver detach race") [v6.11-rc3, v6.10.5, v6.6.46, v6.1.105, v5.15.165, v5.10.224, v5.4.282, v4.19.320] The reporter did not check yet if mainline is affected; decided to forward the report by mail nevertheless, as the maintainer for the subsystem is also the maintainer for the stable tree. ;-) To quote from https://bugzilla.kernel.org/show_bug.cgi?id=219244 : > The symptoms of this bug are as follows: > > - After booting (to the graphical login screen) the mouse pointer > would frozen and only after unplugging and plugging-in again the usb > plug of the mouse would the mouse be working as expected. > - If one would log in without fixing the mouse issue, the mouse > pointer would still be frozen after login. > - The usb keyboard usually is not affected even though plugged into > the same usb-hub - thus logging in is possible. > - The mouse pointer is also frozen if the usb connector is plugged > into a different usb-port (different from the usb-hub) > - The pointer is moveable via the inbuilt synaptics trackpad > > > The kernel log shows almost the same messages (not sure if the > differences mean anything in regards to this bug) for the initial > recognizing the mouse (frozen mouse pointer) and the re-plugged-in mouse > (and subsequently moveable mouse pointer): > > [kernel] [ 8.763158] usb 1-2.2.1.2: new low-speed USB device number 10 using xhci_hcd > [kernel] [ 8.956028] usb 1-2.2.1.2: New USB device found, idVendor=045e, idProduct=00cb, bcdDevice= 1.04 > [kernel] [ 8.956036] usb 1-2.2.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > [kernel] [ 8.956039] usb 1-2.2.1.2: Product: Microsoft Basic Optical Mouse v2.0 > [kernel] [ 8.956041] usb 1-2.2.1.2: Manufacturer: Microsoft > [kernel] [ 8.963554] input: Microsoft Microsoft Basic Optical Mouse v2.0 as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2.1/1-2.2.1.2/1-2.2.1.2:1.0/0003:045E:00CB.0002/input/input18 > [kernel] [ 8.964417] hid-generic 0003:045E:00CB.0002: input,hidraw1: USB HID v1.11 Mouse [Microsoft Microsoft Basic Optical Mouse v2.0 ] on usb-0000:00:14.0-2.2.1.2/input0 > > [kernel] [ 31.258381] usb 1-2.2.1.2: USB disconnect, device number 10 > [kernel] [ 31.595051] usb 1-2.2.1.2: new low-speed USB device number 16 using xhci_hcd > [kernel] [ 31.804002] usb 1-2.2.1.2: New USB device found, idVendor=045e, idProduct=00cb, bcdDevice= 1.04 > [kernel] [ 31.804010] usb 1-2.2.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > [kernel] [ 31.804013] usb 1-2.2.1.2: Product: Microsoft Basic Optical Mouse v2.0 > [kernel] [ 31.804016] usb 1-2.2.1.2: Manufacturer: Microsoft > [kernel] [ 31.812933] input: Microsoft Microsoft Basic Optical Mouse v2.0 as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2.1/1-2.2.1.2/1-2.2.1.2:1.0/0003:045E:00CB.0004/input/input20 > [kernel] [ 31.814028] hid-generic 0003:045E:00CB.0004: input,hidraw1: USB HID v1.11 Mouse [Microsoft Microsoft Basic Optical Mouse v2.0 ] on usb-0000:00:14.0-2.2.1.2/input0 > > Differences: > > ../0003:045E:00CB.0002/input/input18 vs ../0003:045E:00CB.0004/input/input20 > > and > > hid-generic 0003:045E:00CB.0002 vs hid-generic 0003:045E:00CB.0004 > > > The connector / usb-port was not changed in this case! > > > The symptoms of this bug have been present at one point in the > recent > past, but with kernel v6.6.45 (or maybe even some version before that) > it was fine. But with 6.6.45 it seems to be definitely fine. > > But with v6.6.46 the symptoms returned. That's the reason I > suspected > the kernel to be the cause of this issue. So I did some bisecting - > which wasn't easy because that bug would often times not appear if the > system was simply rebooted into the test kernel. > As the bug would definitely appear on the affected kernels (v6.6.46 > ff) after shutting down the system for the night and booting the next > day, I resorted to simulating the over-night powering-off by shutting > the system down, unplugging the power and pressing the power button to > get rid of residual voltage. But even then a few times the bug would > only appear if I repeated this procedure before booting the system again > with the respective kernel. > > This is on a Thinkpad with Kaby Lake and integrated Intel graphics. > Even though it is a laptop, it is used as a desktop device, and the > internal battery is disconnected, the removable battery is removed as > the system is plugged-in via the power cord at all times (when in use)! > Also, the system has no power (except for the bios battery, of > course) > over night as the power outlet is switched off if the device is not in use. > > Not sure if this affects the issue - or how it does. But for > successful bisecting I had to resort to the above procedure. > > Bisecting the issue (between the release commits of v6.6.45 and > v6.6.46) resulted in this commit [1] being the probable culprit. > > I then tested kernel v6.6.49. It still produced the bug for me. So I > reverted the changes of the assumed "bad commit" and re-compiled kernel > v6.6.49. With this modified kernel the bug seems to be gone. > > Now, I assume the commit has a reason for being introduced, but > maybe > needs some adjusting in order to avoid this bug I'm experiencing on my > system. > Also, I can't say why the issue appeared in the past even without > this > commit being present, as I haven't bisected any kernel version before > v6.6.45. > > > [1]: > > 4d035c743c3e391728a6f81cbf0f7f9ca700cf62 is the first bad commit > commit 4d035c743c3e391728a6f81cbf0f7f9ca700cf62 > Author: Dan Williams <dan.j.williams(a)intel.com> > Date: Fri Jul 12 12:42:09 2024 -0700 > > driver core: Fix uevent_show() vs driver detach race > > commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c upstream. > > uevent_show() wants to de-reference dev->driver->name. There is no clean See the ticket for more details. Note, you have to use bugzilla to reach the reporter, as I sadly[1] can not CCed them in mails like this. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. [1] because bugzilla.kernel.org tells users upon registration their "email address will never be displayed to logged out users" P.S.: let me use this mail to also add the report to the list of tracked regressions to ensure it's doesn't fall through the cracks: #regzbot introduced: 4d035c743c3e391728a6f81cbf0f7f9ca700cf62 #regzbot from: brmails+k #regzbot duplicate: https://bugzilla.kernel.org/show_bug.cgi?id=219244 #regzbot title: driver core: frozen usb mouse pointer at boot #regzbot ignore-activity

1 year, 1 month

3
5
0 0

+ mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: avoid unconditional one-tick sleep when swapcache_prepare fails has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails.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: Barry Song <v-songbaohua(a)oppo.com> Subject: mm: avoid unconditional one-tick sleep when swapcache_prepare fails Date: Fri, 27 Sep 2024 09:19:36 +1200 Commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache") introduced an unconditional one-tick sleep when `swapcache_prepare()` fails, which has led to reports of UI stuttering on latency-sensitive Android devices. To address this, we can use a waitqueue to wake up tasks that fail `swapcache_prepare()` sooner, instead of always sleeping for a full tick. While tasks may occasionally be woken by an unrelated `do_swap_page()`, this method is preferable to two scenarios: rapid re-entry into page faults, which can cause livelocks, and multiple millisecond sleeps, which visibly degrade user experience. Oven's testing shows that a single waitqueue resolves the UI stuttering issue. If a 'thundering herd' problem becomes apparent later, a waitqueue hash similar to `folio_wait_table[PAGE_WAIT_TABLE_SIZE]` for page bit locks can be introduced. Link: https://lkml.kernel.org/r/20240926211936.75373-1-21cnbao@gmail.com Fixes: 13ddaf26be32 ("mm/swap: fix race when skipping swapcache") Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> Reported-by: Oven Liyang <liyangouwen1(a)oppo.com> Tested-by: Oven Liyang <liyangouwen1(a)oppo.com> Cc: Kairui Song <kasong(a)tencent.com> Cc: "Huang, Ying" <ying.huang(a)intel.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Yosry Ahmed <yosryahmed(a)google.com> Cc: SeongJae Park <sj(a)kernel.org> Cc: Kalesh Singh <kaleshsingh(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/mm/memory.c~mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails +++ a/mm/memory.c @@ -4192,6 +4192,8 @@ static struct folio *alloc_swap_folio(st } #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +static DECLARE_WAIT_QUEUE_HEAD(swapcache_wq); + /* * We enter with non-exclusive mmap_lock (to exclude vma changes, * but allow concurrent faults), and pte mapped but not yet locked. @@ -4204,6 +4206,7 @@ vm_fault_t do_swap_page(struct vm_fault { struct vm_area_struct *vma = vmf->vma; struct folio *swapcache, *folio = NULL; + DECLARE_WAITQUEUE(wait, current); struct page *page; struct swap_info_struct *si = NULL; rmap_t rmap_flags = RMAP_NONE; @@ -4302,7 +4305,9 @@ vm_fault_t do_swap_page(struct vm_fault * Relax a bit to prevent rapid * repeated page faults. */ + add_wait_queue(&swapcache_wq, &wait); schedule_timeout_uninterruptible(1); + remove_wait_queue(&swapcache_wq, &wait); goto out_page; } need_clear_cache = true; @@ -4609,8 +4614,10 @@ unlock: pte_unmap_unlock(vmf->pte, vmf->ptl); out: /* Clear the swap cache pin for direct swapin after PTL unlock */ - if (need_clear_cache) + if (need_clear_cache) { swapcache_clear(si, entry, nr_pages); + wake_up(&swapcache_wq); + } if (si) put_swap_device(si); return ret; @@ -4625,8 +4632,10 @@ out_release: folio_unlock(swapcache); folio_put(swapcache); } - if (need_clear_cache) + if (need_clear_cache) { swapcache_clear(si, entry, nr_pages); + wake_up(&swapcache_wq); + } if (si) put_swap_device(si); return ret; _ Patches currently in -mm which might be from v-songbaohua(a)oppo.com are mm-avoid-unconditional-one-tick-sleep-when-swapcache_prepare-fails.patch

1 year, 1 month

1
0
0 0

+ selftests-mm-fixed-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftests-mm-fixed-incorrect-buffer-mirror-size-in-hmm2-double_map-test.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: Donet Tom <donettom(a)linux.ibm.com> Subject: selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test Date: Fri, 27 Sep 2024 00:07:52 -0500 The hmm2 double_map test was failing due to an incorrect buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr size was 6 * PAGE_SIZE. The test failed because the kernel's copy_to_user function was attempting to copy a 6 * PAGE_SIZE buffer to buffer->mirror. Since the size of buffer->mirror was incorrect, copy_to_user failed. This patch corrects the buffer->mirror size to 6 * PAGE_SIZE. Test Result without this patch ============================== # RUN hmm2.hmm2_device_private.double_map ... # hmm-tests.c:1680:double_map:Expected ret (-14) == 0 (0) # double_map: Test terminated by assertion # FAIL hmm2.hmm2_device_private.double_map not ok 53 hmm2.hmm2_device_private.double_map Test Result with this patch =========================== # RUN hmm2.hmm2_device_private.double_map ... # OK hmm2.hmm2_device_private.double_map ok 53 hmm2.hmm2_device_private.double_map Link: https://lkml.kernel.org/r/20240927050752.51066-1-donettom@linux.ibm.com Fixes: fee9f6d1b8df ("mm/hmm/test: add selftests for HMM") Signed-off-by: Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: J��r��me Glisse <jglisse(a)redhat.com> Cc: Kees Cook <keescook(a)chromium.org> Cc: Mark Brown <broonie(a)kernel.org> Cc: Przemek Kitszel <przemyslaw.kitszel(a)intel.com> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Ralph Campbell <rcampbell(a)nvidia.com> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/hmm-tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/mm/hmm-tests.c~selftests-mm-fixed-incorrect-buffer-mirror-size-in-hmm2-double_map-test +++ a/tools/testing/selftests/mm/hmm-tests.c @@ -1657,7 +1657,7 @@ TEST_F(hmm2, double_map) buffer->fd = -1; buffer->size = size; - buffer->mirror = malloc(npages); + buffer->mirror = malloc(size); ASSERT_NE(buffer->mirror, NULL); /* Reserve a range of addresses. */ _ Patches currently in -mm which might be from donettom(a)linux.ibm.com are selftests-mm-fixed-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch

1 year, 1 month

1
0
0 0

+ device-dax-correct-pgoff-align-in-dax_set_mapping.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: device-dax: correct pgoff align in dax_set_mapping() has been added to the -mm mm-hotfixes-unstable branch. Its filename is device-dax-correct-pgoff-align-in-dax_set_mapping.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: "Kun(llfl)" <llfl(a)linux.alibaba.com> Subject: device-dax: correct pgoff align in dax_set_mapping() Date: Fri, 27 Sep 2024 15:45:09 +0800 pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. Link: https://lkml.kernel.org/r/23c02a03e8d666fef11bbe13e85c69c8b4ca0624.17274216… Fixes: b9b5777f09be ("device-dax: use ALIGN() for determining pgoff") Signed-off-by: Kun(llfl) <llfl(a)linux.alibaba.com> Tested-by: JianXiong Zhao <zhaojianxiong.zjx(a)alibaba-inc.com> Cc: Joao Martins <joao.m.martins(a)oracle.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/dax/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/dax/device.c~device-dax-correct-pgoff-align-in-dax_set_mapping +++ a/drivers/dax/device.c @@ -86,7 +86,7 @@ static void dax_set_mapping(struct vm_fa nr_pages = 1; pgoff = linear_page_index(vmf->vma, - ALIGN(vmf->address, fault_size)); + ALIGN_DOWN(vmf->address, fault_size)); for (i = 0; i < nr_pages; i++) { struct page *page = pfn_to_page(pfn_t_to_pfn(pfn) + i); _ Patches currently in -mm which might be from llfl(a)linux.alibaba.com are device-dax-correct-pgoff-align-in-dax_set_mapping.patch

1 year, 1 month

1
0
0 0

[PATCH 5.15.y] vfio/pci: fix potential memory leak in vfio_intx_enable()

by Oleksandr Tymoshenko

From: Ye Bin <yebin10(a)huawei.com> [ Upstream commit 82b951e6fbd31d85ae7f4feb5f00ddd4c5d256e2 ] If kzalloc() failed will lead to 'name' memory leak. Fixes: 18c198c96a81 ("vfio/pci: Create persistent INTx handler") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Acked-by: Reinette Chatre <reinette.chatre(a)intel.com> Link: https://lore.kernel.org/r/20240415015029.3699844-1-yebin10@huawei.com Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Oleksandr Tymoshenko <ovt(a)google.com> --- drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c index cb55f96b4f03..f20512c413f7 100644 --- a/drivers/vfio/pci/vfio_pci_intrs.c +++ b/drivers/vfio/pci/vfio_pci_intrs.c @@ -181,8 +181,10 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev, return -ENOMEM; vdev->ctx = kzalloc(sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL); - if (!vdev->ctx) + if (!vdev->ctx) { + kfree(name); return -ENOMEM; + } vdev->num_ctx = 1; -- 2.46.1.824.gd892dcdcdd-goog

1 year, 1 month

1
0
0 0

[PATCH] tools/nolibc: s390: include std.h

by Thomas Weißschuh

arch-s390.h uses types from std.h, but does not include it. Depending on the inclusion order the compilation can fail. Include std.h explicitly to avoid these errors. Fixes: 404fa87c0eaf ("tools/nolibc: s390: provide custom implementation for sys_fork") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- tools/include/nolibc/arch-s390.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h index 2ec13d8b9a2db80efa8d6cbbbd01bfa3d0059de2..f9ab83a219b8a2d5e53b0b303d8bf0bf78280d5f 100644 --- a/tools/include/nolibc/arch-s390.h +++ b/tools/include/nolibc/arch-s390.h @@ -10,6 +10,7 @@ #include "compiler.h" #include "crt.h" +#include "std.h" /* Syscalls for s390: * - registers are 64-bit --- base-commit: e477dba5442c0af7acb9e8bbbbde1108a37ed39c change-id: 20240927-nolibc-s390-std-h-cbb13f70fa73 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

1 year, 1 month

1
0
0 0

[PATCH 6.1.y] vfio/pci: fix potential memory leak in vfio_intx_enable()

by Oleksandr Tymoshenko

From: Ye Bin <yebin10(a)huawei.com> [ Upstream commit 82b951e6fbd31d85ae7f4feb5f00ddd4c5d256e2 ] If kzalloc() failed will lead to 'name' memory leak. Fixes: 18c198c96a81 ("vfio/pci: Create persistent INTx handler") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Acked-by: Reinette Chatre <reinette.chatre(a)intel.com> Link: https://lore.kernel.org/r/20240415015029.3699844-1-yebin10@huawei.com Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Oleksandr Tymoshenko <ovt(a)google.com> --- drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c index 03246a59b553..5cbcde32ff79 100644 --- a/drivers/vfio/pci/vfio_pci_intrs.c +++ b/drivers/vfio/pci/vfio_pci_intrs.c @@ -215,8 +215,10 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev, return -ENOMEM; vdev->ctx = kzalloc(sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL_ACCOUNT); - if (!vdev->ctx) + if (!vdev->ctx) { + kfree(name); return -ENOMEM; + } vdev->num_ctx = 1; -- 2.46.1.824.gd892dcdcdd-goog

1 year, 1 month

1
0
0 0

[PATCH v5.4-v4.19] crypto: aead,cipher - zeroize key buffer after use

by hsimeliere.opensource＠witekio.com

From: Hailey Mothershead <hailmo(a)amazon.com> commit 23e4099bdc3c8381992f9eb975c79196d6755210 upstream. I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. Signed-off-by: Hailey Mothershead <hailmo(a)amazon.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource(a)witekio.com> --- crypto/aead.c | 3 +-- crypto/cipher.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/crypto/aead.c b/crypto/aead.c index 9688ada13981..f8b2cd0567f1 100644 --- a/crypto/aead.c +++ b/crypto/aead.c @@ -45,8 +45,7 @@ static int setkey_unaligned(struct crypto_aead *tfm, const u8 *key, alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1); memcpy(alignbuffer, key, keylen); ret = crypto_aead_alg(tfm)->setkey(tfm, alignbuffer, keylen); - memset(alignbuffer, 0, keylen); - kfree(buffer); + kzfree(buffer); return ret; } diff --git a/crypto/cipher.c b/crypto/cipher.c index 57836c30a49a..3d3fa8d0d533 100644 --- a/crypto/cipher.c +++ b/crypto/cipher.c @@ -38,8 +38,7 @@ static int setkey_unaligned(struct crypto_tfm *tfm, const u8 *key, alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1); memcpy(alignbuffer, key, keylen); ret = cia->cia_setkey(tfm, alignbuffer, keylen); - memset(alignbuffer, 0, keylen); - kfree(buffer); + kzfree(buffer); return ret; } -- 2.43.0

1 year, 1 month

1
0
0 0

self-debug using ptrace bad behavior?

by Sim Brahmi

Hello, I am unsure if this is the 'correct' behavior for ptrace. If you run ptrace_traceme followed by ptrace_attach, then the process attaches its own parent to itself and cannot be attached by another thing. The attach call errors out, but GDB does report something attached to it. I am unsure if Bash does this itself perhaps. It's a bit hard for me to reason about because my debugging skills are bad and trying 'strace' with bash -c ./thing, or just on the thing itself gives -1 on both ptrace calls as strace attaches to it. similarly with GDB. Unsure how to debug this. https://gist.github.com/x64-elf-sh42/83393e319ad8280b8704fbe3f499e381 to compile simply: gcc test.c -o thingy This code works on my machine which is: Linux 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux GDB -p on the pid reports that another pid is attached and the operation is illegal. That other pid is the bash shell that i spawned this binary from (code in gist). it's useful for anti-debugging, but it seems odd it will attach it's parent to the process since that's not actually doing the attach call. If anything i'd expect the pid attached to itself, rather than the parent getting attached. The first call to ptrace (traceme) gets return value 0. The second call (attach) gets return value -1. That does seem correct, but yet there is something 'attached' when i try to use GDB. If I only do the traceme call, it does not get attached by Bash, so it looks totally like the 'attach' call has a side effect of attaching the parent, rather than just only failing. Kind regards, ~sh42

1 year, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024