- Linux-stable-mirror - lists.linaro.org

[PATCH v2] arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2

by Diederik de Haas

Page 13 of the PineTab2 v2 schematic dd 20230417 shows VCCIO4's power source is VCCIO_WL. Page 19 shows that VCCIO_WL is connected to VCCA1V8_PMU, so fix the PineTab2 dtsi to reflect that. Fixes: 1b7e19448f8f ("arm64: dts: rockchip: Add devicetree for Pine64 PineTab2") Cc: stable(a)vger.kernel.org Reviewed-by: Dragan Simic <dsimic(a)manjaro.org> Signed-off-by: Diederik de Haas <diederik(a)cknow-tech.com> --- Changes since v1: - Added Fixes tag (Dragan) - Added R-b tag arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi index d0e38412d56a..08bf40de17ea 100644 --- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi @@ -789,7 +789,7 @@ &pmu_io_domains { vccio1-supply = <&vccio_acodec>; vccio2-supply = <&vcc_1v8>; vccio3-supply = <&vccio_sd>; - vccio4-supply = <&vcc_1v8>; + vccio4-supply = <&vcca1v8_pmu>; vccio5-supply = <&vcc_1v8>; vccio6-supply = <&vcc1v8_dvp>; vccio7-supply = <&vcc_3v3>; -- 2.51.0

1 month

2
1
0 0

+ mm-secretmem-fix-use-after-free-race-in-fault-handler.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/secretmem: fix use-after-free race in fault handler has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-secretmem-fix-use-after-free-race-in-fault-handler.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: Lance Yang <lance.yang(a)linux.dev> Subject: mm/secretmem: fix use-after-free race in fault handler Date: Fri, 31 Oct 2025 20:09:55 +0800 When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed. Link: https://lkml.kernel.org/r/20251031120955.92116-1-lance.yang@linux.dev Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lance Yang <lance.yang(a)linux.dev> Reported-by: Google Big Sleep <big-sleep-vuln-reports(a)google.com> Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWK… Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/secretmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/secretmem.c~mm-secretmem-fix-use-after-free-race-in-fault-handler +++ a/mm/secretmem.c @@ -82,13 +82,13 @@ retry: __folio_mark_uptodate(folio); err = filemap_add_folio(mapping, folio, offset, gfp); if (unlikely(err)) { - folio_put(folio); /* * If a split of large page was required, it * already happened when we marked the page invalid * which guarantees that this call won't fail */ set_direct_map_default_noflush(folio_page(folio, 0)); + folio_put(folio); if (err == -EEXIST) goto retry; _ Patches currently in -mm which might be from lance.yang(a)linux.dev are mm-secretmem-fix-use-after-free-race-in-fault-handler.patch mm-khugepaged-guard-is_zero_pfn-calls-with-pte_present.patch

1 month

1
0
0 0

