lp:~ubuntu-kernel/ubuntu/+source/linux/+git/noble

Get this repository:
git clone https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble
Members of Ubuntu Kernel Repositories can upload to this repository. Log in for directions.

Branches

Name Last Modified Last Commit
hwe-6.11-next 2025-02-17 09:40:21 UTC
UBUNTU: Ubuntu-hwe-6.11-6.11.0-19.19~24.04.1

Author: Stefan Bader
Author Date: 2025-02-17 09:40:21 UTC

UBUNTU: Ubuntu-hwe-6.11-6.11.0-19.19~24.04.1

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

master-prep 2025-02-14 13:04:26 UTC
UBUNTU: Ubuntu-6.8.0-56.58

Author: Mehmet Basaran
Author Date: 2025-02-14 13:04:26 UTC

UBUNTU: Ubuntu-6.8.0-56.58

Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>

master-next 2025-02-14 13:04:26 UTC
UBUNTU: Ubuntu-6.8.0-56.58

Author: Mehmet Basaran
Author Date: 2025-02-14 13:04:26 UTC

UBUNTU: Ubuntu-6.8.0-56.58

Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>

master-next--s2025.01.13-1 2025-02-12 17:13:41 UTC
UBUNTU: [Packaging] linux-tools: Fall back to old python perf path

Author: Juerg Haefliger
Author Date: 2025-01-23 16:06:35 UTC

UBUNTU: [Packaging] linux-tools: Fall back to old python perf path

BugLink: https://bugs.launchpad.net/bugs/2089411

linux-tools from older kernels without these patches provide the
perf python library in a different/broken path, so we have to look
there as well. Sigh.

Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Kevin Becker <kevin.becker@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>

lowlatency-hwe-6.11-next 2025-02-08 20:32:06 UTC
UBUNTU: Ubuntu-lowlatency-hwe-6.11-6.11.0-1010.11~24.04.1

Author: Manuel Diewald
Author Date: 2025-02-08 20:32:06 UTC

UBUNTU: Ubuntu-lowlatency-hwe-6.11-6.11.0-1010.11~24.04.1

Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

lowlatency-next 2025-02-08 00:16:40 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-54.56.1

Author: Manuel Diewald
Author Date: 2025-02-08 00:16:40 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-54.56.1

Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

master-next--s2024.12.02-1 2025-01-10 11:27:46 UTC
net: sched: fix ordering of qlen adjustment

Author: Lion Ackermann
Author Date: 2025-01-08 01:20:44 UTC

net: sched: fix ordering of qlen adjustment

Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen
_before_ a call to said function because otherwise it may fail to notify
parent qdiscs when the child is about to become empty.

Signed-off-by: Lion Ackermann <nnamrec@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5eb7de8cd58e73851cd37ff8d0666517d9926948)
CVE-2024-53164
Signed-off-by: Ian Whitfield <ian.whitfield@canonical.com>
Acked-by: Magali Lemes <magali.lemes@canonical.com>
Acked-by: Benjamin M Romer <benjamin.romer@canonical.com>
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

lowlatency-next--2024.10.28-1--auto 2024-12-04 02:48:36 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-50.51.1

Author: Ubuntu Kernel Bot
Author Date: 2024-12-04 02:48:36 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-50.51.1

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

hwe-6.11-next--s2024.10.28-1--auto 2024-12-04 02:01:07 UTC
UBUNTU: Ubuntu-hwe-6.11-6.11.0-13.14~24.04.1

Author: Ubuntu Kernel Bot
Author Date: 2024-12-04 02:01:07 UTC

UBUNTU: Ubuntu-hwe-6.11-6.11.0-13.14~24.04.1

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.10.28-1--auto 2024-12-02 15:17:18 UTC
UBUNTU: Ubuntu-6.8.0-51.52

Author: Ubuntu Kernel Bot
Author Date: 2024-12-02 15:17:18 UTC

UBUNTU: Ubuntu-6.8.0-51.52

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.10.28-1 2024-11-30 17:52:54 UTC
mm/mglru: only clear kswapd_failures if reclaimable

Author: Wei Xu
Author Date: 2024-11-21 23:05:00 UTC

mm/mglru: only clear kswapd_failures if reclaimable

BugLink: https://bugs.launchpad.net/bugs/2087886

