[РЕШЕНО] Ошибка № ...

пятница

[Bug 2158075] Re: PCI/PM Regression: NVIDIA MX250 / PCI Bridge unable to change power state from D3cold to D0 on kernels >= 6.8 (HP Envy)

I have used AI intensively for the last 3 days in order to back track my steps, review them over and over again; and finally spot the solution. Not sure if this can help someone but for sure helped me, hope this documentation can be used for somebody else. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158075 Title: PCI/PM Regression: NVIDIA MX250 / PCI Bridge unable to change power state from D3cold to D0 on kernels >= 6.8 (HP Envy) Status in linux package in Ubuntu: New Bug description: Expected Behavior: The discrete NVIDIA GeForce MX250 GPU should successfully initialize and wake from low-power runtime states during system boot and user session initialization. Actual Behavior: During the early system boot phase, the kernel fails to wake the discrete GPU from its power-saving D3cold state to D0. Because the hardware remains unresponsive, it reports a broken 64-bit BAR allocation window mapped above 4GB, and the NVIDIA proprietary driver fails to initialize entirely. This bug is persistent across modern HWE kernel stacks (tested on 6.11.0-29-generic and 6.17.0-35-generic). Steps taken that did NOT resolve the issue: - Verified DKMS modules compile completely cleanly for NVIDIA 535.309.01 against both kernels. - Attempted ACPI OSI overrides via GRUB including 'acpi_osi="Windows 2015"' and 'acpi_osi="Windows 2009"' to force legacy vendor firmware paths; the D3cold -> D0 timeout persisted. - Tested kernel and driver power-state management parameters including 'pcie_port_pm=off', 'pci=realloc', and 'nvidia.NVreg_DynamicPowerManagement=1'. None of these flags successfully intercepted or prevented the hardware from falling into an un-wakeable D3cold state. - System is only stable when completely bypassing the device initialization tree using 'prime-select intel'. Hardware Platform: - Laptop: HP Envy x360 15-dr0003np - GPU: NVIDIA GeForce MX250 / Integrated Intel Graphics - OS: Linux Mint 22.3 (Noble Base) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158075/+subscriptions

[Bug 2158440] [NEW] kernel-7.0.0-22 thermal regression

Public bug reported: My Dell Vostro 5515 hits 100°C even when only running Chrome. Switching from kernel 7.0.0-22 to 7.0.0-14 fixed the overheating. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-14-generic 7.0.0-14.14 ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0 Uname: Linux 7.0.0-14-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jun 26 20:39:35 2026 InstallationDate: Installed on 2026-01-08 (169 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) MachineType: Dell Inc. Vostro 5515 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-14-generic root=UUID=95a0af7d-0884-47b9-ae31-23fe2749a34c ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-04-24 (63 days ago) dmi.bios.date: 02/26/2025 dmi.bios.release: 5.3 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.28.0 dmi.board.name: 078X6R dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.28.0 dmi.modalias: dmi:bvnDellInc.:bvr1.28.0:bd02/26/2025:br5.3:svnDellInc.:pnVostro5515:pvr1.28.0:rvnDellInc.:rn078X6R:rvrA00:cvnDellInc.:ct10:cvr1.28.0:sku0A7A:pfaVostro: dmi.product.family: Vostro dmi.product.name: Vostro 5515 dmi.product.sku: 0A7A dmi.product.version: 1.28.0 dmi.sys.vendor: Dell Inc. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug kernel-thermal-regression regression-update resolute wayland-session ** Attachment added: "kernel-7.0.0-22-thermal-regression-summary.txt" https://bugs.launchpad.net/bugs/2158440/+attachment/5979099/+files/kernel-7.0.0-22-thermal-regression-summary.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158440 Title: kernel-7.0.0-22 thermal regression Status in linux package in Ubuntu: New Bug description: My Dell Vostro 5515 hits 100°C even when only running Chrome. Switching from kernel 7.0.0-22 to 7.0.0-14 fixed the overheating. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-14-generic 7.0.0-14.14 ProcVersionSignature: Ubuntu 7.0.0-14.14-generic 7.0.0 Uname: Linux 7.0.0-14-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jun 26 20:39:35 2026 InstallationDate: Installed on 2026-01-08 (169 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) MachineType: Dell Inc. Vostro 5515 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-14-generic root=UUID=95a0af7d-0884-47b9-ae31-23fe2749a34c ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-04-24 (63 days ago) dmi.bios.date: 02/26/2025 dmi.bios.release: 5.3 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.28.0 dmi.board.name: 078X6R dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 1.28.0 dmi.modalias: dmi:bvnDellInc.:bvr1.28.0:bd02/26/2025:br5.3:svnDellInc.:pnVostro5515:pvr1.28.0:rvnDellInc.:rn078X6R:rvrA00:cvnDellInc.:ct10:cvr1.28.0:sku0A7A:pfaVostro: dmi.product.family: Vostro dmi.product.name: Vostro 5515 dmi.product.sku: 0A7A dmi.product.version: 1.28.0 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158440/+subscriptions

[Bug 2158377] [NEW] ext4: writeback causes kernel oops when low on space