[PATCH v2 1/5] mm, swap: do not perform synchronous discard during allocation

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> Since commit 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path"), swap allocation is protected by a local lock, which means we can't do any sleeping calls during allocation. However, the discard routine is not taken well care of. When the swap allocator failed to find any usable cluster, it would look at the pending discard cluster and try to issue some blocking discards. It may not necessarily sleep, but the cond_resched at the bio layer indicates this is wrong when combined with a local lock. And the bio GFP flag used for discard bio is also wrong (not atomic). It's arguable whether this synchronous discard is helpful at all. In most cases, the async discard is good enough. And the swap allocator is doing very differently at organizing the clusters since the recent change, so it is very rare to see discard clusters piling up. So far, no issues have been observed or reported with typical SSD setups under months of high pressure. This issue was found during my code review. But by hacking the kernel a bit: adding a mdelay(500) in the async discard path, this issue will be observable with WARNING triggered by the wrong GFP and cond_resched in the bio layer for debug builds. So now let's apply a hotfix for this issue: remove the synchronous discard in the swap allocation path. And when order 0 is failing with all cluster list drained on all swap devices, try to do a discard following the swap device priority list. If any discards released some cluster, try the allocation again. This way, we can still avoid OOM due to swap failure if the hardware is very slow and memory pressure is extremely high. This may cause more fragmentation issues if the discarding hardware is really slow. Ideally, we want to discard pending clusters before continuing to iterate the fragment cluster lists. This can be implemented in a cleaner way if we clean up the device list iteration part first. Cc: stable(a)vger.kernel.org Fixes: 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path") Acked-by: Nhat Pham <nphamcs(a)gmail.com> Signed-off-by: Kairui Song <kasong(a)tencent.com> --- mm/swapfile.c | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index cb2392ed8e0e..33e0bd905c55 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1101,13 +1101,6 @@ static unsigned long cluster_alloc_swap_entry(struct swap_info_struct *si, int o goto done; } - /* - * We don't have free cluster but have some clusters in discarding, - * do discard now and reclaim them. - */ - if ((si->flags & SWP_PAGE_DISCARD) && swap_do_scheduled_discard(si)) - goto new_cluster; - if (order) goto done; @@ -1394,6 +1387,33 @@ static bool swap_alloc_slow(swp_entry_t *entry, return false; } +/* + * Discard pending clusters in a synchronized way when under high pressure. + * Return: true if any cluster is discarded. + */ +static bool swap_sync_discard(void) +{ + bool ret = false; + int nid = numa_node_id(); + struct swap_info_struct *si, *next; + + spin_lock(&swap_avail_lock); + plist_for_each_entry_safe(si, next, &swap_avail_heads[nid], avail_lists[nid]) { + spin_unlock(&swap_avail_lock); + if (get_swap_device_info(si)) { + if (si->flags & SWP_PAGE_DISCARD) + ret = swap_do_scheduled_discard(si); + put_swap_device(si); + } + if (ret) + return true; + spin_lock(&swap_avail_lock); + } + spin_unlock(&swap_avail_lock); + + return false; +} + /** * folio_alloc_swap - allocate swap space for a folio * @folio: folio we want to move to swap @@ -1432,11 +1452,17 @@ int folio_alloc_swap(struct folio *folio, gfp_t gfp) } } +again: local_lock(&percpu_swap_cluster.lock); if (!swap_alloc_fast(&entry, order)) swap_alloc_slow(&entry, order); local_unlock(&percpu_swap_cluster.lock); + if (unlikely(!order && !entry.val)) { + if (swap_sync_discard()) + goto again; + } + /* Need to call this even if allocation failed, for MEMCG_SWAP_FAIL. */ if (mem_cgroup_try_charge_swap(folio, entry)) goto out_free; -- 2.51.0

1 month

2
1
0 0

[PATCH 0/3] PCI: meson: Fix the parsing of DBI region

by Manivannan Sadhasivam

Hi, This compile tested only series aims to fix the DBI parsing issue repored in [1]. The issue stems from the fact that the DT and binding describing 'dbi' region as 'elbi' from the start. Now, both binding and DTs are fixed and the driver is reworked to work with both old and new DTs. Note: The driver patch is OK to be backported till 6.2 where the common resource parsing code was introduced. But the DTS patch should not be backported. And I'm not sure about the backporting of the binding. Please test this series on the Meson board with old and new DTs. - Mani Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Manivannan Sadhasivam (3): dt-bindings: PCI: amlogic: Fix the register name of the DBI region arm64: dts: amlogic: Fix the register name of the 'DBI' region PCI: meson: Fix parsing the DBI register region .../devicetree/bindings/pci/amlogic,axg-pcie.yaml | 6 +++--- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++-- arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +- drivers/pci/controller/dwc/pci-meson.c | 18 +++++++++++++++--- drivers/pci/controller/dwc/pcie-designware.c | 12 +++++++----- 5 files changed, 28 insertions(+), 14 deletions(-) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251031-pci-meson-fix-c8b651bc6662 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

1 month

1
1
0 0

[PATCH v2 1/2] vfio: Fix ksize arg while copying user struct in vfio_df_ioctl_bind_iommufd()

by Raghavendra Rao Ananta

