The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unusevma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pudclearbad is called by pudnoneorclearbad in unusepudrange() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unusevma to fix it.(CVE-2024-50199)
In the Linux kernel, the following vulnerability has been resolved: ubifs: authentication: Fix use-after-free in ubifstncendcommit After an insertion in TNC, the tree might split and cause a node to change its znode->parent
. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's znode->cparent
could still point to a freed node. This znode->cparent
may not be updated when getting nodes to commit in ubifs_tnc_start_commit()
. This could then trigger a use-after-free when accessing the znode->cparent
in write_index()
in ubifs_tnc_end_commit()
. This can be triggered by running rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync in a loop, and with CONFIG_UBIFS_FS_AUTHENTICATION
. KASAN then reports: BUG: KASAN: use-after-free in ubifstncendcommit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifsbgt020/153 Call trace: dumpbacktrace+0x0/0x340 showstack+0x18/0x24 dumpstacklvl+0x9c/0xbc printaddressdescription.constprop.0+0x74/0x2b0 kasanreport+0x1d8/0x1f0 kasancheckrange+0xf8/0x1a0 memcpy+0x84/0xf4 ubifstncendcommit+0xa5c/0x1950 docommit+0x4e0/0x1340 ubifsbgthread+0x234/0x2e0 kthread+0x36c/0x410 retfromfork+0x10/0x20 Allocated by task 401: kasansavestack+0x38/0x70 _kasankmalloc+0x8c/0xd0 _kmalloc+0x34c/0x5bc tncinsert+0x140/0x16a4 ubifstncadd+0x370/0x52c ubifsjnlwritedata+0x5d8/0x870 dowritepage+0x36c/0x510 ubifswritepage+0x190/0x4dc _writepage+0x58/0x154 writecachepages+0x394/0x830 dowritepages+0x1f0/0x5b0 filemapfdatawritewbc+0x170/0x25c filewriteandwaitrange+0x140/0x190 ubifsfsync+0xe8/0x290 vfsfsyncrange+0xc0/0x1e4 dofsync+0x40/0x90 _arm64sysfsync+0x34/0x50 invokesyscall.constprop.0+0xa8/0x260 doel0svc+0xc8/0x1f0 el0svc+0x34/0x70 el0t64synchandler+0x108/0x114 el0t64sync+0x1a4/0x1a8 Freed by task 403: kasansavestack+0x38/0x70 kasansettrack+0x28/0x40 kasansetfreeinfo+0x28/0x4c _kasanslabfree+0xd4/0x13c kfree+0xc4/0x3a0 tncdelete+0x3f4/0xe40 ubifstncremoverange+0x368/0x73c ubifstncremoveino+0x29c/0x2e0 ubifsjnldeleteinode+0x150/0x260 ubifsevictinode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 dounlinkat+0x2cc/0x490 _arm64sysunlinkat+0x90/0x100 invokesyscall.constprop.0+0xa8/0x260 doel0svc+0xc8/0x1f0 el0svc+0x34/0x70 el0t64synchandler+0x108/0x114 el0t64sync+0x1a4/0x1a8 The offending memcpy()
in ubifs_copy_hash()
has a use-after-free when a node becomes root in TNC but still has a cparent
to an already freed node. More specifically, consider the following TNC: zroot / / zp1 / / zn Inserting a new node zn_new
with a key smaller then zn
will trigger a split in tnc_insert()
if zp1
is full: zroot / \ / \ zp1 zp2 / \ / \ znnew zn zn->parent
has now been moved to zp2
, but zn->cparent
still points to zp1
. Now, consider a removal of all the nodes except zn
. Just when tnc_delete()
is about to delete zroot
and zp2
: zroot \ \ zp2 \ \ zn zroot
and zp2
get freed and the tree collapses: zn zn
now becomes the new zroot
. get_znodes_to_commit()
will now only find zn
, the new zroot
, and write_index()
will check its znode->cparent
that wrongly points to the already freed zp1
. ubifs_copy_hash()
thus gets wrongly called with znode->cparent->zbranch[znode->iip].hash
that triggers the use-after-free! Fix this by explicitly setting znode->cparent
to NULL
in get_znodes_to_commit()
for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures Syzkaller reported a hung task with ueventshow() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummyhcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function readefuse() calls readefusebyte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside readefusebyte() alone, and in this reproducer (which involves the dummyhcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usbhubwq hubevent Call Trace: _schedule+0xe22/0xeb6 scheduletimeout+0xe7/0x132 _waitforcommon+0xb5/0x12e usbstartwaiturb+0xc5/0x1ef ? usballocurb+0x95/0xa4 usbcontrolmsg+0xff/0x184 _usbctrlvendorreqsync+0xa0/0x161 _usbreadsync+0xb3/0xc5 readefusebyte+0x13c/0x146 readefuse+0x351/0x5f0 efusereadallmap+0x42/0x52 rtlefuseshadowmapupdate+0x60/0xef rtlgethwinfo+0x5d/0x1c2 rtl92cureadeeprominfo+0x10a/0x8d5 ? rtl92creadchipversion+0x14f/0x17e rtlusbprobe+0x323/0x851 usbprobeinterface+0x278/0x34b reallyprobe+0x202/0x4a4 _driverprobedevice+0x166/0x1b2 driverprobedevice+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix ueventshow() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.(CVE-2024-53190)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix use-after-free in deviceforeachchild() Syzbot has reported the following KASAN splat: BUG: KASAN: slab-use-after-free in deviceforeachchild+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x100/0x190 ? deviceforeachchild+0x18f/0x1a0 printreport+0x13a/0x4cb ? _virtaddrvalid+0x5e/0x590 ? _physaddr+0xc6/0x150 ? deviceforeachchild+0x18f/0x1a0 kasanreport+0xda/0x110 ? deviceforeachchild+0x18f/0x1a0 ? _pfxdevmemallocnoio+0x10/0x10 deviceforeachchild+0x18f/0x1a0 ? _pfxdeviceforeachchild+0x10/0x10 pmruntimesetmemallocnoio+0xf2/0x180 netdevunregisterkobject+0x1ed/0x270 unregisternetdevicemanynotify+0x123c/0x1d80 ? _mutextrylockcommon+0xde/0x250 ? _pfxunregisternetdevicemanynotify+0x10/0x10 ? tracecontentionend+0xe6/0x140 ? _mutexlock+0x4e7/0x8f0 ? _pfxlockacquire.part.0+0x10/0x10 ? rcuiswatching+0x12/0xc0 ? unregisternetdev+0x12/0x30 unregisternetdevicequeue+0x30d/0x3f0 ? _pfxunregisternetdevicequeue+0x10/0x10 ? _pfxdownwrite+0x10/0x10 unregisternetdev+0x1c/0x30 bnepsession+0x1fb3/0x2ab0 ? _pfxbnepsession+0x10/0x10 ? _pfxlockrelease+0x10/0x10 ? _pfxwokenwakefunction+0x10/0x10 ? _kthreadparkme+0x132/0x200 ? _pfxbnepsession+0x10/0x10 ? kthread+0x13a/0x370 ? _pfxbnepsession+0x10/0x10 kthread+0x2b7/0x370 ? _pfxkthread+0x10/0x10 retfromfork+0x48/0x80 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Allocated by task 4974: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 _kmallocnoprof+0x1d1/0x440 hciallocdevpriv+0x1d/0x2820 _vhcicreatedevice+0xef/0x7d0 vhciwrite+0x2c7/0x480 vfswrite+0x6a0/0xfc0 ksyswrite+0x12f/0x260 dosyscall64+0xc7/0x250 entrySYSCALL64afterhwframe+0x77/0x7f Freed by task 4979: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x4f/0x70 kfree+0x141/0x490 hcireleasedev+0x4d9/0x600 bthostrelease+0x6a/0xb0 devicerelease+0xa4/0x240 kobjectput+0x1ec/0x5a0 putdevice+0x1f/0x30 vhcirelease+0x81/0xf0 _fput+0x3f6/0xb30 taskworkrun+0x151/0x250 doexit+0xa79/0x2c30 dogroupexit+0xd5/0x2a0 getsignal+0x1fcd/0x2210 archdosignalorrestart+0x93/0x780 syscallexittousermode+0x140/0x290 dosyscall64+0xd4/0x250 entrySYSCALL64afterhwframe+0x77/0x7f In 'hciconndelsysfs()', 'device_unregister()' may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)
In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6firechipabort(). But at this moment, the card object might be still in use (as we're calling sndcardfreewhenclosed()). For avoid potential UAFs, move the release of resources to the card's privatefree instead of the manual call of usb6firechip_destroy() at the USB disconnect callback.(CVE-2024-53239)
In the Linux kernel, the following vulnerability has been resolved: ad7780: fix division by zero in ad7780writeraw() In the ad7780writeraw() , val2 can be zero, which might lead to a division by zero error in DIVROUNDCLOSEST(). The ad7780writeraw() is based on iioinfo's writeraw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)
In the Linux kernel, the following vulnerability has been resolved: jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out.(CVE-2024-56595)
In the Linux kernel, the following vulnerability has been resolved: jfs: fix shift-out-of-bounds in dbSplit When dmt_budmin is less than zero, it causes errors in the later stages. Added a check to return an error beforehand in dbAllocCtl itself.(CVE-2024-56597)
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read in sgrelease() Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 _mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp. After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)
In the Linux kernel, the following vulnerability has been resolved: tcpbpf: Fix the skmemuncharge logic in tcpbpfsendmsg The current sk memory accounting logic in _SKREDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value applybytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to applybytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - applybytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->applybytes && psock->applybytes < tosend) 417 tosend = psock->applybytes; [...] 443 skmsgreturn(sk, msg, tosend); 444 releasesock(sk); 446 origsize = msg->sg.size; 447 ret = tcpbpfsendmsgredir(skredir, rediringress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 locksock(sk); 455 if (unlikely(ret < 0)) { 456 int free = skmsgfreenocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == _SKREDIRECT) 488 skmemcharge(sk, tosend - sent); [...] When running the selftest testtxmsgredirwaitsndmem with txmsgapply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/afinet.c:156 inetsockdestruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events skpsockdestroy RIP: 0010:inetsockdestruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _warn+0x89/0x130 ? inetsockdestruct+0x190/0x1a0 ? reportbug+0xfc/0x1e0 ? handlebug+0x5c/0xa0 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x190/0x1a0 _skdestruct+0x25/0x220 skpsockdestroy+0x2b2/0x310 processscheduledworks+0xa3/0x3e0 workerthread+0x117/0x240 ? _pfxworkerthread+0x10/0x10 kthread+0xcf/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x40 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- In _SKREDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke skmsgfree. Same thing happens in case _SKDROP, when tosend is set to applybytes, we may miss uncharging (msg->sg.size - applybytes) bytes. The same warning will be reported in selftest. [...] 468 case _SKDROP: 469 default: 470 skmsgfreepartial(sk, msg, tosend); 471 skmsgapplybytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of skmsgfreepartial we can do skmsg_free here.(CVE-2024-56633)
In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: vmalloc-out-of-bounds Read in acpinfitctl Fix an issue detected by syzbot with KASAN: BUG: KASAN: vmalloc-out-of-bounds in cmdtofunc drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpinfitctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 The issue occurs in cmdtofunc when the callpkg->ndreserved2 array is accessed without verifying that callpkg points to a buffer that is appropriately sized as a struct ndcmdpkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space. To address this, a check was added in acpinfitctl() to ensure that buf is not NULL and that buflen is less than sizeof(*callpkg) before accessing it. This ensures safe access to the members of callpkg, including the nd_reserved2 array.(CVE-2024-56662)
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix dtlaccesslock to be a rwsemaphore The dtlaccesslock needs to be a rwsempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatchstats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 199, name: sh preemptcount: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sbwriters#3){.+.+}-{0:0}, at: vfswrite+0x324/0x438 #1: c0000000028c7058 (dtlenablemutex){+.+.}-{3:3}, at: vcpudispatchstatswrite+0xd4/0x5f4 #2: c0000000028c70b8 (dtlaccesslock){+.+.}-{2:2}, at: vcpudispatchstatswrite+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dumpstacklvl+0x130/0x148 (unreliable) _mightresched+0x174/0x410 kmemcacheallocnoprof+0x340/0x3d0 allocdtlbuffers+0x124/0x1ac vcpudispatchstatswrite+0x2a8/0x5f4 procregwrite+0xf4/0x150 vfswrite+0xfc/0x438 ksyswrite+0x88/0x148 systemcallexception+0x1c4/0x5a0 systemcallcommon+0xf4/0x258(CVE-2024-56701)
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when COWing tree bock and tracing is enabled When a COWing a tree block, at btrfscowblock(), and we have the tracepoint tracebtrfscowblock() enabled and preemption is also enabled (CONFIGPREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfscowblock(), such as btrfssearchslot(), we are holding the last reference on the extent buffer @buf so btrfsforcecowblock() drops the last reference on the @buf extent buffer when it calls freeextentbufferstale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling tracebtrfscowblock() and the extent buffer already released by the time tracebtrfscowblock() is called, resulting in a use-after-free. Fix this by moving the tracebtrfscowblock() from btrfscowblock() to btrfsforcecowblock() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfsreallocnode(), since btrfsforcecow_block() is called there, but this is fine and it was actually missing there.(CVE-2024-56759)
{ "severity": "High" }
{ "src": [ "kernel-5.10.0-246.0.0.145.oe2203sp4.src.rpm" ], "x86_64": [ "bpftool-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-headers-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-source-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-tools-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "python3-perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm", "python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm" ], "aarch64": [ "bpftool-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-headers-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-source-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-tools-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "python3-perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm", "python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm" ] }