lru_gen_shrink_node() unconditionally clears kswapd_failures, which can
prevent kswapd from sleeping and cause 100% kswapd cpu usage even when
kswapd repeatedly fails to make progress in reclaim.

Only clear kswap_failures in lru_gen_shrink_node() if reclaim makes some
progress, similar to shrink_node().

I happened to run into this problem in one of my tests recently. It
requires a combination of several conditions: The allocator needs to
allocate a right amount of pages such that it can wake up kswapd
without itself being OOM killed; there is no memory for kswapd to
reclaim (My test disables swap and cleans page cache first); no other
process frees enough memory at the same time.

Link: https://lkml.kernel.org/r/20241014221211.832591-1-weixugc@google.com
Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists")
Signed-off-by: Wei Xu <weixugc@google.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jan Alexander Steffens <heftig@archlinux.org>
Cc: Suleiman Souhlal <suleiman@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

(cherry picked from commit b130ba4a6259f6b64d8af15e9e7ab1e912bcb7ad)
Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com>
Acked-by: Koichiro Den <koichiro.den@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

master-next--2024.10.28-1--auto 2024-11-21 22:15:47 UTC
UBUNTU: Ubuntu-6.8.0-51.51

Author: Ubuntu Kernel Bot
Author Date: 2024-11-21 22:15:47 UTC

UBUNTU: Ubuntu-6.8.0-51.51

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

lowlatency-next--s2024.09.30-1--auto 2024-11-15 16:29:06 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-49.49.1

Author: Ubuntu Kernel Bot
Author Date: 2024-11-15 16:29:06 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-49.49.1

Signed-off-by: Ubuntu Kernel Bot <kernel-team-bot+auto-prepare@canonical.com>

master-next--s2024.09.30-1--auto 2024-11-15 14:56:22 UTC
UBUNTU: Ubuntu-6.8.0-49.49

Author: Ubuntu Kernel Bot
Author Date: 2024-11-15 14:56:22 UTC

UBUNTU: Ubuntu-6.8.0-49.49

Signed-off-by: Ubuntu Kernel Bot <kernel-team-bot+auto-prepare@canonical.com>

lowlatency-next--2024.10.28-1 2024-11-09 20:38:45 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-49.49.1

Author: Mehmet Basaran
Author Date: 2024-11-09 20:38:45 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-49.49.1

Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>

master-next--2024.10.28-1 2024-11-08 07:24:30 UTC
UBUNTU: Ubuntu-6.8.0-50.50

Author: Mehmet Basaran
Author Date: 2024-11-07 21:05:21 UTC

UBUNTU: Ubuntu-6.8.0-50.50

Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>

master 2024-11-01 10:56:32 UTC
UBUNTU: Ubuntu-6.8.0-49.49

Author: Manuel Diewald
Author Date: 2024-11-01 10:56:32 UTC

UBUNTU: Ubuntu-6.8.0-49.49

Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

master-next--s2024.09.30-1 2024-10-31 13:41:40 UTC
sch/netem: fix use after free in netem_dequeue

Author: Stephen Hemminger
Author Date: 2024-10-09 16:43:42 UTC

sch/netem: fix use after free in netem_dequeue

commit 3b3a2a9c6349e25a025d2330f479bc33a6ccb54a upstream.

If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")

Commands to trigger KASAN UaF:

ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF

Fixes: 50612537e9ab ("netem: fix classful handling")
Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Link: https://patch.msgid.link/20240901182438.4992-1-stephen@networkplumber.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 32008ab989ddcff1a485fa2b4906234c25dc5cd6 linux-6.10.y)
CVE-2024-46800
Signed-off-by: Bethany Jamison <bethany.jamison@canonical.com>
Acked-by: Ivan Hu <ivan.hu@canonical.com>
Acked-by: Guoqing Jiang <guoqing.jiang@canonical.com>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>

lowlatency-next--2024.09.30-1--auto 2024-10-25 21:55:54 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-48.48.1

Author: Ubuntu Kernel Bot
Author Date: 2024-10-25 21:55:54 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-48.48.1

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--2024.09.30-1--auto 2024-10-25 21:07:43 UTC
UBUNTU: Ubuntu-6.8.0-48.48

Author: Ubuntu Kernel Bot
Author Date: 2024-10-25 21:07:43 UTC

UBUNTU: Ubuntu-6.8.0-48.48

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