For the cases where user includes a non-zero value in 'token_uuid_ptr' field of 'struct vfio_device_bind_iommufd', the copy_struct_from_user() in vfio_df_ioctl_bind_iommufd() fails with -E2BIG. For the 'minsz' passed, copy_struct_from_user() expects the newly introduced field to be zero-ed, which would be incorrect in this case. Fix this by passing the actual size of the kernel struct. If working with a newer userspace, copy_struct_from_user() would copy the 'token_uuid_ptr' field, and if working with an old userspace, it would zero out this field, thus still retaining backward compatibility. Fixes: 86624ba3b522 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD") Cc: stable(a)vger.kernel.org Signed-off-by: Raghavendra Rao Ananta <rananta(a)google.com> Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/vfio/device_cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c index 480cac3a0c274..8ceca24ac136c 100644 --- a/drivers/vfio/device_cdev.c +++ b/drivers/vfio/device_cdev.c @@ -99,7 +99,7 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df, return ret; if (user_size < minsz) return -EINVAL; - ret = copy_struct_from_user(&bind, minsz, arg, user_size); + ret = copy_struct_from_user(&bind, sizeof(bind), arg, user_size); if (ret) return ret; -- 2.51.1.930.gacf6e81ea2-goog

1 month

1
0
0 0

[PATCH net] Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()

by Ilia Gavrilov

In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: db08722fc7d4 ("Bluetooth: hci_core: Fix missing instances using HCI_MAX_AD_LENGTH") Cc: stable(a)vger.kernel.org Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru> --- include/net/bluetooth/mgmt.h | 2 +- net/bluetooth/mgmt.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h index 74edea06985b..4b07ce6dfd69 100644 --- a/include/net/bluetooth/mgmt.h +++ b/include/net/bluetooth/mgmt.h @@ -780,7 +780,7 @@ struct mgmt_adv_pattern { __u8 ad_type; __u8 offset; __u8 length; - __u8 value[31]; + __u8 value[HCI_MAX_AD_LENGTH]; } __packed; #define MGMT_OP_ADD_ADV_PATTERNS_MONITOR 0x0052 diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index a3d16eece0d2..500033b70a96 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -5391,9 +5391,9 @@ static u8 parse_adv_monitor_pattern(struct adv_monitor *m, u8 pattern_count, for (i = 0; i < pattern_count; i++) { offset = patterns[i].offset; length = patterns[i].length; - if (offset >= HCI_MAX_EXT_AD_LENGTH || - length > HCI_MAX_EXT_AD_LENGTH || - (offset + length) > HCI_MAX_EXT_AD_LENGTH) + if (offset >= HCI_MAX_AD_LENGTH || + length > HCI_MAX_AD_LENGTH || + (offset + length) > HCI_MAX_AD_LENGTH) return MGMT_STATUS_INVALID_PARAMS; p = kmalloc(sizeof(*p), GFP_KERNEL); -- 2.39.5

1 month

3
5
0 0

[PATCH v2 0/1] Bluetooth: btusb: add default nvm file

by Shuai Zhang

this patch adds support for default NVM file Changes v2: - Add log for failed default nvm file request. - Added Cc: stable(a)vger.kernel.org to comply with stable kernel rules. - Link to v1: https://lore.kernel.org/all/20251028120550.2225434-1-quic_shuaz@quicinc.com/ Shuai Zhang (1): Bluetooth: btusb: add default nvm file drivers/bluetooth/btusb.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) -- 2.34.1

1 month

2
2
0 0

[PATCH v3] usb: storage: Fix memory leak in USB bulk transport

by Desnes Nunes

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable(a)vger.kernel.org Signed-off-by: Desnes Nunes <desnesn(a)redhat.com> --- V2->V3: Changed memset to use sizeof(buf) and added a comment about the leak V1->V2: Used the same code style found on usb_stor_Bulk_transport() drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 1aa1bd26c81f..9a4bf86e7b6a 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1200,7 +1200,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature == cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg = NULL; + offset = 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) != + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } -- 2.51.0

