# backporting Published articles for backporting. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Android 17 on a 4.9 Kernel: LineageOS 24.0 on the Pixel 3a DevFeed: [Android 17 on a 4.9 Kernel: LineageOS 24.0 on the Pixel 3a]() Original publisher: [Read original article]() Author: xbill Published: 2026-11-06T15:13:25Z Content type: tutorial Language: en Sources: [ProAndroidDev]() Topics: [LineageOS](), [Android](), [Linux Kernel](), [SELinux](), [Linux]() Tags: [android](), [android-17](), [android-app-development](), [android-rom](), [androiddev](), [backporting](), [bluetooth](), [boot](), [build](), [chrome](), [connectivity](), [device-tree](), [google-play-services](), [init](), [ion](), [kernel](), [keys](), [lineageos](), [linux](), [linux-kernel](), [loader](), [logger](), [pixel]() ### AI overview The article reports a working LineageOS 24.0 (Android 17) port for the Pixel 3a on its original Linux 4.9.337 kernel: it boots with SELinux enforcing in 83 seconds, supports Wi-Fi, Bluetooth, sensors and Chrome, and can update without erasing user data. Android 17 expects newer kernel features, so the port combines a cgroup BPF reference-count fix, five platform-code forks for fscrypt, BPF/network handling and the native app zygote, plus device-tree changes. A /init logger that records kernel and system logs helped identify boot failures. Google Play Services required repackaging because its EROFS APEX cannot mount on kernel 4.9. Active Edge remains disabled; calls, SMS, audio, photos, fingerprint enrollment, NFC payments and satellite GPS are untested. Builds use test keys and trigger a recovery signature warning; first installation wipes the phone. ### Source excerpt This article provides a step by step guide to running LineageOS 24.0, which is Android 17, on a Google Pixel 3a and its original 4.9 Linux kernel. It continues the LineageOS 23.2 port on the same phone. Every patch, script and build is published. https://github.com/xbill9/android_kernel_google_msm-4.9/releases/tag/lineage-24.0-sargo-20261027 The Pixel 3a boots LineageOS 24.0 on kernel 4.9.337 with SELinux enforcing in 83 s, with Wi-Fi, Bluetooth, the sensors, Chrome and Google Play Services working, and updates that keep user data. Android 17 assumes a kernel of at least 5.10 in more places than Android 16 did. The port needed one kernel fix, for a cgroup BPF reference count the 4.9 backport had missed, five forks of platform code (fscrypt keys, the BPF loader, netd and Connectivity, and the native app zygote), and device-tree changes for ueventd, gralloc and the ION memory allocator. The /init logger from the 23.2 port found each one. What is this project trying to Do? The Pixel 3a (codename sargo) has a Snapdragon 670 and a 4.9 kernel. Its last Google build is Android 12. LineageOS carries it officially to 22.2, and the previous article in this series brought it to 23.2, Android 16, by backporting three kernel features. The goal here: keep the phone current and out of a landfill by running the newest LineageOS release, 24.0, on the kernel it already has. The kernel carries a BPF backport that reports itself to Android as 5.4. The NetBpfLoad lines from the first 24.0 boot show the version Android reads, 0x504012e, against the 5.10 it asks for: NetBpfLoad: skipping map sk_storage which requires kernel version 0x504012e >= 0x50a0000 NetBpfLoad: skipping map packet_trace_ringbuf which requires kernel version 0x504012e >= 0x50a0000At This Point You Should Have... A Google Pixel 3a (sargo), bootloader unlocked The LineageOS 24.0 source with the local manifest from the release A build machine with room for the tree; the 24.0 tree here is 266 GB, and the home machine is an ## Critical security vulnerability affects OpenSSH on Alpine Linux systems DevFeed: [Critical security vulnerability affects OpenSSH on Alpine Linux systems]() Original publisher: [Read original article]() Author: jzb Published: 2026-11-05T11:39:10Z Content type: news Language: en Sources: [LWN.net]() Topics: [Vulnerabilities](), [OpenSSH](), [Linux]() Tags: [2022](), [alpine](), [alpine-linux](), [authentication](), [backporting](), [bug](), [critical](), [critical-vulnerability](), [glibc](), [libc](), [linux](), [mitigation](), [musl](), [openssh](), [pam](), [password](), [security](), [ssh](), [vulnerability](), [workaround]() ### AI overview OpenSSH 10.6p2 provides a workaround for a critical vulnerability affecting Linux systems that use musl libc with PAM disabled, including Alpine Linux. OpenSSH developer Damien Miller advised operators to set `PasswordAuthentication=no` or disable SSH immediately on those systems. The source says the vulnerability does not affect non-Linux systems, Linux systems using glibc, or Linux systems using PAM for password authentication. OpenSSH describes the root cause as outside OpenSSH itself. Alpine Linux plans to backport the fix to releases as far back as Alpine 3.16, released in May 2022. ### Source excerpt Version 10.6p2 of OpenSSH has been released with a workaround for a critical vulnerability that affects Linux systems that use musl libc with PAM disabled, such as Alpine Linux. OpenSSH developer Damien Miller said: If you operate a Linux system that uses musl libc without PAM (Alpine Linux is one example) then stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY. This vulnerability does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication. We consider the root cause of this bug to be outside OpenSSH itself, but we're in a good position to deliver a mitigation quickly. The Alpine Linux project has announced that it will be backporting the OpenSSH fix "all the way back to Alpine 3.16", which was released in May 2022. ## These New Linux Security Flaws Made Me Check My Home Lab DevFeed: [These New Linux Security Flaws Made Me Check My Home Lab]() Original publisher: [Read original article]() Author: Brandon Lee Published: 2026-10-31T12:43:11Z Content type: article Language: en Sources: [Virtualization Howto]() Topics: [Vulnerabilities](), [Linux](), [Homelab](), [patches](), [Security research]() Tags: [almalinux](), [apt](), [attack-surface](), [audit](), [authentication](), [backporting](), [blast-radius](), [connectivity](), [container](), [container-hosts](), [containers](), [crash](), [cvss](), [cvss-score](), [home-lab](), [home-server](), [linux](), [linux-security](), [security](), [security-vulnerabilities](), [vulnerabilities]() ### AI overview The article identifies six disclosed Linux vulnerabilities across the kernel and ConnMan, emphasizing that exposure depends on enabled components and configuration. It flags ZDI-CAN-33367 (CVSS 7.8) as a practical concern for self-hosted servers: its local privilege escalation can follow an initial compromise, and its exploit uses unprivileged user namespaces. Check kernel and OS versions, compare against distribution advisories, and account for backported fixes; AlmaLinux has patches for this issue in production repositories for versions 8-10. Disabling unprivileged namespaces may disrupt rootless containers or sandboxed apps, so the article favors applying kernel fixes. The two CVSS 9.0 issues affect ksmbd, not necessarily Samba, and one requires a specific RDMA and writable-share configuration. Other checks cover vmwgfx, NVMe target modules, and ConnMan. Container updates do not patch the host kernel; the article also recommends auditing Docker privileges and Kubernetes seccomp settings, while warning that restrictions can affect workloads. ### Source excerpt In case you haven't heard, there are 6 new Linux security vulnerabilities that I wanted to write a quite blog about that you want to take note of for your... The post These New Linux Security Flaws Made Me Check My Home Lab appeared first on Virtualization Howto. ## Why embargoes matter for open source security DevFeed: [Why embargoes matter for open source security]() Original publisher: [Read original article]() Author: Rajan Patel Published: 2026-10-30T00:01:00Z Content type: article Language: en Sources: [Canonical]() Topics: [Vulnerabilities](), [Ubuntu](), [Open Source](), [open source maintenance](), [open source communities](), [canonical]() Tags: [automated-testing](), [backporting](), [canonical](), [cloud](), [code-execution](), [collaboration](), [exploit](), [maintainers](), [open-source](), [open-source-security](), [patch](), [patching](), [security](), [security-patch](), [security-vulnerabilities](), [software](), [software-vulnerability](), [transparency](), [vulnerabilities](), [vulnerability]() ### AI overview A security embargo gives maintainers and distributors time to prepare and test patches before vulnerability details become public, enabling coordinated releases across the open-source ecosystem. The text describes two critical PHP remote code execution flaws affecting versions 5.4-8.5; details leaked before the planned release, prompting maintainers to move the embargo date forward. Canonical says it received early notice, backported and tested fixes for security-maintained Ubuntu releases from 14.04 LTS to 26.10, then published packages when the embargo lifted. Ubuntu users with Unattended Upgrades enabled receive available fixes through the default 24-hour update cycle. The account presents coordinated disclosure as dependent on trust and useful for avoiding fragmented patch releases, while noting that leaks force teams to accelerate response without dropping verification and coordination. ### Source excerpt Open source is built on a foundation of transparency, collaboration, and speed. We share code, we share ideas, and together, we build better software. But when it comes to discovering and patching security vulnerabilities, that standard model of immediate, public sharing has to temporarily shift. A security embargo is a temporary agreement to keep a software vulnerability private so that vendors and maintainers can create and release a security patch before malicious actors learn how to exploit it. ## php2shell (CVE-2026-109618, CVE-2026-109619): Patches in progress DevFeed: [php2shell (CVE-2026-109618, CVE-2026-109619): Patches in progress]() Original publisher: [Read original article]() Author: Jonathan Wright Infrastructure SIG Lead; ALESCo Member Published: 2026-10-21T00:00:00Z Content type: news Language: en Sources: [AlmaLinux]() Topics: [cve remediation](), [patches]() Tags: [2026](), [account](), [all](), [almalinux](), [backporting](), [building](), [can](), [code](), [core](), [critical](), [cve](), [cve-2026-109618](), [cve-2026-109619](), [cvss](), [cvss-v4-0](), [either](), [http](), [patches](), [php2shell](), [progress]() ### AI overview The php2shell flaws (CVE-2026-109618 and CVE-2026-109619) can each enable unauthenticated remote code execution through crafted HTTP requests. AlmaLinux 8, 9, and 10 ship affected PHP; PHP rated both Critical (9.2 CVSS v4.0). One flaw involves out-of-memory corruption during request cleanup; the other uses stale global state after a request ends, including confirmed paths through session upload progress and PHP settings. PHP released fixes, and AlmaLinux was preparing patches for supported streams for its testing repository. Until patched packages are available, suggested mitigations include disabling session upload progress, removing warning-producing per-request settings, addressing triggerable fatal errors, and reducing out-of-memory attack paths with memory and request-size controls. These measures reduce specific exposure; updating is the full solution. Retired PHP streams are excluded from the first patch round. ### Source excerpt Two critical vulnerabilities in PHP, nicknamed php2shell, were disclosed by PHP today: CVE-2026-109618 and CVE-2026-109619. Either one can let an unauthenticated attacker run code on a web server, as the account PHP runs under, by sending it crafted HTTP requests. PHP rates both 9.2 (Critical) on CVSS v4.0. AlmaLinux 8, 9, and 10 all ship affected PHP versions. We are aware of these vulnerabilities, and our core team is actively backporting the fixes and building patched packages. We expect to release them to the testing repository later today, and we will update this post with package versions and testing instructions as soon as they are available. Until then, the mitigations below reduce your exposure. ## Java library vulnerabilities: IBM and Red Hat fix 400+ previously unknown flaws DevFeed: [Java library vulnerabilities: IBM and Red Hat fix 400+ previously unknown flaws]() Original publisher: [Read original article]() Author: Anamarija Pogorelec Published: 2026-10-08T04:18:00Z Content type: news Language: en Sources: [Help Net Security]() Topics: [software composition analysis](), [snyk-open-source](), [cve remediation](), [Open Source](), [redhat](), [ibm]() Tags: [backporting](), [dependencies](), [enterprise](), [ibm](), [java](), [java-libraries](), [news](), [open-source](), [red-hat](), [security](), [vulnerability-assessment](), [vulnerability-management]() ### AI overview IBM and Red Hat say they found and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries through Lightwell, which backports fixes into older versions used in production. Its new Lightwell Clearinghouse lets enterprise customers request review and repair of specific open source dependencies. The companies did not identify the affected libraries, provide CVE numbers or severity scores, or give a timeframe for the discoveries. ### Source excerpt IBM and Red Hat have found and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries through Lightwell, their program for patching open source code that companies already run in production. Companies running the affected libraries are exposed until they apply the fixes. Autonomous AI agents can now combine several minor software weaknesses into one serious attack. "AI agents do not care if a codebase is ten years old or otherwise considered ... More -> The post Java library vulnerabilities: IBM and Red Hat fix 400+ previously unknown flaws appeared first on Help Net Security. ## IBM and Red Hat patch 400-plus unknown Java flaws, open Clearinghouse for fix requests DevFeed: [IBM and Red Hat patch 400-plus unknown Java flaws, open Clearinghouse for fix requests]() Original publisher: [Read original article]() Author: Duncan Riley Published: 2026-10-06T13:00:57Z Content type: news Language: en Sources: [SiliconANGLE]() Topics: [software composition analysis](), [Security research](), [redhat](), [ibm](), [snyk-open-source]() Tags: [ai-agents](), [backporting](), [clearinghouse-premier](), [cybersecurity](), [dependencies](), [fixed](), [gunnar-hellekson](), [ibm](), [java](), [lightwell](), [lightwell-clearinghouse](), [lightwell-network](), [news](), [open-source](), [open-source-security](), [red-hat](), [responsible-disclosure](), [security](), [software-supply-chain](), [the-latest](), [vulnerabilities](), [vulnerability-remediation]() ### AI overview IBM and Red Hat say their Lightwell program has identified and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries. They have also made Lightwell Clearinghouse generally available, allowing enterprise customers to submit dependencies for priority review and remediation. The fixes are backported to older versions used in production, and applicable patches are submitted upstream under responsible disclosure protocols. ### Source excerpt IBM Corp. and its Red Hat unit said today that their Lightwell open-source security program has found and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries. The companies also made Lightwell Clearinghouse generally available. Enterprise customers can use it to submit specific open-source dependencies to IBM and Red Hat for priority [...] The post IBM and Red Hat patch 400-plus unknown Java flaws, open Clearinghouse for fix requests appeared first on SiliconANGLE. ## GrapheneOS Isn't Happy With Google Over Pixel's Widening Head Start DevFeed: [GrapheneOS Isn't Happy With Google Over Pixel's Widening Head Start]() Original publisher: [Read original article]() Author: Sourav Rudra Published: 2026-09-18T14:17:00Z Content type: opinion Language: en Sources: [It's FOSS]() Topics: [GrapheneOS](), [Google]() Tags: [2026](), [android](), [android-17](), [android-security](), [aosp](), [apis](), [app-ecosystem](), [backporting](), [big-tech](), [compliance](), [delay](), [developer](), [google](), [gpl](), [grapheneos](), [keep](), [kernel](), [manufacturers](), [news](), [patches](), [pixel]() ### AI overview GrapheneOS says Google is delaying standard Android security fixes that appear in the September 2026 Pixel bulletin, leaving non-Pixel manufacturers without them until Android 17 QPR2 is expected in December. It also reports that Android 17 QPR1 added developer APIs absent from AOSP; GrapheneOS has ported its code but says it cannot ship that work, so it is backporting QPR1 Pixel components to Android 17. Separately, GrapheneOS says Google took more than two weeks to provide GPL source code it requested on September 1. The excerpt presents these as recurring ecosystem concerns, while noting that each delay alone is not catastrophic. It also describes opposition to a planned 2027 app developer registration requirement and associated sideloading steps. ### Source excerpt GrapheneOS is calling out Google over its negligence in providing certain patches. ## How a missed Arm Mali driver patch enabled kernel code execution on Pixel 6 DevFeed: [How a missed Arm Mali driver patch enabled kernel code execution on Pixel 6]() Original publisher: [Read original article]() Author: Man Yue Mo Published: 2023-04-06T16:00:48Z Content type: article Language: en Sources: [GitHub Blog]() Topics: [patches](), [Linux](), [Open Source](), [CVE-2021-44228]() Tags: [android](), [android-security](), [arm](), [backporting](), [exploit-development](), [github-security-lab](), [patch](), [security](), [vulnerability-research]() ### AI overview The article examines a missing Arm Mali driver patch in the January Pixel 6 update. A race condition involving JIT memory could let a malicious app retain access to freed memory, overwrite kernel code, and gain root privileges. The vulnerability was fixed in the March 2023 update. The author argues that more transparent security patch backporting could help prevent similar delays. ### Source excerpt In this post, I'll look at a security-related change in version r40p0 of the Arm Mali driver that was AWOL in the January update of the Pixel bulletin, where other patches from r40p0 was applied, and how these two lines of changes can be exploited to gain arbitrary kernel code execution and root from a malicious app. This highlights how treacherous it can be when backporting security changes. ## Introducing Vectordrawable-Seekable DevFeed: [Introducing Vectordrawable-Seekable]() Original publisher: [Read original article]() Author: Alistair Sykes Published: 2020-05-11T13:35:28Z Content type: release Language: en Sources: [Android & Tech News]() Topics: [animations]() Tags: [android](), [android-app-development](), [android-development](), [animation](), [apis](), [app](), [asset](), [backporting](), [core](), [how-to](), [library](), [material-design]() ### AI overview Vectordrawable-Seekable adds pause and seek controls to animated vector drawables through the SeekableAnimatedVectorDrawable class, which uses AnimatorSet and Animator from the separate AndroidX Core-Animation library. The excerpt describes creating an optimized vector asset with named groups and pivot points, defining an ObjectAnimator in XML, and connecting the drawable and animation in an animated vector XML file. Converting that resource to SeekableAnimatedVectorDrawable provides pause and seek functionality. The excerpt also mentions displaying the animation through a view or programmatically, but cuts off during a note about duration for infinite animations. ### Source excerpt Using the new and improved AnimatedVectorDrawable to pause and seek your animations.AnimatedVectorDrawable Android SDK 21 introduced both the VectorDrawable and the AnimatedVectorDrawable. This allowed you to use vector assets within your app, and even animate them. They've iterated on these since then, but AnimatedVectorDrawable was still missing something. You couldn't manipulate and control the animation. There was no pause or seek functionality. Core-Animation The Android team has been hard at work backporting the framework Animator APIs. They have created a separate unbundled AndroidX library called Core-Animation. The Animator APIs have been around for some time. But they didn't provide the capabilities needed for this pause and seek functionality. So they needed to be unbundled and then iterated on. Vectordrawable-Seekable Once Core-Animation was available the Android team could create the Vectordrawable-Seekable library. This library revolves around the class SeekableAnimatedVectorDrawable. Under the hood, this class uses the AnimatorSet and subsequently Animator from Core-Animation. These provide the pause and seek functionality. How toCreate the vector Firstly, you need a vector asset of the image you wish to animate. This works best if it is simple and optimised. See these resources for information on optimising assets: - https://www.brightec.co.uk/blog/creating-vector-drawables-android - https://arturdryomov.dev/posts/optimizing-android-vector-images/ For this example I am going to use an Android: https://medium.com/media/c1f49ee65961374471c7019479d595cf/href This XML file should be placed in your res/drawable directory. Notice the group names, as these allow us to reference each part of the image later. Notice also the pivot points defined. These define the pivot around which rotation would happen. Create the animation To define the animation itself you can create another XML file. This defines an ObjectAnimator. https://medium.com/media/51350379510a257