lowlatency-next--s2024.09.02-1--auto 2024-10-24 10:39:44 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-47.47.1

Author: Ubuntu Kernel Bot
Author Date: 2024-10-24 10:39:44 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-47.47.1

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.09.02-1 2024-09-25 18:05:46 UTC
netem: fix return value if duplicate enqueue fails

Author: Stephen Hemminger
Author Date: 2024-09-24 15:45:00 UTC

netem: fix return value if duplicate enqueue fails

There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.

This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.

There are two ways for the bug happen:

- If the duplicated packet is dropped by rootq->enqueue() and then
  the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc
  and the original packet is dropped.

In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.

Fixes: 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240819175753.5151-1-stephen@networkplumber.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

CVE-2024-45016
(cherry picked from commit c07ff8592d57ed258afee5a5e04991a48dbaf382)
Signed-off-by: Ian Whitfield <ian.whitfield@canonical.com>
Acked-by: Magali Lemes <magali.lemes@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

lowlatency-next--s2024.08.05-1--auto 2024-09-02 15:25:58 UTC
UBUNTU: Ubuntu-lowlatency-6.8.0-45.45.1

Author: Ubuntu Kernel Bot
Author Date: 2024-09-02 15:25:58 UTC

UBUNTU: Ubuntu-lowlatency-6.8.0-45.45.1

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.08.05-1--auto 2024-09-02 04:07:59 UTC
UBUNTU: Ubuntu-6.8.0-45.45

Author: Ubuntu Kernel Bot
Author Date: 2024-09-02 04:07:59 UTC

UBUNTU: Ubuntu-6.8.0-45.45

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.08.05-1 2024-08-28 20:03:58 UTC
bpf: Fix overrunning reservations in ringbuf

Author: Daniel Borkmann
Author Date: 2024-06-21 14:08:27 UTC

bpf: Fix overrunning reservations in ringbuf

BugLink: https://bugs.launchpad.net/bugs/2076435

[ Upstream commit cfa1a2329a691ffd991fcf7248a57d752e712881 ]

The BPF ring buffer internally is implemented as a power-of-2 sized circular
buffer, with two logical and ever-increasing counters: consumer_pos is the
consumer counter to show which logical position the consumer consumed the
data, and producer_pos which is the producer counter denoting the amount of
data reserved by all producers.

Each time a record is reserved, the producer that "owns" the record will
successfully advance producer counter. In user space each time a record is
read, the consumer of the data advanced the consumer counter once it finished
processing. Both counters are stored in separate pages so that from user
space, the producer counter is read-only and the consumer counter is read-write.

One aspect that simplifies and thus speeds up the implementation of both
producers and consumers is how the data area is mapped twice contiguously
back-to-back in the virtual memory, allowing to not take any special measures
for samples that have to wrap around at the end of the circular buffer data
area, because the next page after the last data page would be first data page
again, and thus the sample will still appear completely contiguous in virtual
memory.

Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
book-keeping the length and offset, and is inaccessible to the BPF program.
Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
possible to make a second allocated memory chunk overlapping with the first
chunk and as a result, the BPF program is now able to edit first chunk's
header.