Public bug reported: SRU Justification: [Impact] The noble upstream stable patchset 2026-05-28 (LP: #2154496) introduced refactoring patches targeting ext4 code, originating from upstream stable branch linux-6.6.y. During regression testing of the generic noble kernel, the ltp tests mmap14 and mmap16 were observed to fail, causing a kernel oops. Through bisecting, upstream commit f7d1331f16a8 ("ext4: get rid of ppath in ext4_ext_insert_extent()") was found to be cause. This commit was the first in the refactoring series of commits targeting ext4 in v6.6.130. The following stacktrace was recorded on an arm64 openstack instance: [ 1194.380996] Unable to handle kernel paging request at virtual address ffffffffffffffec [ 1194.381993] Mem abort info: [ 1194.382451] ESR = 0x0000000096000004 [ 1194.382950] EC = 0x25: DABT (current EL), IL = 32 bits [ 1194.383615] SET = 0, FnV = 0 [ 1194.384067] EA = 0, S1PTW = 0 [ 1194.384534] FSC = 0x04: level 0 translation fault [ 1194.385143] Data abort info: [ 1194.385626] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1194.386310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1194.387026] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1194.391322] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000cc641000 [ 1194.393554] [ffffffffffffffec] pgd=0000000000000000, p4d=0000000000000000 [ 1194.394958] Internal error: Oops: 0000000096000004 [#1] SMP [ 1194.395660] Modules linked in: brd overlay exfat bcachefs lz4hc_compress lz4_compress xfs sctp ip6_udp_tunnel udp_tunnel nfsd auth_rpcgss nfs_acl lockd grace sunrpc tls qrtr cfg80211 binfmt_misc nls_iso8859_1 input_leds sch_fq_codel dm_multipath efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 crct10dif_ce polyval_ce polyval_generic ghash_ce sm4 sha2_ce sha256_arm64 virtio_gpu arm_smccc_trng sha1_ce virtio_rng virtio_dma_buf xhci_pci xhci_pci_renesas aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [last unloaded: init_module(OE)] [ 1194.405523] CPU: 1 PID: 95 Comm: kworker/u6:1 Tainted: G OE 6.8.0-132-generic #133-Ubuntu [ 1194.407319] Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8~22.04.0~ppa3 05/14/2025 [ 1194.408502] Workqueue: writeback wb_workfn (flush-7:0) [ 1194.409343] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1194.410263] pc : ext4_ext_map_blocks+0x2a0/0xa18 [ 1194.410979] lr : ext4_ext_map_blocks+0x8e8/0xa18 [ 1194.411685] sp : ffff8000803db600 [ 1194.412280] x29: ffff8000803db6a0 x28: 0000000000000ee8 x27: ffff0000c3641280 [ 1194.413248] x26: ffff0000cb20b000 x25: ffffffffffffffe4 x24: 000000000000042f [ 1194.414196] x23: ffff0000c286bc40 x22: ffff0000c36413a8 x21: ffff8000803db948 [ 1194.415141] x20: 0000000000000008 x19: 0000000000000000 x18: ffff800080381078 [ 1194.416131] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 1194.417083] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1194.418051] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa6fb00b8227c [ 1194.419026] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 1194.419949] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 1194.420897] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 1194.421851] Call trace: [ 1194.422404] ext4_ext_map_blocks+0x2a0/0xa18 [ 1194.423106] ext4_map_blocks+0x1c4/0x650 [ 1194.423755] mpage_map_one_extent+0x7c/0x1e0 [ 1194.424456] mpage_map_and_submit_extent+0x94/0x428 [ 1194.425196] ext4_do_writepages+0x6c0/0x7d8 [ 1194.425883] ext4_writepages+0x88/0x128 [ 1194.426570] do_writepages+0x98/0x210 [ 1194.427222] __writeback_single_inode+0x50/0x390 [ 1194.427947] writeback_sb_inodes+0x230/0x4d8 [ 1194.428666] wb_writeback+0x128/0x410 [ 1194.429324] wb_do_writeback+0xb4/0x398 [ 1194.429998] wb_workfn+0x80/0x258 [ 1194.430604] process_one_work+0x17c/0x448 [ 1194.431289] worker_thread+0x1bc/0x3a0 [ 1194.431923] kthread+0xf8/0x110 [ 1194.432533] ret_from_fork+0x10/0x20 [ 1194.433178] Code: b9003fe2 f94023f9 b9000ea0 b4001a39 (79401337) [ 1194.434077] ---[ end trace 0000000000000000 ]--- The crash is triggered during normal writeback when the filesystem is low on space. Any workload that writes to ext4 with unwritten (preallocated/fallocated) extents under space pressure can hit this. It is fatal to the affected writeback worker thread. [Explanation] The kernel crash (oops) occurs during ext4 writeback in `ext4_ext_map_blocks()` when the filesystem encounters an ENOSPC (no space left on device) condition while handling unwritten extents. The crash manifests as a page fault at address `0xffffffffffffffec` (which is `ERR_PTR(-ENOSPC) + 8`) on arm64, triggered from a writeback worker thread. The ext4 extent code underwent a significant refactoring series that changed how extent path objects are passed between functions. Previously, functions used double-pointer (`struct ext4_ext_path **ppath`) semantics — on error, the callee would set `*ppath = NULL`, ensuring the caller never held a dangling or invalid pointer. The refactoring changed these functions to return the path directly (or `ERR_PTR` on error). After this refactoring, functions like `ext4_ext_handle_unwritten_extents()` and `ext4_ext_insert_extent()` return `ERR_PTR(-ENOSPC)` on failure. The caller (`ext4_ext_map_blocks`) stores this error pointer in its local `path` variable and jumps to its cleanup label, where `ext4_free_ext_path(path)` is called. However, `ext4_free_ext_path()` was never updated to handle `ERR_PTR` values — it only had a NULL check. As a result, it attempts to dereference the error pointer (specifically reading `path->p_depth`), causing the kernel page fault. [Fix] Cherry-pick this missing prerequisite patch: 6b854d552711 ("ext4: get rid of ppath in get_ext_path()"). This patch adds `IS_ERR_OR_NULL()` guards to both `ext4_ext_drop_refs()` and `ext4_free_ext_path()`. This teaches these cleanup functions to gracefully handle error pointers by returning immediately, which is necessary now that the refactored call chain can leave `path` set to an `ERR_PTR` value when reaching cleanup code. [Test Plan] Run the ltp tests mmap14 and mmp16 that reliably trigger the crash. The tests should complete successfully without triggering a kernel crash. [Where problems could occur] If problems with this fix were to occur, they would manifest as silent memory leaks in ext4 extent handling - specifically, any code path that previously relied on `ext4_free_ext_path()` to actually free a valid path object but now mistakenly passes an `IS_ERR()` value would silently skip the free and leak the already-freed (or never-allocated) path, making such bugs harder to detect rather than causing a visible crash. Conversely, if any code path were to accidentally store an `ERR_PTR` in a path variable that is later reused (rather than cleaned up), the `IS_ERR_OR_NULL` guard would mask what should be a loud failure, potentially leading to subtle use-after-free or NULL-dereference bugs downstream when that variable is subsequently passed to `ext4_find_extent()` for recycling. ** Affects: linux (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Noble) Importance: High Assignee: Manuel Diewald (diewald) Status: In Progress ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Assignee: (unassigned) => Manuel Diewald (diewald) ** Changed in: linux (Ubuntu Noble) Status: New => In Progress ** Changed in: linux (Ubuntu Noble) Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158377 Title: ext4: writeback causes kernel oops when low on space Status in linux package in Ubuntu: Invalid Status in linux source package in Noble: In Progress Bug description: SRU Justification: [Impact] The noble upstream stable patchset 2026-05-28 (LP: #2154496) introduced refactoring patches targeting ext4 code, originating from upstream stable branch linux-6.6.y. During regression testing of the generic noble kernel, the ltp tests mmap14 and mmap16 were observed to fail, causing a kernel oops. Through bisecting, upstream commit f7d1331f16a8 ("ext4: get rid of ppath in ext4_ext_insert_extent()") was found to be cause. This commit was the first in the refactoring series of commits targeting ext4 in v6.6.130. The following stacktrace was recorded on an arm64 openstack instance: [ 1194.380996] Unable to handle kernel paging request at virtual address ffffffffffffffec [ 1194.381993] Mem abort info: [ 1194.382451] ESR = 0x0000000096000004 [ 1194.382950] EC = 0x25: DABT (current EL), IL = 32 bits [ 1194.383615] SET = 0, FnV = 0 [ 1194.384067] EA = 0, S1PTW = 0 [ 1194.384534] FSC = 0x04: level 0 translation fault [ 1194.385143] Data abort info: [ 1194.385626] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1194.386310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1194.387026] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1194.391322] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000cc641000 [ 1194.393554] [ffffffffffffffec] pgd=0000000000000000, p4d=0000000000000000 [ 1194.394958] Internal error: Oops: 0000000096000004 [#1] SMP [ 1194.395660] Modules linked in: brd overlay exfat bcachefs lz4hc_compress lz4_compress xfs sctp ip6_udp_tunnel udp_tunnel nfsd auth_rpcgss nfs_acl lockd grace sunrpc tls qrtr cfg80211 binfmt_misc nls_iso8859_1 input_leds sch_fq_codel dm_multipath efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 crct10dif_ce polyval_ce polyval_generic ghash_ce sm4 sha2_ce sha256_arm64 virtio_gpu arm_smccc_trng sha1_ce virtio_rng virtio_dma_buf xhci_pci xhci_pci_renesas aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [last unloaded: init_module(OE)] [ 1194.405523] CPU: 1 PID: 95 Comm: kworker/u6:1 Tainted: G OE 6.8.0-132-generic #133-Ubuntu [ 1194.407319] Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8~22.04.0~ppa3 05/14/2025 [ 1194.408502] Workqueue: writeback wb_workfn (flush-7:0) [ 1194.409343] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1194.410263] pc : ext4_ext_map_blocks+0x2a0/0xa18 [ 1194.410979] lr : ext4_ext_map_blocks+0x8e8/0xa18 [ 1194.411685] sp : ffff8000803db600 [ 1194.412280] x29: ffff8000803db6a0 x28: 0000000000000ee8 x27: ffff0000c3641280 [ 1194.413248] x26: ffff0000cb20b000 x25: ffffffffffffffe4 x24: 000000000000042f [ 1194.414196] x23: ffff0000c286bc40 x22: ffff0000c36413a8 x21: ffff8000803db948 [ 1194.415141] x20: 0000000000000008 x19: 0000000000000000 x18: ffff800080381078 [ 1194.416131] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 1194.417083] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1194.418051] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa6fb00b8227c [ 1194.419026] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 1194.419949] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 1194.420897] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 1194.421851] Call trace: [ 1194.422404] ext4_ext_map_blocks+0x2a0/0xa18 [ 1194.423106] ext4_map_blocks+0x1c4/0x650 [ 1194.423755] mpage_map_one_extent+0x7c/0x1e0 [ 1194.424456] mpage_map_and_submit_extent+0x94/0x428 [ 1194.425196] ext4_do_writepages+0x6c0/0x7d8 [ 1194.425883] ext4_writepages+0x88/0x128 [ 1194.426570] do_writepages+0x98/0x210 [ 1194.427222] __writeback_single_inode+0x50/0x390 [ 1194.427947] writeback_sb_inodes+0x230/0x4d8 [ 1194.428666] wb_writeback+0x128/0x410 [ 1194.429324] wb_do_writeback+0xb4/0x398 [ 1194.429998] wb_workfn+0x80/0x258 [ 1194.430604] process_one_work+0x17c/0x448 [ 1194.431289] worker_thread+0x1bc/0x3a0 [ 1194.431923] kthread+0xf8/0x110 [ 1194.432533] ret_from_fork+0x10/0x20 [ 1194.433178] Code: b9003fe2 f94023f9 b9000ea0 b4001a39 (79401337) [ 1194.434077] ---[ end trace 0000000000000000 ]--- The crash is triggered during normal writeback when the filesystem is low on space. Any workload that writes to ext4 with unwritten (preallocated/fallocated) extents under space pressure can hit this. It is fatal to the affected writeback worker thread. [Explanation] The kernel crash (oops) occurs during ext4 writeback in `ext4_ext_map_blocks()` when the filesystem encounters an ENOSPC (no space left on device) condition while handling unwritten extents. The crash manifests as a page fault at address `0xffffffffffffffec` (which is `ERR_PTR(-ENOSPC) + 8`) on arm64, triggered from a writeback worker thread. The ext4 extent code underwent a significant refactoring series that changed how extent path objects are passed between functions. Previously, functions used double-pointer (`struct ext4_ext_path **ppath`) semantics — on error, the callee would set `*ppath = NULL`, ensuring the caller never held a dangling or invalid pointer. The refactoring changed these functions to return the path directly (or `ERR_PTR` on error). After this refactoring, functions like `ext4_ext_handle_unwritten_extents()` and `ext4_ext_insert_extent()` return `ERR_PTR(-ENOSPC)` on failure. The caller (`ext4_ext_map_blocks`) stores this error pointer in its local `path` variable and jumps to its cleanup label, where `ext4_free_ext_path(path)` is called. However, `ext4_free_ext_path()` was never updated to handle `ERR_PTR` values — it only had a NULL check. As a result, it attempts to dereference the error pointer (specifically reading `path->p_depth`), causing the kernel page fault. [Fix] Cherry-pick this missing prerequisite patch: 6b854d552711 ("ext4: get rid of ppath in get_ext_path()"). This patch adds `IS_ERR_OR_NULL()` guards to both `ext4_ext_drop_refs()` and `ext4_free_ext_path()`. This teaches these cleanup functions to gracefully handle error pointers by returning immediately, which is necessary now that the refactored call chain can leave `path` set to an `ERR_PTR` value when reaching cleanup code. [Test Plan] Run the ltp tests mmap14 and mmp16 that reliably trigger the crash. The tests should complete successfully without triggering a kernel crash. [Where problems could occur] If problems with this fix were to occur, they would manifest as silent memory leaks in ext4 extent handling - specifically, any code path that previously relied on `ext4_free_ext_path()` to actually free a valid path object but now mistakenly passes an `IS_ERR()` value would silently skip the free and leak the already-freed (or never-allocated) path, making such bugs harder to detect rather than causing a visible crash. Conversely, if any code path were to accidentally store an `ERR_PTR` in a path variable that is later reused (rather than cleaned up), the `IS_ERR_OR_NULL` guard would mask what should be a loud failure, potentially leading to subtle use-after-free or NULL-dereference bugs downstream when that variable is subsequently passed to `ext4_find_extent()` for recycling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158377/+subscriptions

[Bug 2156858] Re: [SRU] Fix GPU throttling limits on Strix Halo

For OEM-6.17: https://kernel.ubuntu.com/forgejo/kernel/noble-linux- oem/pulls/432 For 7.0 generic: https://lists.ubuntu.com/archives/kernel- team/2026-June/169539.html -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156858 Title: [SRU] Fix GPU throttling limits on Strix Halo Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: New Bug description: BugLink: https://bugs.launchpad.net/bugs/2156858 [ Impact ] We found that setting power_dpm_force_performance_level to high and running heavy workload on Strix Halo platforms somehow makes it reboot. This is due to the throttling limits in amdgpu don't aligned with the power management firmware properly. [ Fix ] Cherry-pick the following commit: - 03b70e0d8aa26bab (drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in set_soft_freq_limited_range) which has been accepted since mainline v7.1 [ Test ] 1. Boot the kernel 2. Run the same compute workload on a Strix Halo system, and it shouldn't reboot. [ Where problems could occur ] If the driver throttles to aggressively this may impact performance, but this is safer than letting Strix Halo burn. [ Additional Information ] https://github.com/torvalds/linux/commit/03b70e0d8aa26bab89a0f1394c1c80a871925e42 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2156858/+subscriptions

[Bug 2151747] Re: AppArmor Vulnerabilities

[Bug 2154172] Re: GRO managed-frag use-after-free leading to local privilege escalation

This bug is awaiting verification that the linux-xuantie/7.0.0-1004.4 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-resolute-linux-xuantie' to 'verification-done- resolute-linux-xuantie'. If the problem still exists, change the tag 'verification-needed-resolute-linux-xuantie' to 'verification-failed- resolute-linux-xuantie'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-resolute-linux-xuantie-v2 verification-needed-resolute-linux-xuantie -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154172 Title: GRO managed-frag use-after-free leading to local privilege escalation Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: Fix Released Status in linux source package in Questing: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [ Impact ] skb_gro_receive() in net/core/gro.c transfers frag descriptors from a source skb into a GRO accumulator without checking the SKBFL_MANAGED_FRAG_REFS flag. A managed-frag skb does not hold a per-frag page reference; the caller owns page lifetime. When such frags are appended to a non-managed accumulator, skb_release_data() later calls put_page() on frags it never get_page()'d, producing a page refcount underflow. The resulting use-after-free is reachable by an unprivileged local user via io_uring SEND_ZC with fixed buffers over a GRO-enabled interface, and yields local privilege escalation. The bug was introduced upstream by commit 753f1ca4e1e5 ("net: introduce managed frags infrastructure"), which first landed in v5.20/v6.0. [ Fix ] commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ("net: gro: don't merge zcopy skbs") Refuse to merge in skb_gro_receive() when either side has SKBFL_MANAGED_FRAG_REFS or any zerocopy flag set. Landed in net.git for v7.1-rc5. [ Test Plan ] A user-space reproducer is run on a VM with the candidate kernel installed. sha256(/etc/passwd) is captured pre and post. Patched kernel: reproducer self-reports failure, sha256 unchanged. Unpatched kernel: reproducer succeeds, sha256 changes during the run. [ Where Problems Could Occur ] The fix only refuses a merge in a case that was always unsafe. The visible effect is that GRO occasionally produces one more segment-sized skb than otherwise on flows that mix managed and non-managed frags. Tiny throughput change in an uncommon path, no crash or correctness risk. No userspace API change, no kernel ABI change, no module change. [ Other Info ] No CVE ID assigned at the time of filing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154172/+subscriptions

[Bug 2148809] Re: apparmor: LLVM/clang build failure due to uninitialized variable in notify.c

This bug is awaiting verification that the linux-xuantie/7.0.0-1004.4 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-resolute-linux-xuantie' to 'verification-done- resolute-linux-xuantie'. If the problem still exists, change the tag 'verification-needed-resolute-linux-xuantie' to 'verification-failed- resolute-linux-xuantie'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-resolute-linux-xuantie-v2 verification-needed-resolute-linux-xuantie -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2148809 Title: apparmor: LLVM/clang build failure due to uninitialized variable in notify.c Status in linux package in Ubuntu: Fix Released Bug description: [Impact] Building the Ubuntu Resolute (26.04) kernel with LLVM/clang (LLVM=1) fails due to an uninitialized variable in security/apparmor/notify.c. The function knotif_update_from_uresp_perm() declares `u16 flags` without initialization. The compiler detects that when `uresp` is NULL, the else branch (line 839) does not assign a value to `flags`, but `flags` is subsequently read at line 846 in the expression `flags & URESPONSE_NO_CACHE`. Currently the only call site (line 1041) always passes a non-NULL pointer (`&uresp->perm`), so the uninitialized read is not reachable at runtime. However, the function signature accepts a pointer and explicitly checks for NULL, making this a latent defect. Clang's -Wsometimes-uninitialized correctly flags this, and combined with -Werror, the build fails. [Test case] 1. Download linux_7.0.0-10.10 source 2. Configure with x86_64_defconfig + CONFIG_SECURITY_APPARMOR=y 3. Build with: make LLVM=1 -j$(nproc) Build fails with: security/apparmor/notify.c:817:6: error: variable 'flags' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] With the fix applied, security/apparmor/notify.c compiles without error. [Fix] Initialize the variable to zero: `u16 flags = 0;` The NULL path is currently unreachable, so the choice of initial value does not affect runtime behavior. Zero-initialization silences the compiler diagnostic and is the standard practice for this class of warning. --- a/security/apparmor/notify.c +++ b/security/apparmor/notify.c @@ -812,7 +812,7 @@ static void knotif_update_from_uresp_perm(struct aa_knotif *knotif, struct apparmor_notif_resp_perm *uresp) { - u16 flags; + u16 flags = 0; if (uresp) { [Regression potential] Minimal. Zero-initialization of a local variable. The NULL path is currently unreachable (the sole call site passes &uresp->perm), so this change has no effect on runtime behavior. It only resolves the compiler diagnostic to enable LLVM/clang kernel builds. [Other info] - Source: linux_7.0.0-10.10 (Ubuntu Resolute 26.04) - Compiler: clang 21.1.8 (LLVM=1) - Architecture: x86_64 - security/apparmor/notify.c is Ubuntu out-of-tree code (not in mainline) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2148809/+subscriptions

четверг

[Bug 2154172] Re: GRO managed-frag use-after-free leading to local privilege escalation

This bug is awaiting verification that the linux-nvidia/6.8.0-1057.60 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-nvidia' to 'verification-done- noble-linux-nvidia'. If the problem still exists, change the tag 'verification-needed-noble-linux-nvidia' to 'verification-failed-noble- linux-nvidia'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-nvidia-v2 verification-needed-noble-linux-nvidia -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154172 Title: GRO managed-frag use-after-free leading to local privilege escalation Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: Fix Released Status in linux source package in Questing: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [ Impact ] skb_gro_receive() in net/core/gro.c transfers frag descriptors from a source skb into a GRO accumulator without checking the SKBFL_MANAGED_FRAG_REFS flag. A managed-frag skb does not hold a per-frag page reference; the caller owns page lifetime. When such frags are appended to a non-managed accumulator, skb_release_data() later calls put_page() on frags it never get_page()'d, producing a page refcount underflow. The resulting use-after-free is reachable by an unprivileged local user via io_uring SEND_ZC with fixed buffers over a GRO-enabled interface, and yields local privilege escalation. The bug was introduced upstream by commit 753f1ca4e1e5 ("net: introduce managed frags infrastructure"), which first landed in v5.20/v6.0. [ Fix ] commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ("net: gro: don't merge zcopy skbs") Refuse to merge in skb_gro_receive() when either side has SKBFL_MANAGED_FRAG_REFS or any zerocopy flag set. Landed in net.git for v7.1-rc5. [ Test Plan ] A user-space reproducer is run on a VM with the candidate kernel installed. sha256(/etc/passwd) is captured pre and post. Patched kernel: reproducer self-reports failure, sha256 unchanged. Unpatched kernel: reproducer succeeds, sha256 changes during the run. [ Where Problems Could Occur ] The fix only refuses a merge in a case that was always unsafe. The visible effect is that GRO occasionally produces one more segment-sized skb than otherwise on flows that mix managed and non-managed frags. Tiny throughput change in an uncommon path, no crash or correctness risk. No userspace API change, no kernel ABI change, no module change. [ Other Info ] No CVE ID assigned at the time of filing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154172/+subscriptions

[Bug 2158249] Re: SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot

** Description changed: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on,memory-encryption=sev0 \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ -machine memory-backend=ram1 \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ -kernel vmlinuz \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin + Using the same kernel/stage0 binaries without SEV-SNP works fine: + + qemu-system-x86_64 \ + -enable-kvm \ + -nographic \ + -no-reboot \ + -machine microvm,acpi=on \ + -cpu EPYC-v4 \ + -smp 1 \ + -m 2G \ + -kernel kernel/boot/vmlinuz-7.1.0-5-generic \ + -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ + -bios stage0_bin.bin + + [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158249 Title: SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot Status in linux package in Ubuntu: New Bug description: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on,memory-encryption=sev0 \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ -machine memory-backend=ram1 \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ -kernel vmlinuz \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin Using the same kernel/stage0 binaries without SEV-SNP works fine: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -kernel kernel/boot/vmlinuz-7.1.0-5-generic \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158249/+subscriptions

[Bug 2158249] Re: SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot

For good measure, I also tested 7.1.0-5.5-generic from ppa:canonical- kernel-team/unstable and I was able to reproduce. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158249 Title: SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot Status in linux package in Ubuntu: New Bug description: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on,memory-encryption=sev0 \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ -machine memory-backend=ram1 \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ -kernel vmlinuz \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158249/+subscriptions

[Bug 2158249] [NEW] SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot

Public bug reported: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on,memory-encryption=sev0 \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ -machine memory-backend=ram1 \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ -kernel vmlinuz \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Build script and pre-built binary for Oak's stage0" https://bugs.launchpad.net/bugs/2158249/+attachment/5978941/+files/stage0.tar.gz ** Description changed: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP - guest, the kernel panic with: + guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> - Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ - -enable-kvm \ - -nographic \ - -no-reboot \ - -machine microvm,acpi=on,memory-encryption=sev0 \ - -cpu EPYC-v4 \ - -smp 1 \ - -m 2G \ - -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ - -machine memory-backend=ram1 \ - -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ - -kernel vmlinuz \ - -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ - -bios stage0_bin.bin + -enable-kvm \ + -nographic \ + -no-reboot \ + -machine microvm,acpi=on,memory-encryption=sev0 \ + -cpu EPYC-v4 \ + -smp 1 \ + -m 2G \ + -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ + -machine memory-backend=ram1 \ + -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ + -kernel vmlinuz \ + -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ + -bios stage0_bin.bin [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158249 Title: SEV-SNP guest panics in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI boot Status in linux package in Ubuntu: New Bug description: When trying to boot 7.0.0-22-generic with Oak's stage0[0] in a SEV-SNP guest, the kernel panics with: PANIC: Unsupported exit-code 0x404 in early #VC exception (IP: 0xffffffff9d7b5e05) [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-22-generic #22-Ubuntu PREEMPT(undef) [ 0.000000] RIP: 0010:reserve_ibft_region+0x75/0x130 [ 0.000000] Code: be 00 10 00 00 4c 89 e7 e8 88 32 fc ff be 00 10 00 00 48 89 df e8 3b 31 fc ff 48 89 d9 49 89 c4 48 89 d8 48 29 c8 49 8d 3c 04 <81> 3f 69 42 46 54 75 13 49 8b 74 04 04 89 f2 48 01 da 48 81 fa ff [ 0.000000] RSP: 0000:ffffffff9d203e80 EFLAGS: 00010046 ORIG_RAX: 0000000000000404 [ 0.000000] RAX: 0000000000000000 RBX: 00000000000c0000 RCX: 00000000000c0000 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffff200000 [ 0.000000] RBP: ffffffff9d203e90 R08: 0000000000000000 R09: 0000000000000000 [ 0.000000] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffff200000 [ 0.000000] R13: 0000000000000000 R14: 0000000000000007 R15: 000000000001b000 [ 0.000000] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffffffff200000 CR3: 00080000469fc000 CR4: 00000000000000b0 [ 0.000000] Call Trace: [ 0.000000] <TASK> [ 0.000000] setup_arch+0x448/0x880 [ 0.000000] start_kernel+0x66/0x4c0 [ 0.000000] x86_64_start_reservations+0x24/0x30 [ 0.000000] x86_64_start_kernel+0x134/0x140 [ 0.000000] common_startup_64+0x13e/0x141 [ 0.000000] </TASK> Steps to reproduce 1. build stage0[1] or use another non-EFI firmware 2. launch a VM with SEV-SNP: qemu-system-x86_64 \ -enable-kvm \ -nographic \ -no-reboot \ -machine microvm,acpi=on,memory-encryption=sev0 \ -cpu EPYC-v4 \ -smp 1 \ -m 2G \ -object memory-backend-memfd,id=ram1,size=2G,share=true,prealloc=false \ -machine memory-backend=ram1 \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x30000 \ -kernel vmlinuz \ -append "console=ttyS0 earlyprintk=serial,ttyS0 loglevel=8 ignore_loglevel panic=-1" \ -bios stage0_bin.bin [0] https://github.com/project-oak/oak/tree/main/stage0 [1] See attached files for build script and pre-built binary To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158249/+subscriptions

[Bug 2155609] Re: net/tls: Three upstream fixes without CVE missing from Ubuntu 6.8.0-124-generic

** Description changed: - == Summary == - During source code analysis of Ubuntu 6.8.0-124-generic, - 3 upstream security fixes in net/tls/tls_sw.c were found - missing. None of these fixes have been assigned a CVE. + [ Impact ] - == Environment == - Kernel: 6.8.0-124-generic - Package: linux-source-6.8.0 (apt) - Verification method: Source diff vs upstream commits + Three upstream net/tls bug fixes are missing from Noble (6.8.0, present + through 6.8.0-132.133). All three touch net/tls/tls_sw.c, affect only + kTLS sockets, and were not assigned a CVE upstream. They address data + integrity and memory safety issues in the TLS software path: - == Issue 1: Silent data drop under pipe back-pressure == - Upstream fix: 7e7be31bfdb0 (2026-05-02) - Author: Jakub Kicinski - CVE: NOT ASSIGNED + 1) Silent data drop under pipe back-pressure. + tls_sw_splice_read() advances rxm->offset / rxm->full_len by the + requested length instead of the number of bytes actually spliced + into the pipe. When the destination pipe cannot accept everything, + splice_to_pipe() returns fewer bytes than requested and the + difference is silently skipped, corrupting the TLS RX stream. - Vulnerable code (tls_sw.c line 2288-2290): - if (chunk < rxm->full_len) { - rxm->offset += len; - rxm->full_len -= len; + 2) Off-by-one in the sg_chain() entry count for a wrapped sk_msg ring. + When the sk_msg scatterlist ring wraps (sg.end < sg.start), the + chain pointer is placed one entry short of the true last entry, so + the crypto engine is handed a malformed scatterlist. - Required fix: - if (copied < rxm->full_len) { - rxm->offset += copied; - rxm->full_len -= copied; + 3) chain-after-chain in the plaintext SG path. + When the ring is empty (end == 0) the existing code emits a chain + link that points directly at another chain link. The scatterlist + API (sg_next) does not resolve consecutive chain links, so this is + illegal input to crypto. - Impact: When pipe is full during tls_sw_splice_read(), - skb_splice_bits() returns copied < chunk. - Ubuntu code advances rxm->offset by len instead - of copied, silently skipping unread bytes. - Causes data integrity violation in TLS RX splice path. + [ Fix ] - == Issue 2: Off-by-one in sg_chain entry count == - Upstream fix: 285943c6e7ca (2026-05-14) - Author: Jakub Kicinski - CVE: NOT ASSIGNED - Reported by: 钱一铭 (yimingqian591@gmail.com) + Clean cherry-picks of the following upstream commits, in order: - Vulnerable code (tls_sw.c line 803-804): - sg_chain(&msg_pl->sg.data[msg_pl->sg.start], - MAX_SKB_FRAGS - msg_pl->sg.start + 1, - msg_pl->sg.data); + 7e7be31bfdb0 ("net: tls: fix silent data drop under pipe back-pressure") + 285943c6e7ca ("net: tls: fix off-by-one in sg_chain entry count for + wrapped sk_msg ring") + ff26a0e8377d ("net: tls: prevent chain-after-chain in plain text SG") - Required fix: - sg_chain(msg_pl->sg.data, - ARRAY_SIZE(msg_pl->sg.data), - msg_pl->sg.data); + (1) fixes commit e062fe99cccd; (2) and (3) fix commit 9aaaa56845a0. + Both Fixes: targets are present in Noble. - Impact: When sk_msg scatterlist ring wraps - (sg.end < sg.start), wrong sg_chain index - places chain pointer at data[MAX_SKB_FRAGS] - instead of true last entry. - Crypto engine receives invalid scatterlist, - potential slab-out-of-bounds read/write. + [ Test Plan ] - == Issue 3: chain-after-chain prevention in TLS 1.3 == - Upstream fix: ff26a0e8377d (2026-05-14) - Author: Jakub Kicinski - CVE: NOT ASSIGNED + Build: CBD build cengiz-noble-a55bcaa0d741-8479 + amd64: BUILD-OK + arm64: BUILD-OK + armhf: BUILD-OK + ppc64el: BUILD-OK + s390x: BUILD-OK - Vulnerable code (tls_sw.c line 796): - sg_chain(msg_pl->sg.data, msg_pl->sg.end + 1, - &rec->sg_content_type); + Boot: PASS (Kybele uvt-kvm boot test using the amd64 CBD artifacts) + Kernel: 6.8.0-132-generic + uname -v: #133 SMP PREEMPT_DYNAMIC Wed Jun 24 11:46:08 UTC 2026 - Required fix: - sg_chain(msg_pl->sg.data, i + 2, - &rec->sg_content_type); + [ Where Problems Could Occur ] - Impact: SGL does not allow chain-after-chain. - For TLS 1.3, wrong chain size when wrap entry - exists causes invalid scatterlist for - content_type byte, potential memory corruption - in crypto path. + The changes are confined to net/tls/tls_sw.c and only affect TLS + sockets that use the kernel TLS software path. A regression would + manifest as TLS send/receive failures or data corruption on kTLS + sockets; traffic that does not use kTLS is unaffected. - == Verification == - Commands to reproduce: + [ Other Info ] - sudo apt install linux-source-6.8.0 - sudo tar xf /usr/src/linux-source-6.8.0/\ - linux-source-6.8.0.tar.bz2 -C /tmp/ - - # Issue 1: - grep -n "rxm->offset += len" \ - /tmp/linux-source-6.8.0/net/tls/tls_sw.c - # Expected: line 2289 (vulnerable) - - # Issue 2: - grep -n "MAX_SKB_FRAGS - msg_pl->sg.start" \ - /tmp/linux-source-6.8.0/net/tls/tls_sw.c - # Expected: line 804 (vulnerable) - - # Issue 3: - grep -n "sg.end + 1" \ - /tmp/linux-source-6.8.0/net/tls/tls_sw.c - # Expected: line 796 (vulnerable) - - == References == - 7e7be31bfdb0: https://git.kernel.org/torvalds/c/7e7be31bfdb0 - 285943c6e7ca: https://git.kernel.org/torvalds/c/285943c6e7ca - ff26a0e8377d: https://git.kernel.org/torvalds/c/ff26a0e8377d + None of these commits carry a CVE upstream. They are pure upstream + cherry-picks with no Ubuntu-specific adaptations. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155609 Title: net/tls: Three upstream fixes without CVE missing from Ubuntu 6.8.0-124-generic Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: In Progress Bug description: [ Impact ] Three upstream net/tls bug fixes are missing from Noble (6.8.0, present through 6.8.0-132.133). All three touch net/tls/tls_sw.c, affect only kTLS sockets, and were not assigned a CVE upstream. They address data integrity and memory safety issues in the TLS software path: 1) Silent data drop under pipe back-pressure. tls_sw_splice_read() advances rxm->offset / rxm->full_len by the requested length instead of the number of bytes actually spliced into the pipe. When the destination pipe cannot accept everything, splice_to_pipe() returns fewer bytes than requested and the difference is silently skipped, corrupting the TLS RX stream. 2) Off-by-one in the sg_chain() entry count for a wrapped sk_msg ring. When the sk_msg scatterlist ring wraps (sg.end < sg.start), the chain pointer is placed one entry short of the true last entry, so the crypto engine is handed a malformed scatterlist. 3) chain-after-chain in the plaintext SG path. When the ring is empty (end == 0) the existing code emits a chain link that points directly at another chain link. The scatterlist API (sg_next) does not resolve consecutive chain links, so this is illegal input to crypto. [ Fix ] Clean cherry-picks of the following upstream commits, in order: 7e7be31bfdb0 ("net: tls: fix silent data drop under pipe back-pressure") 285943c6e7ca ("net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring") ff26a0e8377d ("net: tls: prevent chain-after-chain in plain text SG") (1) fixes commit e062fe99cccd; (2) and (3) fix commit 9aaaa56845a0. Both Fixes: targets are present in Noble. [ Test Plan ] Build: CBD build cengiz-noble-a55bcaa0d741-8479 amd64: BUILD-OK arm64: BUILD-OK armhf: BUILD-OK ppc64el: BUILD-OK s390x: BUILD-OK Boot: PASS (Kybele uvt-kvm boot test using the amd64 CBD artifacts) Kernel: 6.8.0-132-generic uname -v: #133 SMP PREEMPT_DYNAMIC Wed Jun 24 11:46:08 UTC 2026 [ Where Problems Could Occur ] The changes are confined to net/tls/tls_sw.c and only affect TLS sockets that use the kernel TLS software path. A regression would manifest as TLS send/receive failures or data corruption on kTLS sockets; traffic that does not use kTLS is unaffected. [ Other Info ] None of these commits carry a CVE upstream. They are pure upstream cherry-picks with no Ubuntu-specific adaptations. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155609/+subscriptions

[Bug 2158229] Re: MT7925 wifi is hard blocked on Dell's machine

** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Stonking) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: New => Triaged ** Changed in: linux (Ubuntu Resolute) Status: New => Triaged ** Changed in: linux (Ubuntu Resolute) Assignee: (unassigned) => AceLan Kao (acelankao) ** Also affects: linux (Ubuntu Questing) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Questing) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Questing) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-6.17 (Ubuntu Questing) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2158229 Title: MT7925 wifi is hard blocked on Dell's machine Status in linux package in Ubuntu: New Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Triaged Status in linux source package in Questing: New Status in linux-oem-6.17 source package in Questing: Invalid Status in linux source package in Resolute: Triaged Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux source package in Stonking: New Status in linux-oem-6.17 source package in Stonking: Invalid Bug description: [Impact] The wifi is hard blocked and can't be used randomly. [Test] 1. Boot up Machine 2. Run `rfkill list` to check wlan0 block state Wireless: Mediatek Inc. - 14c3:7925 ubuntu@localhost:~$ rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes [Affected Machines] 202505-36757 202501-36195 202501-36253 [Similar Issue] https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.14/+bug/2127044 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.17.0-1020-oem 6.17.0-1020.20 ProcVersionSignature: Ubuntu 6.17.0-1020.20-oem 6.17.13 Uname: Linux 6.17.0-1020-oem x86_64 ApportVersion: 2.28.2-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ubuntu 1918 F.... pipewire ubuntu 1922 F.... wireplumber /dev/snd/controlC0: ubuntu 1922 F.... wireplumber /dev/snd/seq: ubuntu 1918 F.... pipewire CasperMD5CheckMismatches: ./casper/initrd ./casper/vmlinuz ./casper/minimal.standard.live.hotfix.manifest ./casper/minimal.standard.live.hotfix.size ./casper/minimal.standard.live.size ./casper/minimal.manifest ./casper/minimal.standard.manifest ./casper/minimal.standard.size ./casper/minimal.hotfix.size ./casper/minimal.standard.live.hotfix.squashfs ./casper/minimal.standard.hotfix.squashfs ./casper/minimal.standard.hotfix.size ./casper/minimal.hotfix.squashfs ./casper/minimal.standard.live.manifest ./casper/minimal.size ./boot/grub/grub.cfg CasperMD5CheckResult: fail Date: Thu Jun 25 05:43:16 2026 DistributionChannelDescriptor: # This is the distribution channel descriptor for Ubuntu 24.04 for Dell # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-noble-oem-24.04b-proposed-20250604-520 InstallationDate: Installed on 2026-05-07 (49 days ago) InstallationMedia: Ubuntu OEM 24.04.2 LTS "Noble Numbat" - Release amd64 (20250603) IwConfig: lo no wireless extensions. enp195s0f0 no wireless extensions. wlp194s0 no wireless extensions. MachineType: Dell Inc. Dell Pro Max 14 MC14255 ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-1020-oem root=UUID=881d0e73-6adc-444d-90b2-9491672e82b1 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-6.17.0-1020-oem N/A linux-backports-modules-6.17.0-1020-oem N/A linux-firmware 20240318.git3b128b60-0ubuntu2.27 SourcePackage: linux-oem-6.17 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/09/2025 dmi.bios.release: 1.4 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.4.1 dmi.board.name: 0WT010 dmi.board.vendor: Dell Inc. dmi.board.version: D01 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.ec.firmware.release: 1.3 dmi.modalias: dmi:bvnDellInc.:bvr1.4.1:bd09/09/2025:br1.4:efr1.3:svnDellInc.:pnDellProMax14MC14255:pvr:rvnDellInc.:rn0WT010:rvrD01:cvnDellInc.:ct10:cvr:sku0D80: dmi.product.family: Dell Pro Max Laptops dmi.product.name: Dell Pro Max 14 MC14255 dmi.product.sku: 0D80 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158229/+subscriptions