PT-2024-11485 · Openeuler+1 · Kernel+111
Published
2024-05-24
·
Updated
2024-06-14
·
CVE-2021-47543
CVSS v3.1
5.5
Medium
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: cdc eem: fix tx fixup skb leak
when usbnet transmit a skb, eem fixup it in eem tx fixup(),
if skb copy expand() failed, it return NULL,
usbnet start xmit() will have no chance to free original skb.
fix it by free orginal skb in eem tx fixup() first,
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in gfs2 glock shrink scan
The GLF LRU flag is checked under lru lock in gfs2 glock remove from lru() to
remove the glock from the lru list in gfs2 glock put().
On the shrink scan path, the same flag is cleared under lru lock but because
of cond resched lock(&lru lock) in gfs2 dispose glock lru(), progress on the
put side can be made without deleting the glock from the lru list.
Keep GLF LRU across the race window opened by cond resched lock(&lru lock) to
ensure correct behavior on both sides - clear GLF LRU after list del under
lru lock.(CVE-2021-47254)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Decrease sock refcount when sock timers expire
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod timer() by sk reset timer(), and
del timer() by sk stop timer().
Function sk reset timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)
In the Linux kernel, the following vulnerability has been resolved:
memory: fsl ifc: fix leak of IO mapping on probe failure
On probe error the driver should unmap the IO memory. Smatch reports:
drivers/memory/fsl ifc.c:298 fsl ifc ctrl probe() warn: 'fsl ifc ctrl dev->gregs' not released on lines: 298.(CVE-2021-47315)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free in wdt startup()
This module's remove path calls del timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del timer sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.(CVE-2021-47324)
In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid sas: Fix resource leak in case of probe failure
The driver doesn't clean up all the allocated resources properly when
scsi add host(), megasas start aen() function fails during the PCI device
probe.
Clean up all those resources.(CVE-2021-47329)
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix module reference leak
A reference to the carrier module was taken on every open but was only
released once when the final reference to the tty struct was dropped.
Fix this by taking the module reference and initialising the tty driver
data when installing the tty.(CVE-2021-47403)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: check return value after calling platform get resource()
It will cause null-ptr-deref if platform get resource() returns NULL,
we need check the return value.(CVE-2021-47409)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix freeing of uninitialized misc IRQ vector
When VSI set up failed in i40e probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e clear interrupt scheme and produced a kernel Oops:
Trying to free already-free IRQ 266
WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 free irq+0x9a/0x300
Workqueue: events work for cpu fn
RIP: 0010: free irq+0x9a/0x300
Call Trace:
? synchronize irq+0x3a/0xa0
free irq+0x2e/0x60
i40e clear interrupt scheme+0x53/0x190 [i40e]
i40e probe.part.108+0x134b/0x1a40 [i40e]
? kmem cache alloc+0x158/0x1c0
? acpi ut update ref count.part.1+0x8e/0x345
? acpi ut update object reference+0x15e/0x1e2
? strstr+0x21/0x70
? irq get irq data+0xa/0x20
? mp check pin attr+0x13/0xc0
? irq get irq data+0xa/0x20
? mp map pin to irq+0xd3/0x2f0
? acpi register gsi ioapic+0x93/0x170
? pci conf1 read+0xa4/0x100
? pci bus read config word+0x49/0x70
? do pci enable device+0xcc/0x100
local pci probe+0x41/0x90
work for cpu fn+0x16/0x20
process one work+0x1a7/0x360
worker thread+0x1cf/0x390
? create worker+0x1a0/0x1a0
kthread+0x112/0x130
? kthread flush work fn+0x10/0x10
ret from fork+0x1f/0x40
The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.
Add a check in i40e clear interrupt scheme for I40E MISC IRQ REQUESTED
PF state before calling i40e free misc vector. This state is set only if
misc IRQ vectors were properly initialized.(CVE-2021-47424)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after conversion from inline format
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
block write full page()") uncovered a latent bug in ocfs2 conversion
from inline inode format to a normal inode format.
The code in ocfs2 convert inline data to extents() attempts to zero out
the whole cluster allocated for file data by grabbing, zeroing, and
dirtying all pages covering this cluster. However these pages are
beyond i size, thus writeback code generally ignores these dirty pages
and no blocks were ever actually zeroed on the disk.
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
pages past i size.") for standard ocfs2 write path, inline conversion
path was apparently forgotten; the commit log also has a reasoning why
the zeroing actually is not needed.
After commit 6dbf7bb55598, things became worse as writeback code stopped
invalidating buffers on pages beyond i size and thus these pages end up
with clean PageDirty bit but with buffers attached to these pages being
still dirty. So when a file is converted from inline format, then
writeback triggers, and then the file is grown so that these pages
become valid, the invalid dirtiness state is preserved,
mark buffer dirty() does nothing on these pages (buffers are already
dirty) but page is never written back because it is clean. So data
written to these pages is lost once pages are reclaimed.
Simple reproducer for the problem is:
xfs io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync"
-c "pwrite 4000 2000" ocfs2 file
After unmounting and mounting the fs again, you can observe that end of
'ocfs2 file' has lost its contents.
Fix the problem by not doing the pointless zeroing during conversion
from inline format similarly as in the standard write path.
In the Linux kernel, the following vulnerability has been resolved:
comedi: ni usb6501: fix NULL-deref in command paths
The driver uses endpoint-sized USB transfer buffers but had no sanity
checks on the sizes. This can lead to zero-size-pointer dereferences or
overflowed transfer buffers in ni6501 port command() and
ni6501 counter command() if a (malicious) device has smaller max-packet
sizes than expected (or when doing descriptor fuzz testing).
Add the missing sanity checks to probe().(CVE-2021-47476)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Fix out of bound access for corrupted isofs image
When isofs image is suitably corrupted isofs read inode() can read data
beyond the end of buffer. Sanity-check the directory entry length before
using it.(CVE-2021-47478)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix use-after-free in rtl8712 dl fw
Syzbot reported use-after-free in rtl8712 dl fw(). The problem was in
race condition between r871xu dev remove() ->ndo open() callback.
It's easy to see from crash log, that driver accesses released firmware
in ->ndo open() callback. It may happen, since driver was releasing
firmware before unregistering netdev. Fix it by moving
unregister netdev() before cleaning up resources.
Call Trace:
...
rtl871x open fw drivers/staging/rtl8712/hal init.c:83 [inline]
rtl8712 dl fw+0xd95/0xe10 drivers/staging/rtl8712/hal init.c:170
rtl8712 hal init drivers/staging/rtl8712/hal init.c:330 [inline]
rtl871x hal init+0xae/0x180 drivers/staging/rtl8712/hal init.c:394
netdev open+0xe6/0x6c0 drivers/staging/rtl8712/os intfs.c:380
dev open+0x2bc/0x4d0 net/core/dev.c:1484
Freed by task 1306:
...
release firmware+0x1b/0x30 drivers/base/firmware loader/main.c:1053
r871xu dev remove+0xcc/0x2c0 drivers/staging/rtl8712/usb intf.c:599
usb unbind interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)
In the Linux kernel, the following vulnerability has been resolved:
iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
When ACPI type is ACPI SMO8500, the data->dready trig will not be set, the
memory allocated by iio triggered buffer setup() will not be freed, and cause
memory leak as follows:
unreferenced object 0xffff888009551400 (size 512):
comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
hex dump (first 32 bytes):
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ .......
backtrace:
[<0000000041ce75ee>] kmem cache alloc trace+0x16d/0x360
[<000000000aeb17b0>] iio kfifo allocate+0x41/0x130 [kfifo buf]
[<000000004b40c1f5>] iio triggered buffer setup ext+0x2c/0x210 [industrialio triggered buffer]
[<000000004375b15f>] kxcjk1013 probe+0x10c3/0x1d81 [kxcjk 1013]
Fix it by remove data->dready trig condition in probe and remove.(CVE-2021-47499)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Fix negative period/buffer sizes
The period size calculation in OSS layer may receive a negative value
as an error, but the code there assumes only the positive values and
handle them with size t. Due to that, a too big value may be passed
to the lower layers.
This patch changes the code to handle with ssize t and adds the proper
error checks appropriately.(CVE-2021-47511)
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix potential NULL pointer deref in nfc genl dump ses done
The done() netlink callback nfc genl dump ses done() should check if
received argument is non-NULL, because its allocation could fail earlier
in dumpit() (nfc genl dump ses()).(CVE-2021-47518)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix rxrpc local leak in rxrpc lookup peer()
Need to call rxrpc put local() for peer candidate before kfree() as it
holds a ref to rxrpc local.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx4 en: Fix an use-after-free bug in mlx4 en try alloc resources()
In mlx4 en try alloc resources(), mlx4 en copy priv() is called and
tmp->tx cq will be freed on the error path of mlx4 en copy priv().
After that mlx4 en alloc resources() is called and there is a dereference
of &tmp->tx cq[t][i] in mlx4 en alloc resources(), which could lead to
a use after free problem on failure of mlx4 en copy priv().
Fix this bug by adding a check of mlx4 en copy priv()
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG MLX4 EN=m show no new warnings,
and our static analyzer no longer warns about this code.(CVE-2021-47541)
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic 83xx add rings()
In qlcnic 83xx add rings(), the indirect function of
ahw->hw ops->alloc mbx args will be called to allocate memory for
cmd.req.arg, and there is a dereference of it in qlcnic 83xx add rings(),
which could lead to a NULL pointer dereference on failure of the
indirect function like qlcnic 83xx alloc mbx args().
Fix this bug by adding a check of alloc mbx args(), this patch
imitates the logic of mbx cmd()'s failure handling.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG QLCNIC=m show no new warnings, and our
static analyzer no longer warns about this code.(CVE-2021-47542)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix page frag corruption on page fault
Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.
The root cause is quite similar to the one addressed by
commit 20eb4f29b602 ("net: fix sk page frag() recursion from
memory reclaim"). Here the nested access to the task page frag
is caused by a page fault on the (mmapped) user-space memory
buffer coming from the cifs file.
The page fault handler performs an smb transaction on a different
socket, inside the same process context. Since sk->sk allaction
for such socket does not prevent the usage for the task frag,
the nested allocation modify "under the hood" the page frag
in use by the outer sendmsg call, corrupting the stream.
The overall relevant stack trace looks like the following:
httpd 78268 [001] 3461630.850950: probe:tcp sendmsg locked:
ffffffff91461d91 tcp sendmsg locked+0x1
ffffffff91462b57 tcp sendmsg+0x27
ffffffff9139814e sock sendmsg+0x3e
ffffffffc06dfe1d smb send kvec+0x28
[...]
ffffffffc06cfaf8 cifs readpages+0x213
ffffffff90e83c4b read pages+0x6b
ffffffff90e83f31 do page cache readahead+0x1c1
ffffffff90e79e98 filemap fault+0x788
ffffffff90eb0458 do fault+0x38
ffffffff90eb5280 do fault+0x1a0
ffffffff90eb7c84 handle mm fault+0x4d4
ffffffff90eb8093 handle mm fault+0xc3
ffffffff90c74f6d do page fault+0x1ed
ffffffff90c75277 do page fault+0x37
ffffffff9160111e page fault+0x1e
ffffffff9109e7b5 copyin+0x25
ffffffff9109eb40 copy from iter full+0xe0
ffffffff91462370 tcp sendmsg locked+0x5e0
ffffffff91462370 tcp sendmsg locked+0x5e0
ffffffff91462b57 tcp sendmsg+0x27
ffffffff9139815c sock sendmsg+0x4c
ffffffff913981f7 sock write iter+0x97
ffffffff90f2cc56 do iter readv writev+0x156
ffffffff90f2dff0 do iter write+0x80
ffffffff90f2e1c3 vfs writev+0xa3
ffffffff90f2e27c do writev+0x5c
ffffffff90c042bb do syscall 64+0x5b
ffffffff916000ad entry SYSCALL 64 after hwframe+0x65
The cifs filesystem rightfully sets sk allocations to GFP NOFS,
we can avoid the nesting using the sk page frag for allocation
lacking the GFP FS flag. Do not define an additional mm-helper
for that, as this is strictly tied to the sk page frag usage.
v1 -> v2:
- use a stricted sk page frag() check instead of reordering the code (Eric)(CVE-2021-47544)
In the Linux kernel, the following vulnerability has been resolved:
net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the
'for' end, the 'k' is 8.
At this time, the array 'lp->phy[8]' may be out of bound.(CVE-2021-47547)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal event init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.(CVE-2023-52686)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS SB2 OFFSET BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes. Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
phys seg 1 prio class 2
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs resize fs(), passing a huge number
of segments to nilfs sufile resize(), corrupting parameters such as the
number of segments in superblocks. This causes excessive loop iterations
in nilfs sufile resize() during a subsequent resize ioctl, causing
semaphore ns segctor sem to block for a long time and hang the writer
thread:
INFO: task segctord:5067 blocked for more than 143 seconds.
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
"echo 0 > /proc/sys/kernel/hung task timeout secs" disables this message.
task:segctord state:D stack:23456 pid:5067 ppid:2
flags:0x00004000
Call Trace:
<TASK>
context switch kernel/sched/core.c:5293 [inline]
schedule+0x1409/0x43f0 kernel/sched/core.c:6606
schedule+0xc3/0x190 kernel/sched/core.c:6682
rwsem down write slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
nilfs transaction lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
nilfs segctor thread construct fs/nilfs2/segment.c:2486 [inline]
nilfs segctor thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
kthread+0x270/0x300 kernel/kthread.c:376
ret from fork+0x1f/0x30 arch/x86/entry/entry 64.S:308
</TASK>
...
Call Trace:
<TASK>
folio mark accessed+0x51c/0xf00 mm/swap.c:515
nilfs get page block fs/nilfs2/page.c:42 [inline]
nilfs grab buffer+0x3d3/0x540 fs/nilfs2/page.c:61
nilfs mdt submit block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
nilfs mdt read block+0xeb/0x430 fs/nilfs2/mdt.c:176
nilfs mdt get block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
nilfs sufile get segment usage block fs/nilfs2/sufile.c:92 [inline]
nilfs sufile truncate range fs/nilfs2/sufile.c:679 [inline]
nilfs sufile resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
nilfs resize fs+0x20c/0xed0 fs/nilfs2/super.c:422
nilfs ioctl resize fs/nilfs2/ioctl.c:1033 [inline]
nilfs ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
...
This fixes these issues by inserting appropriate minimum device size
checks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver. It's usually true, but it's still
possible that the first interface is bound with another driver via a
malformed descriptor. Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon context object although it's a completely different one
that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.(CVE-2023-52754)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd profile start() the amount of requests on the device queue are
counted. The access to the device queue is unprotected against
concurrent access. With a lot of parallel I/O, especially with alias
devices enabled, the device queue can change while dasd profile start()
is accessing the queue. In the worst case this leads to a kernel panic
due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and
counting the requests. Additionally the check for a valid profile data
pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
RPC client pipefs dentries cleanup is in separated rpc remove pipedir()
workqueue,which takes care about pipefs superblock locking.
In some special scenarios, when kernel frees the pipefs sb of the
current client and immediately alloctes a new pipefs sb,
rpc remove pipedir function would misjudge the existence of pipefs
sb which is not the one it used to hold. As a result,
the rpc remove pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc remove pipedir should check whether the
current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
[ 250.497700] BUG: KASAN: slab-use-after-free in dget parent+0x195/0x200
[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
[ 250.500549] Workqueue: events rpc free client work
[ 250.501001] Call Trace:
[ 250.502880] kasan report+0xb6/0xf0
[ 250.503209] ? dget parent+0x195/0x200
[ 250.503561] dget parent+0x195/0x200
[ 250.503897] ? pfx rpc clntdir depopulate+0x10/0x10
[ 250.504384] rpc rmdir depopulate+0x1b/0x90
[ 250.504781] rpc remove client dir+0xf5/0x150
[ 250.505195] rpc free client work+0xe4/0x230
[ 250.505598] process one work+0x8ee/0x13b0
...
[ 22.039056] Allocated by task 244:
[ 22.039390] kasan save stack+0x22/0x50
[ 22.039758] kasan set track+0x25/0x30
[ 22.040109] kasan slab alloc+0x59/0x70
[ 22.040487] kmem cache alloc lru+0xf0/0x240
[ 22.040889] d alloc+0x31/0x8e0
[ 22.041207] d alloc+0x44/0x1f0
[ 22.041514] rpc lookup create exclusive+0x11c/0x140
[ 22.041987] rpc mkdir populate.constprop.0+0x5f/0x110
[ 22.042459] rpc create client dir+0x34/0x150
[ 22.042874] rpc setup pipedir sb+0x102/0x1c0
[ 22.043284] rpc client register+0x136/0x4e0
[ 22.043689] rpc new client+0x911/0x1020
[ 22.044057] rpc create xprt+0xcb/0x370
[ 22.044417] rpc create+0x36b/0x6c0
...
[ 22.049524] Freed by task 0:
[ 22.049803] kasan save stack+0x22/0x50
[ 22.050165] kasan set track+0x25/0x30
[ 22.050520] kasan save free info+0x2b/0x50
[ 22.050921] kasan slab free+0x10e/0x1a0
[ 22.051306] kmem cache free+0xa5/0x390
[ 22.051667] rcu core+0x62c/0x1930
[ 22.051995] do softirq+0x165/0x52a
[ 22.052347]
[ 22.052503] Last potentially related work creation:
[ 22.052952] kasan save stack+0x22/0x50
[ 22.053313] kasan record aux stack+0x8e/0xa0
[ 22.053739] call rcu common.constprop.0+0x6b/0x8b0
[ 22.054209] dentry free+0xb2/0x140
[ 22.054540] dentry kill+0x3be/0x540
[ 22.054900] shrink dentry list+0x199/0x510
[ 22.055293] shrink dcache parent+0x190/0x240
[ 22.055703] do one tree+0x11/0x40
[ 22.056028] shrink dcache for umount+0x61/0x140
[ 22.056461] generic shutdown super+0x70/0x590
[ 22.056879] kill anon super+0x3a/0x60
[ 22.057234] rpc kill sb+0x121/0x200(CVE-2023-52803)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp->private data, which means that private data will not be NULL when
wmi char open() is called. This might cause memory corruption should
wmi char open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi free devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container of(). This
also avoids wmi char open() picking a wrong WMI device bound to a
driver with the same name as the original driver.(CVE-2023-52864)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk alloc clk data
Add the check for the return value of mtk alloc clk data() in order to
avoid NULL pointer dereference.(CVE-2023-52865)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even
a failed probe call would modify the global drv data pointer. So check
if drv data is valid before overwriting it.(CVE-2023-52871)
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys addr t:
drivers/firmware/efi/capsule-loader.c: In function 'efi capsule open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys addr t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
295 | cap info->phys = kzalloc(sizeof(void *), GFP KERNEL);
| ^
Use the correct type instead here.(CVE-2024-27413)
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime idle() callback and the .remove()
callback in the rtsx pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].
The problem is that rtsx pci runtime idle() is not expected to be running
after pm runtime get sync() has been called, but the latter doesn't really
guarantee that. It only guarantees that the suspend and resume callbacks
will not be running when it returns.
However, if a .runtime idle() callback is already running when
pm runtime get sync() is called, the latter will notice that the runtime PM
status of the device is RPM ACTIVE and it will return right away without
waiting for the former to complete. In fact, it cannot wait for
.runtime idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).
Thus in general, whoever is providing a .runtime idle() callback needs
to protect it from running in parallel with whatever code runs after
pm runtime get sync(). [Note that .runtime idle() will not start after
pm runtime get sync() has returned, but it may continue running then if it
has started earlier.]
One way to address that race condition is to call pm runtime barrier()
after pm runtime get sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime idle() callback to complete should
it be running at that point. A suitable place for doing that is in
pci device remove() which calls pm runtime get sync() before removing the
driver, so it may as well call pm runtime barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx pcr
driver, but in any PCI drivers providing .runtime idle() callbacks.(CVE-2024-35809)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf cfg80211 detach
This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:
->brcmf usb probe
->brcmf usb probe cb
->brcmf attach
->brcmf bus started
->brcmf cfg80211 attach
->wl init priv
->brcmf init escan
->INIT WORK(&cfg->escan timeout work,
brcmf cfg80211 escan timeout worker);
If we disconnect the USB by hotplug, it will call
brcmf usb disconnect to make cleanup. The invoking chain is :
brcmf usb disconnect
->brcmf usb disconnect cb
->brcmf detach
->brcmf cfg80211 detach
->kfree(cfg);
While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf cfg80211 escan timeout worker.
Fix it by deleting the timer and canceling the worker in
brcmf cfg80211 detach.
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan base hdr is present in skb->head
syzbot reported a problem in ip6erspan rcv() [1]
Issue is that ip6erspan rcv() (and erspan rcv()) no longer make
sure erspan base hdr is present in skb linear part (skb->head)
before getting @ver field from it.
Add the missing pskb may pull() calls.
v2: Reload iph pointer in erspan rcv() after pskb may pull()
because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb may pull reason include/linux/skbuff.h:2742 [inline]
BUG: KMSAN: uninit-value in pskb may pull include/linux/skbuff.h:2756 [inline]
BUG: KMSAN: uninit-value in ip6erspan rcv net/ipv6/ip6 gre.c:541 [inline]
BUG: KMSAN: uninit-value in gre rcv+0x11f8/0x1930 net/ipv6/ip6 gre.c:610
pskb may pull reason include/linux/skbuff.h:2742 [inline]
pskb may pull include/linux/skbuff.h:2756 [inline]
ip6erspan rcv net/ipv6/ip6 gre.c:541 [inline]
gre rcv+0x11f8/0x1930 net/ipv6/ip6 gre.c:610
ip6 protocol deliver rcu+0x1d4c/0x2ca0 net/ipv6/ip6 input.c:438
ip6 input finish net/ipv6/ip6 input.c:483 [inline]
NF HOOK include/linux/netfilter.h:314 [inline]
ip6 input+0x15d/0x430 net/ipv6/ip6 input.c:492
ip6 mc input+0xa7e/0xc80 net/ipv6/ip6 input.c:586
dst input include/net/dst.h:460 [inline]
ip6 rcv finish+0x955/0x970 net/ipv6/ip6 input.c:79
NF HOOK include/linux/netfilter.h:314 [inline]
ipv6 rcv+0xde/0x390 net/ipv6/ip6 input.c:310
netif receive skb one core net/core/dev.c:5538 [inline]
netif receive skb+0x1da/0xa00 net/core/dev.c:5652
netif receive skb internal net/core/dev.c:5738 [inline]
netif receive skb+0x58/0x660 net/core/dev.c:5798
tun rx batched+0x3ee/0x980 drivers/net/tun.c:1549
tun get user+0x5566/0x69e0 drivers/net/tun.c:2002
tun chr write iter+0x3af/0x5d0 drivers/net/tun.c:2048
call write iter include/linux/fs.h:2108 [inline]
new sync write fs/read write.c:497 [inline]
vfs write+0xb63/0x1520 fs/read write.c:590
ksys write+0x20f/0x4c0 fs/read write.c:643
do sys write fs/read write.c:655 [inline]
se sys write fs/read write.c:652 [inline]
x64 sys write+0x93/0xe0 fs/read write.c:652
do syscall 64+0xd5/0x1f0
entry SYSCALL 64 after hwframe+0x6d/0x75
Uninit was created at:
slab post alloc hook mm/slub.c:3804 [inline]
slab alloc node mm/slub.c:3845 [inline]
kmem cache alloc node+0x613/0xc50 mm/slub.c:3888
kmalloc reserve+0x13d/0x4a0 net/core/skbuff.c:577
alloc skb+0x35b/0x7a0 net/core/skbuff.c:668
alloc skb include/linux/skbuff.h:1318 [inline]
alloc skb with frags+0xc8/0xbf0 net/core/skbuff.c:6504
sock alloc send pskb+0xa81/0xbf0 net/core/sock.c:2795
tun alloc skb drivers/net/tun.c:1525 [inline]
tun get user+0x209a/0x69e0 drivers/net/tun.c:1846
tun chr write iter+0x3af/0x5d0 drivers/net/tun.c:2048
call write iter include/linux/fs.h:2108 [inline]
new sync write fs/read write.c:497 [inline]
vfs write+0xb63/0x1520 fs/read write.c:590
ksys write+0x20f/0x4c0 fs/read write.c:643
do sys write fs/read write.c:655 [inline]
se sys write fs/read write.c:652 [inline]
x64 sys write+0x93/0xe0 fs/read write.c:652
do syscall 64+0xd5/0x1f0
entry SYSCALL 64 after hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account
before copying data.
BUG: KASAN: slab-out-of-bounds in copy from sockptr offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy from sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in do replace net/ipv4/netfilter/ip tables.c:1111 [inline]
BUG: KASAN: slab-out-of-bounds in do ipt set ctl+0x902/0x3dd0 net/ipv4/netfilter/ip tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
dump stack lib/dump stack.c:88 [inline]
dump stack lvl+0x241/0x360 lib/dump stack.c:114
print address description mm/kasan/report.c:377 [inline]
print report+0x169/0x550 mm/kasan/report.c:488
kasan report+0x143/0x180 mm/kasan/report.c:601
kasan check range+0x282/0x290 mm/kasan/generic.c:189
asan memcpy+0x29/0x70 mm/kasan/shadow.c:105
copy from sockptr offset include/linux/sockptr.h:49 [inline]
copy from sockptr include/linux/sockptr.h:55 [inline]
do replace net/ipv4/netfilter/ip tables.c:1111 [inline]
do ipt set ctl+0x902/0x3dd0 net/ipv4/netfilter/ip tables.c:1627
nf setsockopt+0x295/0x2c0 net/netfilter/nf sockopt.c:101
do sock setsockopt+0x3af/0x720 net/socket.c:2311
sys setsockopt+0x1ae/0x250 net/socket.c:2334
do sys setsockopt net/socket.c:2343 [inline]
se sys setsockopt net/socket.c:2340 [inline]
x64 sys setsockopt+0xb5/0xd0 net/socket.c:2340
do syscall 64+0xfb/0x240
entry SYSCALL 64 after hwframe+0x72/0x7a
RIP: 0033:0x7fd22067dde9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
</TASK>
Allocated by task 7238:
kasan save stack mm/kasan/common.c:47 [inline]
kasan save track+0x3f/0x80 mm/kasan/common.c:68
poison kmalloc redzone mm/kasan/common.c:370 [inline]
kasan kmalloc+0x98/0xb0 mm/kasan/common.c:387
kasan kmalloc include/linux/kasan.h:211 [inline]
do kmalloc node mm/slub.c:4069 [inline]
kmalloc noprof+0x200/0x410 mm/slub.c:4082
kmalloc noprof include/linux/slab.h:664 [inline]
cgroup bpf run filter setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
do sock setsockopt+0x6b4/0x720 net/socket.c:2293
sys setsockopt+0x1ae/0x250 net/socket.c:2334
do sys setsockopt net/socket.c:2343 [inline]
se sys setsockopt net/socket.c:2340 [inline]
x64 sys setsockopt+0xb5/0xd0 net/socket.c:2340
do syscall 64+0xfb/0x240
entry SYSCALL 64 after hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
---truncated---(CVE-2024-35896)
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
i2c transfer.
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA VF VLAN LIST attribute validation
Each attribute inside a nested IFLA VF VLAN LIST is assumed to be a
struct ifla vf vlan info so the size of such attribute needs to be at least
of sizeof(struct ifla vf vlan info) which is 14 bytes.
The current size validation in do setvfinfo is against NLA HDRLEN (4 bytes)
which is less than sizeof(struct ifla vf vlan info) so this validation
is not enough and a too small attribute might be cast to a
struct ifla vf vlan info, this might result in an out of bands
read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.(CVE-2024-36029)
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops init
net alloc generic is called by net alloc, which is called without any
locking. It reads max gen ptrs, which is changed under pernet ops rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max gen ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.
Fix it by reading max gen ptrs only once in net alloc generic. If
max gen ptrs is later incremented, it will be caught in net assign generic.(CVE-2024-36883)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6 rules: avoid possible NULL dereference in fib6 rule action()
syzbot is able to trigger the following crash [1],
caused by unsafe ip6 dst idev() use.
Indeed ip6 dst idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010: fib6 rule action net/ipv6/fib6 rules.c:237 [inline]
RIP: 0010:fib6 rule action+0x241/0x7b0 net/ipv6/fib6 rules.c:267
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
fib rules lookup+0x62c/0xdb0 net/core/fib rules.c:317
fib6 rule lookup+0x1fd/0x790 net/ipv6/fib6 rules.c:108
ip6 route output flags noref net/ipv6/route.c:2637 [inline]
ip6 route output flags+0x38e/0x610 net/ipv6/route.c:2649
ip6 route output include/net/ip6 route.h:93 [inline]
ip6 dst lookup tail+0x189/0x11a0 net/ipv6/ip6 output.c:1120
ip6 dst lookup flow+0xb9/0x180 net/ipv6/ip6 output.c:1250
sctp v6 get dst+0x792/0x1e20 net/sctp/ipv6.c:326
sctp transport route+0x12c/0x2e0 net/sctp/transport.c:455
sctp assoc add peer+0x614/0x15c0 net/sctp/associola.c:662
sctp connect new asoc+0x31d/0x6c0 net/sctp/socket.c:1099
sctp connect+0x66d/0xe30 net/sctp/socket.c:1197
sctp connect net/sctp/socket.c:4819 [inline]
sctp inet connect+0x149/0x1f0 net/sctp/socket.c:4834
sys connect file net/socket.c:2048 [inline]
sys connect+0x2df/0x310 net/socket.c:2065
do sys connect net/socket.c:2075 [inline]
se sys connect net/socket.c:2072 [inline]
x64 sys connect+0x7a/0x90 net/socket.c:2072
do syscall x64 arch/x86/entry/common.c:52 [inline]
do syscall 64+0xf5/0x240 arch/x86/entry/common.c:83
entry SYSCALL 64 after hwframe+0x77/0x7f(CVE-2024-36902)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix potential uninit-value access in ip6 make skb()
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
ip make skb()") for IPv4, check FLOWI FLAG KNOWN NH on fl6->flowi6 flags
instead of testing HDRINCL on the socket to avoid a race condition which
causes uninit-value access.(CVE-2024-36903)
In the Linux kernel, the following vulnerability has been resolved:
block: fix overflow in blk ioctl discard()
There is no check for overflow of 'start + len' in blk ioctl discard().
Hung task occurs if submit an discard ioctl with the following param:
start = 0x80000000000ff000, len = 0x8000000000fff000;
Add the overflow validation now.(CVE-2024-36917)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc worker wake up()
lpfc worker wake up() calls the lpfc work done() routine, which takes the
hbalock. Thus, lpfc worker wake up() should not be called while holding the
hbalock to avoid potential deadlock.(CVE-2024-36924)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc buf append
skb linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after skb linearize(), so that the skb can be
freed on the err path.(CVE-2024-36954)
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it
to be able to set (among others) the suid bit. This was presumably not
the intent since the unix extended bits are handled explicitly and
conditionally on .u.(CVE-2024-36964)
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Kernel
Linux
Linux-Allwinner-5.19
Linux-Aws
Linux-Aws-5.0
Linux-Aws-5.11
Linux-Aws-5.13
Linux-Aws-5.15
Linux-Aws-5.19
Linux-Aws-5.3
Linux-Aws-5.4
Linux-Aws-5.8
Linux-Aws-6.2
Linux-Aws-6.5
Linux-Aws-Fips
Linux-Aws-Hwe
Linux-Azure
Linux-Azure-4.15
Linux-Azure-5.11
Linux-Azure-5.13
Linux-Azure-5.15
Linux-Azure-5.19
Linux-Azure-5.3
Linux-Azure-5.4
Linux-Azure-5.8
Linux-Azure-6.2
Linux-Azure-6.5
Linux-Azure-Edge
Linux-Azure-Fde
Linux-Azure-Fde-5.15
Linux-Azure-Fde-5.19
Linux-Azure-Fde-6.2
Linux-Azure-Fips
Linux-Bluefield
Linux-Fips
Linux-Gcp
Linux-Gcp-4.15
Linux-Gcp-5.11
Linux-Gcp-5.13
Linux-Gcp-5.15
Linux-Gcp-5.19
Linux-Gcp-5.3
Linux-Gcp-5.4
Linux-Gcp-5.8
Linux-Gcp-6.2
Linux-Gcp-6.5
Linux-Gcp-Fips
Linux-Gke
Linux-Gke-4.15
Linux-Gkeop-5.15
Linux-Gke-5.4
Linux-Gkeop
Linux-Hwe
Linux-Hwe-5.11
Linux-Hwe-5.13
Linux-Hwe-5.15
Linux-Hwe-5.19
Linux-Hwe-5.4
Linux-Hwe-5.8
Linux-Hwe-6.2
Linux-Hwe-6.5
Linux-Hwe-Edge
Linux-Ibm
Linux-Ibm-5.15
Linux-Ibm-5.4
Linux-Intel
Linux-Intel-5.13
Linux-Intel-Iotg
Linux-Intel-Iotg-5.15
Linux-Iot
Linux-Kvm
Linux-Lowlatency
Linux-Lowlatency-Hwe-5.15
Linux-Lowlatency-Hwe-5.19
Linux-Lowlatency-Hwe-6.2
Linux-Lowlatency-Hwe-6.5
Linux-Lts-Xenial
Linux-Nvidia
Linux-Nvidia-6.2
Linux-Nvidia-6.5
Linux-Oem
Linux-Oem-5.10
Linux-Oem-5.13
Linux-Oem-5.14
Linux-Oem-5.17
Linux-Oem-5.6
Linux-Oem-6.0
Linux-Oem-6.1
Linux-Oem-6.5
Linux-Oem-6.8
Linux-Oracle
Linux-Oracle-5.0
Linux-Oracle-5.11
Linux-Oracle-5.13
Linux-Oracle-5.15
Linux-Oracle-5.3
Linux-Oracle-5.4
Linux-Oracle-5.8
Linux-Oracle-6.5
Linux-Raspi
Linux-Raspi-5.4
Linux-Raspi2
Linux-Riscv
Linux-Riscv-5.11
Linux-Riscv-5.15
Linux-Riscv-5.19
Linux-Riscv-5.8
Linux-Riscv-6.5
Linux-Starfive-5.19
Linux-Starfive-6.2
Linux-Starfive-6.5
Linux-Xilinx-Zynqmp