1 month

2
1
0 0

[PATCH] gpiolib: Fix a null-ptr-deref in gpiolib_seq_stop()

by Ilia Gavrilov

Syzkaller reports a null-ptr-deref in gpiolib_seq_stop() [1] If the memory allocation for priv variable in gpiolib_seq_start() fails, then s->private remains uninitialized, which leads to a null pointer dereference to s->private in gpiolib_seq_stop(). [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10120 Comm: gpio_seq_stop Not tainted 6.12.53 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:gpiolib_seq_stop+0x4c/0xd0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 95 00 00 00 48 8b 9b e0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 5d 8b RSP: 0018:ffffc90019f2fad8 EFLAGS: 00010247 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000400 RDX: 0000000000000000 RSI: ffffffff84c57bfe RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000dc0 R09: 00000000ffffffff R10: ffffffff8e3865b3 R11: 0000000000000001 R12: 0000000000000000 R13: ffffffff8bd9da80 R14: 0000000000010000 R15: 0000000000000000 FS: 00007fb9a07cf6c0(0000) GS:ffff888131600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004c2018 CR3: 00000000264c6000 CR4: 00000000000006f0 Call Trace: <TASK> seq_read_iter+0x610/0x1290 seq_read+0x3a4/0x570 ? __pfx_seq_read+0x10/0x10 full_proxy_read+0x12a/0x1a0 ? __pfx_full_proxy_read+0x10/0x10 vfs_read+0x1e2/0xcf0 ? __fget_files+0x23a/0x3f0 ? __pfx_lock_release+0x10/0x10 ? fdget_pos+0x24c/0x360 ? __pfx_vfs_read+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? __fget_files+0x244/0x3f0 ksys_read+0x12f/0x260 ? __pfx_ksys_read+0x10/0x10 do_syscall_64+0xcd/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU") Reported-by: syzbot+b95d0c98f01e7a95da72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b95d0c98f01e7a95da72 Cc: stable(a)vger.kernel.org # 6.9+ Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru> --- drivers/gpio/gpiolib.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 9952e412da50..13cf9f4bdc6d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -5298,7 +5298,7 @@ static void *gpiolib_seq_start(struct seq_file *s, loff_t *pos) priv = kzalloc(sizeof(*priv), GFP_KERNEL); if (!priv) - return NULL; + return ERR_PTR(-ENOMEM); s->private = priv; if (*pos > 0) @@ -5331,8 +5331,11 @@ static void gpiolib_seq_stop(struct seq_file *s, void *v) { struct gpiolib_seq_priv *priv = s->private; - srcu_read_unlock(&gpio_devices_srcu, priv->idx); - kfree(priv); + if (!IS_ERR(v)) { + srcu_read_unlock(&gpio_devices_srcu, priv->idx); + kfree(priv); + } + s->private = NULL; } static int gpiolib_seq_show(struct seq_file *s, void *v) -- 2.39.5

1 month

1
0
0 0

[PATCH 0/3] SDM630/660: Add missing MDSS reset

by unknown＠example.com

Since kernel 6.17 display stack needs to reset the hardware properly to ensure that we don't run into issues with the hardware configured by the bootloader. MDSS reset is necessary to have working display when the bootloader has already initialized it for the boot splash screen. Signed-off-by: Alexey Minnekhanov <<alexeymin(a)postmarketos.org>> --- Alexey Minnekhanov (3): dt-bindings: clock: mmcc-sdm660: Add missing MDSS reset clk: qcom: mmcc-sdm660: Add missing MDSS reset arm64: dts: qcom: sdm630: Add missing MDSS reset arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 + drivers/clk/qcom/mmcc-sdm660.c | 1 + include/dt-bindings/clock/qcom,mmcc-sdm660.h | 1 + 3 files changed, 3 insertions(+) --- base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6 change-id: 20251031-sdm660-mdss-reset-015a46a238b5 Best regards, -- Alexey Minnekhanov <<alexeymin(a)postmarketos.org>>

1 month

5
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror