Upstream linux-hardened tag v7.2.8-hardened1 available #63

New issue

Closed

opened 2026-09-30 21:01:00 +00:00 by unredacted_bot · 1 comment

unredacted_bot commented

2026-09-30 21:01:00 +00:00

Owner

Upstream tag: v7.2.8-hardened1
Local newest PUBLISHED: v7.2.7-hardened1

CVEs reported fixed in 7.2.8 since 7.2.7 (source: kernel.org CVE project).

Severity = Red Hat's rating (best-effort; the kernel CNA publishes no CVSS), not the project's own. List as of 2026-09-30T21:00Z — the feed can lag, so re-check vulns.git before building.

CVE-2026-98163 — Moderate (CVSS 5.5) — cgroup: Avoid iteration of dying tasks with zero refcount

The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from
cgroup_task_release() to cgroup_task_free()") extended the lifetime of
tasks on the dying_tasks list.
The iterators have provision to go through dying_tasks because of
dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however,
it was expected that such tasks can obtain a new reference (that is
possible before cgroup_task_release()/put_task_struct_rcu_user()).
The tasks after cgroup_task_release() and before cgroup_task_free()
are subject to race when they may or may not have ->usage count > 0.

The race window is between css_task_iter_next() invocations
when css_set_lock is released and we may arrive at a new ->task_pos.
The iterator should not attempt to resurrect tasks whose ->usage count
dropped to zero. (When that happens, __put_task_struct_rcu_cb() is
already imminent and the returned task_struct would could be used
after free.)

As for the fix, we cannot simply check the signal->live count of a task
on the dying list because that won't distinguish regular zombies waiting
to be reaped from RCU remnant tasks that are going to be free'd.
…

Action: review the upstream signature, then tag from an up-to-date
main and push — the tag push triggers build-kernel.yml.

git switch main && git pull --ff-only   # do NOT skip
git tag v7.2.8-hardened1
git push origin v7.2.8-hardened1

The pull is load-bearing. Seed-bump merges and publish: commits
land on main continuously between builds, so a tag cut from a
stale checkout builds an old seed pin and silently ships that config.
If you already pushed a stale tag, drop it on both sides
(git push origin :refs/tags/v7.2.8-hardened1 then
git tag -d v7.2.8-hardened1), pull, and re-tag.

See docs/users/cve-policy.md for the SLA.

Upstream tag: v7.2.8-hardened1 Local newest PUBLISHED: v7.2.7-hardened1 **CVEs reported fixed in `7.2.8` since `7.2.7`** (source: kernel.org CVE project). _Severity = Red Hat's rating (best-effort; the kernel CNA publishes no CVSS), not the project's own. List as of 2026-09-30T21:00Z — the feed can lag, so re-check vulns.git before building._ <details><summary><strong>CVE-2026-98163</strong> — Moderate (CVSS 5.5) — cgroup: Avoid iteration of dying tasks with zero refcount</summary> ```text The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. … ``` </details> Action: review the upstream signature, then tag from an up-to-date `main` and push — the tag push triggers build-kernel.yml. ``` git switch main && git pull --ff-only # do NOT skip git tag v7.2.8-hardened1 git push origin v7.2.8-hardened1 ``` The pull is load-bearing. Seed-bump merges and `publish:` commits land on `main` continuously between builds, so a tag cut from a stale checkout builds an old seed pin and silently ships that config. If you already pushed a stale tag, drop it on both sides (`git push origin :refs/tags/v7.2.8-hardened1` then `git tag -d v7.2.8-hardened1`), pull, and re-tag. See docs/users/cve-policy.md for the SLA.

zach commented

2026-09-30 22:35:54 +00:00

Owner

Released

zach closed this issue

2026-09-30 22:35:54 +00:00

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

unredacted/linux-hardened-unredacted#63

No description provided.

Rows
Columns