For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
allocate a chunk B with size 0x3000. This will succeed because consumer_pos
was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`
check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
page and could cause a crash.

Fix it by calculating the oldest pending_pos and check whether the range
from the oldest outstanding record to the newest would span beyond the ring
buffer size. If that is the case, then reject the request. We've tested with
the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
before/after the fix and while it seems a bit slower on some benchmarks, it
is still not significantly enough to matter.

Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Reported-by: Muhammad Ramdhan <ramdhan@starlabs.sg>
Co-developed-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Co-developed-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20240621140828.18238-1-daniel@iogearbox.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Portia Stephens <portia.stephens@canonical.com>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
CVE-2024-41009
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

master-next--2024.07.08-1--auto 2024-08-25 19:40:18 UTC
UBUNTU: Ubuntu-6.8.0-40.40

Author: Ubuntu Kernel Bot
Author Date: 2024-08-25 19:40:18 UTC

UBUNTU: Ubuntu-6.8.0-40.40

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.06.10-1--auto 2024-08-25 19:28:55 UTC
UBUNTU: Ubuntu-6.8.0-39.39

Author: Ubuntu Kernel Bot
Author Date: 2024-08-25 19:28:55 UTC

UBUNTU: Ubuntu-6.8.0-39.39

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.07.08-1--auto 2024-08-23 17:57:58 UTC
UBUNTU: Ubuntu-6.8.0-41.41

Author: Ubuntu Kernel Bot
Author Date: 2024-08-23 17:57:58 UTC

UBUNTU: Ubuntu-6.8.0-41.41

Signed-off-by: Ubuntu Kernel Bot <ubuntu-kernel-bot@canonical.com>

master-next--s2024.07.08-1 2024-07-30 17:00:13 UTC
md/md-bitmap: fix writing non bitmap pages

Author: Ofir Gal
Author Date: 2024-07-30 04:38:21 UTC

md/md-bitmap: fix writing non bitmap pages

BugLink: https://bugs.launchpad.net/bugs/2075110

__write_sb_page() rounds up the io size to the optimal io size if it
doesn't exceed the data offset, but it doesn't check the final size
exceeds the bitmap length.

For example:
page count - 1
page size - 4K
data offset - 1M
optimal io size - 256K

The final io size would be 256K (64 pages) but md_bitmap_storage_alloc()
allocated 1 page, the IO would write 1 valid page and 63 pages that
happens to be allocated afterwards. This leaks memory to the raid device
superblock.

This issue caused a data transfer failure in nvme-tcp. The network
drivers checks the first page of an IO with sendpage_ok(), it returns
true if the page isn't a slabpage and refcount >= 1. If the page
!sendpage_ok() the network driver disables MSG_SPLICE_PAGES.

As of now the network layer assumes all the pages of the IO are
sendpage_ok() when MSG_SPLICE_PAGES is on.

The bitmap pages aren't slab pages, the first page of the IO is
sendpage_ok(), but the additional pages that happens to be allocated
after the bitmap pages might be !sendpage_ok(). That cause
skb_splice_from_iter() to stop the data transfer, in the case below it
hangs 'mdadm --create'.

The bug is reproducible, in order to reproduce we need nvme-over-tcp
controllers with optimal IO size bigger than PAGE_SIZE. Creating a raid
with bitmap over those devices reproduces the bug.

In order to simulate large optimal IO size you can use dm-stripe with a
single device.
Script to reproduce the issue on top of brd devices using dm-stripe is
attached below (will be added to blktest).

I have added some logs to test the theory:
...
md: created bitmap (1 pages) for device md127
__write_sb_page before md_super_write offset: 16, size: 262144. pfn: 0x53ee
=== __write_sb_page before md_super_write. logging pages ===
pfn: 0x53ee, slab: 0 <-- the only page that allocated for the bitmap
pfn: 0x53ef, slab: 1
pfn: 0x53f0, slab: 0
pfn: 0x53f1, slab: 0
pfn: 0x53f2, slab: 0
pfn: 0x53f3, slab: 1
...
nvme_tcp: sendpage_ok - pfn: 0x53ee, len: 262144, offset: 0
skbuff: before sendpage_ok() - pfn: 0x53ee
skbuff: before sendpage_ok() - pfn: 0x53ef
WARNING at net/core/skbuff.c:6848 skb_splice_from_iter+0x142/0x450
skbuff: !sendpage_ok - pfn: 0x53ef. is_slab: 1, page_count: 1
...

Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ofir Gal <ofir.gal@volumez.com>
Signed-off-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/r/20240607072748.3182199-1-ofir.gal@volumez.com
(cherry picked from commit ab99a87542f194f28e2364a42afbf9fb48b1c724)
Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com>
Acked-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>

master-next--2024.07.08-1 2024-07-05 07:42:08 UTC
drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

Author: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?=
Author Date: 2024-07-04 07:47:00 UTC

drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

BugLink: https://bugs.launchpad.net/bugs/2069380

On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.

Note that on every other platform this itself would hang the
machine, but on MTL the system firmware is expected to relax
the access permission guarding stolen memory to enable this
workaround, and thus direct CPU accesses should be fine.

The raw stolen memory areas won't be passed to VMs so we'll
need to risk using the BAR there for the initial setup. Once
command submission is up we should switch to MI_UPDATE_GTT
which at least shouldn't hang the whole machine.

v2: Don't use direct GSM/DSM access on guests
    Add w/a number
v3: Check register 0x138914 to see if pcode did its job
    Add some debug prints

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com

(cherry picked from commit c08c364102d07288610734de34111a666e730ae7)
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

master-next--s2024.06.10-1 2024-07-04 19:02:03 UTC
x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler

Author: Tom Lendacky
Author Date: 2024-07-03 22:11:00 UTC

x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler

The MWAITX and MONITORX instructions generate the same #VC error code as
the MWAIT and MONITOR instructions, respectively. Update the #VC handler
opcode checking to also support the MWAITX and MONITORX opcodes.

Fixes: e3ef461af35a ("x86/sev: Harden #VC instruction emulation somewhat")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/453d5a7cfb4b9fe818b6fb67f93ae25468bc9e23.1713793161.git.thomas.lendacky@amd.com

CVE-2024-25742
(cherry picked from commit e70316d17f6ab49a6038ffd115397fd68f8c7be8)
Signed-off-by: Yuxuan Luo <yuxuan.luo@canonical.com>
Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

master-next--s2024.04.29-1 2024-06-07 10:28:52 UTC
netfilter: nft_set_pipapo: do not free live element

Author: Florian Westphal
Author Date: 2024-05-22 22:19:15 UTC

netfilter: nft_set_pipapo: do not free live element

[ Upstream commit 3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc ]

Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern. Quoting Pablo:

  add_elem("00000000") timeout 100 ms
  ...
  add_elem("0000000X") timeout 100 ms
  del_elem("0000000X") <---------------- delete one that was just added
  ...
  add_elem("00005000") timeout 100 ms

  1) nft_pipapo_remove() removes element 0000000X
  Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one
element that share the same key.

This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.

The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).

Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.

v2: avoid uneeded temporary variable (Stefano)

Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 14b001ba221136c15f894577253e8db535b99487 linux-6.8.y)
CVE-2024-26924
Signed-off-by: Bethany Jamison <bethany.jamison@canonical.com>
Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Acked-by: Thibault Ferrante <thibault.ferrante@canonical.com>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>

master-next--2024.06.10-1 2024-06-07 09:27:56 UTC
sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()

Author: Xuewen Yan
Author Date: 2024-06-07 04:05:00 UTC

sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()

BugLink: https://bugs.launchpad.net/bugs/2068024

It was possible to have pick_eevdf() return NULL, which then causes a
NULL-deref. This turned out to be due to entity_eligible() returning
falsely negative because of a s64 multiplcation overflow.

Specifically, reweight_eevdf() computes the vlag without considering
the limit placed upon vlag as update_entity_lag() does, and then the
scaling multiplication (remember that weight is 20bit fixed point) can
overflow. This then leads to the new vruntime being weird which then
causes the above entity_eligible() to go side-ways and claim nothing
is eligible.

Thus limit the range of vlag accordingly.

All this was quite rare, but fatal when it does happen.

Closes: https://lore.kernel.org/all/ZhuYyrh3mweP_Kd8@nz.home/
Closes: https://lore.kernel.org/all/CA+9S74ih+45M_2TPUY_mPPVDhNvyYfy1J1ftSix+KjiTVxg8nw@mail.gmail.com/
Closes: https://lore.kernel.org/lkml/202401301012.2ed95df0-oliver.sang@intel.com/
Fixes: eab03c23c2a1 ("sched/eevdf: Fix vruntime adjustment on reweight")
Reported-by: Sergei Trofimovich <slyich@gmail.com>
Reported-by: Igor Raits <igor@gooddata.com>
Reported-by: Breno Leitao <leitao@debian.org>
Reported-by: kernel test robot <oliver.sang@intel.com>
Reported-by: Yujie Liu <yujie.liu@intel.com>
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
Reviewed-and-tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240422082238.5784-1-xuewen.yan@unisoc.com

(cherry picked from commit 1560d1f6eb6b398bddd80c16676776c0325fe5fe)
Signed-off-by: John Cabaj <john.cabaj@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

lowlatency 2023-03-15 12:03:00 UTC
UBUNTU: Ubuntu-lowlatency-6.2.0-1001.1

Author: Paolo Pisati
Author Date: 2023-03-15 12:03:00 UTC

UBUNTU: Ubuntu-lowlatency-6.2.0-1001.1

Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>

134 of 34 results
This repository contains Public information 
Everyone can see this information.