3794 lines
158 KiB
XML
3794 lines
158 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1836</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-12</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-12</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-12</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-12</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: lgdt3306a: Add a check against null-pointer-def
|
|
|
|
The driver should check whether the client provides the platform_data.
|
|
|
|
The following log reveals it:
|
|
|
|
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
|
|
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
|
|
[ 29.612820] Call Trace:
|
|
[ 29.613030] <TASK>
|
|
[ 29.613201] dump_stack_lvl+0x56/0x6f
|
|
[ 29.613496] ? kmemdup+0x30/0x40
|
|
[ 29.613754] print_report.cold+0x494/0x6b7
|
|
[ 29.614082] ? kmemdup+0x30/0x40
|
|
[ 29.614340] kasan_report+0x8a/0x190
|
|
[ 29.614628] ? kmemdup+0x30/0x40
|
|
[ 29.614888] kasan_check_range+0x14d/0x1d0
|
|
[ 29.615213] memcpy+0x20/0x60
|
|
[ 29.615454] kmemdup+0x30/0x40
|
|
[ 29.615700] lgdt3306a_probe+0x52/0x310
|
|
[ 29.616339] i2c_device_probe+0x951/0xa90(CVE-2022-48772)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tls: fix missing memory barrier in tls_init
|
|
|
|
In tls_init(), a write memory barrier is missing, and store-store
|
|
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.
|
|
|
|
CPU0 CPU1
|
|
----- -----
|
|
// In tls_init()
|
|
// In tls_ctx_create()
|
|
ctx = kzalloc()
|
|
ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)
|
|
|
|
// In update_sk_prot()
|
|
WRITE_ONCE(sk->sk_prot, tls_prots) -(2)
|
|
|
|
// In sock_common_setsockopt()
|
|
READ_ONCE(sk->sk_prot)->setsockopt()
|
|
|
|
// In tls_{setsockopt,getsockopt}()
|
|
ctx->sk_proto->setsockopt() -(3)
|
|
|
|
In the above scenario, when (1) and (2) are reordered, (3) can observe
|
|
the NULL value of ctx->sk_proto, causing NULL dereference.
|
|
|
|
To fix it, we rely on rcu_assign_pointer() which implies the release
|
|
barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is
|
|
initialized, we can ensure that ctx->sk_proto are visible when
|
|
changing sk->sk_prot.(CVE-2024-36489)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.(CVE-2024-36949)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
|
|
|
|
There are cases after NPIV deletion where the fabric switch still believes
|
|
the NPIV is logged into the fabric. This occurs when a vport is
|
|
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
|
|
fabric.
|
|
|
|
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
|
|
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
|
|
object. This sometimes causes the race condition where the final DA_ID and
|
|
LOGO are skipped from being sent to the fabric switch.
|
|
|
|
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
|
|
and LOGO are sent.(CVE-2024-36952)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs
|
|
|
|
Currently the driver uses local_bh_disable()/local_bh_enable() in its
|
|
IRQ handler to avoid triggering net_rx_action() softirq on exit from
|
|
netif_rx(). The net_rx_action() could trigger this driver .start_xmit
|
|
callback, which is protected by the same lock as the IRQ handler, so
|
|
calling the .start_xmit from netif_rx() from the IRQ handler critical
|
|
section protected by the lock could lead to an attempt to claim the
|
|
already claimed lock, and a hang.
|
|
|
|
The local_bh_disable()/local_bh_enable() approach works only in case
|
|
the IRQ handler is protected by a spinlock, but does not work if the
|
|
IRQ handler is protected by mutex, i.e. this works for KS8851 with
|
|
Parallel bus interface, but not for KS8851 with SPI bus interface.
|
|
|
|
Remove the BH manipulation and instead of calling netif_rx() inside
|
|
the IRQ handler code protected by the lock, queue all the received
|
|
SKBs in the IRQ handler into a queue first, and once the IRQ handler
|
|
exits the critical section protected by the lock, dequeue all the
|
|
queued SKBs and push them all into netif_rx(). At this point, it is
|
|
safe to trigger the net_rx_action() softirq, since the netif_rx()
|
|
call is outside of the lock that protects the IRQ handler.(CVE-2024-36962)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
|
|
|
|
The IPI buffer location is read from the firmware that we load to the
|
|
System Companion Processor, and it's not granted that both the SRAM
|
|
(L2TCM) size that is defined in the devicetree node is large enough
|
|
for that, and while this is especially true for multi-core SCP, it's
|
|
still useful to check on single-core variants as well.
|
|
|
|
Failing to perform this check may make this driver perform R/W
|
|
operations out of the L2TCM boundary, resulting (at best) in a
|
|
kernel panic.
|
|
|
|
To fix that, check that the IPI buffer fits, otherwise return a
|
|
failure and refuse to boot the relevant SCP core (or the SCP at
|
|
all, if this is single core).(CVE-2024-36965)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
|
|
|
|
When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
|
|
present in the list, free_irq() is called for the same vector. That
|
|
causes following splat:
|
|
|
|
[ 0.414355] Trying to free already-free IRQ 27
|
|
[ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
|
|
[ 0.414510] Modules linked in:
|
|
[ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
|
|
[ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
[ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
|
|
[ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
|
|
[ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
|
|
[ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
|
|
[ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
|
|
[ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
|
|
[ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
|
|
[ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
|
|
[ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
|
|
[ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
|
|
[ 0.414540] Call Trace:
|
|
[ 0.414540] <TASK>
|
|
[ 0.414540] ? __warn+0x80/0x120
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] ? report_bug+0x164/0x190
|
|
[ 0.414540] ? handle_bug+0x3b/0x70
|
|
[ 0.414540] ? exc_invalid_op+0x17/0x70
|
|
[ 0.414540] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] vp_del_vqs+0xc1/0x220
|
|
[ 0.414540] vp_find_vqs_msix+0x305/0x470
|
|
[ 0.414540] vp_find_vqs+0x3e/0x1a0
|
|
[ 0.414540] vp_modern_find_vqs+0x1b/0x70
|
|
[ 0.414540] init_vqs+0x387/0x600
|
|
[ 0.414540] virtnet_probe+0x50a/0xc80
|
|
[ 0.414540] virtio_dev_probe+0x1e0/0x2b0
|
|
[ 0.414540] really_probe+0xc0/0x2c0
|
|
[ 0.414540] ? __pfx___driver_attach+0x10/0x10
|
|
[ 0.414540] __driver_probe_device+0x73/0x120
|
|
[ 0.414540] driver_probe_device+0x1f/0xe0
|
|
[ 0.414540] __driver_attach+0x88/0x180
|
|
[ 0.414540] bus_for_each_dev+0x85/0xd0
|
|
[ 0.414540] bus_add_driver+0xec/0x1f0
|
|
[ 0.414540] driver_register+0x59/0x100
|
|
[ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10
|
|
[ 0.414540] virtio_net_driver_init+0x90/0xb0
|
|
[ 0.414540] do_one_initcall+0x58/0x230
|
|
[ 0.414540] kernel_init_freeable+0x1a3/0x2d0
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] kernel_init+0x1a/0x1c0
|
|
[ 0.414540] ret_from_fork+0x31/0x50
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] ret_from_fork_asm+0x1a/0x30
|
|
[ 0.414540] </TASK>
|
|
|
|
Fix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix crash on racing fsync and size-extending write into prealloc
|
|
|
|
We have been seeing crashes on duplicate keys in
|
|
btrfs_set_item_key_safe():
|
|
|
|
BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/ctree.c:2620!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
|
|
RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
|
|
|
|
With the following stack trace:
|
|
|
|
#0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
|
|
#1 btrfs_drop_extents (fs/btrfs/file.c:411:4)
|
|
#2 log_one_extent (fs/btrfs/tree-log.c:4732:9)
|
|
#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
|
|
#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
|
|
#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
|
|
#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
|
|
#7 btrfs_sync_file (fs/btrfs/file.c:1933:8)
|
|
#8 vfs_fsync_range (fs/sync.c:188:9)
|
|
#9 vfs_fsync (fs/sync.c:202:9)
|
|
#10 do_fsync (fs/sync.c:212:9)
|
|
#11 __do_sys_fdatasync (fs/sync.c:225:9)
|
|
#12 __se_sys_fdatasync (fs/sync.c:223:1)
|
|
#13 __x64_sys_fdatasync (fs/sync.c:223:1)
|
|
#14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
|
|
#15 do_syscall_64 (arch/x86/entry/common.c:83:7)
|
|
#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
|
|
|
|
So we're logging a changed extent from fsync, which is splitting an
|
|
extent in the log tree. But this split part already exists in the tree,
|
|
triggering the BUG().
|
|
|
|
This is the state of the log tree at the time of the crash, dumped with
|
|
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
|
|
to get more details than btrfs_print_leaf() gives us:
|
|
|
|
>>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
|
|
leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
|
|
leaf 33439744 flags 0x100000000000000
|
|
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
|
|
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
|
|
item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
|
|
generation 7 transid 9 size 8192 nbytes 8473563889606862198
|
|
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
|
|
sequence 204 flags 0x10(PREALLOC)
|
|
atime 1716417703.220000000 (2024-05-22 15:41:43)
|
|
ctime 1716417704.983333333 (2024-05-22 15:41:44)
|
|
mtime 1716417704.983333333 (2024-05-22 15:41:44)
|
|
otime 17592186044416.000000000 (559444-03-08 01:40:16)
|
|
item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
|
|
index 195 namelen 3 name: 193
|
|
item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
|
|
location key (0 UNKNOWN.0 0) type XATTR
|
|
transid 7 data_len 1 name_len 6
|
|
name: user.a
|
|
data a
|
|
item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
|
|
generation 9 type 1 (regular)
|
|
extent data disk byte 303144960 nr 12288
|
|
extent data offset 0 nr 4096 ram 12288
|
|
extent compression 0 (none)
|
|
item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
|
|
generation 9 type 2 (prealloc)
|
|
prealloc data disk byte 303144960 nr 12288
|
|
prealloc data offset 4096 nr 8192
|
|
item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
|
|
generation 9 type 2 (prealloc)
|
|
prealloc data disk byte 303144960 nr 12288
|
|
prealloc data offset 8192 nr 4096
|
|
...
|
|
|
|
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
|
|
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
|
|
item 5 starts at i_size.
|
|
|
|
Here is the state of
|
|
---truncated---(CVE-2024-37354)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK>(CVE-2024-37356)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: mediatek: Assign dummy when codec not specified for a DAI link
|
|
|
|
MediaTek sound card drivers are checking whether a DAI link is present
|
|
and used on a board to assign the correct parameters and this is done
|
|
by checking the codec DAI names at probe time.
|
|
|
|
If no real codec is present, assign the dummy codec to the DAI link
|
|
to avoid NULL pointer during string comparison.(CVE-2024-38551)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix potential index out of bounds in color transformation function
|
|
|
|
Fixes index out of bounds issue in the color transformation function.
|
|
The issue could occur when the index 'i' exceeds the number of transfer
|
|
function points (TRANSFER_FUNC_POINTS).
|
|
|
|
The fix adds a check to ensure 'i' is within bounds before accessing the
|
|
transfer function points. If 'i' is out of bounds, an error message is
|
|
logged and the function returns false to indicate an error.
|
|
|
|
Reported by smatch:
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-38552)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issue of net_device
|
|
|
|
There is a reference count leak issue of the object "net_device" in
|
|
ax25_dev_device_down(). When the ax25 device is shutting down, the
|
|
ax25_dev_device_down() drops the reference count of net_device one
|
|
or zero times depending on if we goto unlock_put or not, which will
|
|
cause memory leak.
|
|
|
|
In order to solve the above issue, decrease the reference count of
|
|
net_device after dev->ax25_ptr is set to null.(CVE-2024-38554)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40(CVE-2024-38555)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: nl80211: Avoid address calculations via out of bounds array indexing
|
|
|
|
Before request->channels[] can be used, request->n_channels must be set.
|
|
Additionally, address calculations for memory after the "channels" array
|
|
need to be calculated from the allocation base ("request") rather than
|
|
via the first "out of bounds" index of "channels", otherwise run-time
|
|
bounds checking will throw a warning.(CVE-2024-38562)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
|
|
|
|
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
|
|
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
|
|
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
|
|
to properly verify prog_type <> attach_type association.
|
|
|
|
Add missing attach_type enforcement for the link_create case.
|
|
Otherwise, it's currently possible to attach cgroup_skb prog
|
|
types to other cgroup hooks.(CVE-2024-38564)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
|
|
|
|
There is a possibility of buffer overflow in
|
|
show_rcu_tasks_trace_gp_kthread() if counters, passed
|
|
to sprintf() are huge. Counter numbers, needed for this
|
|
are unrealistically high, but buffer overflow is still
|
|
possible.
|
|
|
|
Use snprintf() with buffer size instead of sprintf().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: bcm - Fix pointer arithmetic
|
|
|
|
In spu2_dump_omd() value of ptr is increased by ciph_key_len
|
|
instead of hash_iv_len which could lead to going beyond the
|
|
buffer boundaries.
|
|
Fix this bug by changing ciph_key_len to hash_iv_len.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential hang in nilfs_detach_log_writer()
|
|
|
|
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
|
|
during nilfs2 unmount.
|
|
|
|
Analysis revealed that this is because nilfs_segctor_sync(), which
|
|
synchronizes with the log writer thread, can be called after
|
|
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
|
|
below:
|
|
|
|
nilfs_detach_log_writer
|
|
nilfs_segctor_destroy
|
|
nilfs_segctor_kill_thread --> Shut down log writer thread
|
|
flush_work
|
|
nilfs_iput_work_func
|
|
nilfs_dispose_list
|
|
iput
|
|
nilfs_evict_inode
|
|
nilfs_transaction_commit
|
|
nilfs_construct_segment (if inode needs sync)
|
|
nilfs_segctor_sync --> Attempt to synchronize with
|
|
log writer thread
|
|
*** DEADLOCK ***
|
|
|
|
Fix this issue by changing nilfs_segctor_sync() so that the log writer
|
|
thread returns normally without synchronizing after it terminates, and by
|
|
forcing tasks that are already waiting to complete once after the thread
|
|
terminates.
|
|
|
|
The skipped inode metadata flushout will then be processed together in the
|
|
subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ftrace: Fix possible use-after-free issue in ftrace_location()
|
|
|
|
KASAN reports a bug:
|
|
|
|
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
|
|
Read of size 8 at addr ffff888141d40010 by task insmod/424
|
|
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x68/0xa0
|
|
print_report+0xcf/0x610
|
|
kasan_report+0xb5/0xe0
|
|
ftrace_location+0x90/0x120
|
|
register_kprobe+0x14b/0xa40
|
|
kprobe_init+0x2d/0xff0 [kprobe_example]
|
|
do_one_initcall+0x8f/0x2d0
|
|
do_init_module+0x13a/0x3c0
|
|
load_module+0x3082/0x33d0
|
|
init_module_from_file+0xd2/0x130
|
|
__x64_sys_finit_module+0x306/0x440
|
|
do_syscall_64+0x68/0x140
|
|
entry_SYSCALL_64_after_hwframe+0x71/0x79
|
|
|
|
The root cause is that, in lookup_rec(), ftrace record of some address
|
|
is being searched in ftrace pages of some module, but those ftrace pages
|
|
at the same time is being freed in ftrace_release_mod() as the
|
|
corresponding module is being deleted:
|
|
|
|
CPU1 | CPU2
|
|
register_kprobes() { | delete_module() {
|
|
check_kprobe_address_safe() { |
|
|
arch_check_ftrace_location() { |
|
|
ftrace_location() { |
|
|
lookup_rec() // USE! | ftrace_release_mod() // Free!
|
|
|
|
To fix this issue:
|
|
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
|
|
2. Use ftrace_location_range() instead of lookup_rec() in
|
|
ftrace_location();
|
|
3. Call synchronize_rcu() before freeing any ftrace pages both in
|
|
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md: fix resync softlockup when bitmap size is less than array size
|
|
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
|
trigger following softlockup:
|
|
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
|
Call Trace:
|
|
<TASK>
|
|
md_bitmap_start_sync+0x6b/0xf0
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
|
md_do_sync+0x64b/0x1020
|
|
md_thread+0xa7/0x170
|
|
kthread+0xcf/0x100
|
|
ret_from_fork+0x30/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
And the detailed process is as follows:
|
|
|
|
md_do_sync
|
|
j = mddev->resync_min
|
|
while (j < max_sectors)
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
|
return sync_blocks + sectors_skippe;
|
|
// sectors = 0;
|
|
j += sectors;
|
|
// j never change
|
|
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
|
|
|
Fix this problem by always set returned blocks from
|
|
md_bitmap_get_counter"(), as it used to be.
|
|
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
|
case that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issues of ax25_dev
|
|
|
|
The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
|
|
count leak issue of the object "ax25_dev".
|
|
|
|
Memory leak issue in ax25_addr_ax25dev():
|
|
|
|
The reference count of the object "ax25_dev" can be increased multiple
|
|
times in ax25_addr_ax25dev(). This will cause a memory leak.
|
|
|
|
Memory leak issues in ax25_dev_device_down():
|
|
|
|
The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
|
|
then increase the reference count when ax25_dev is added to ax25_dev_list.
|
|
As a result, the reference count of ax25_dev is 2. But when the device is
|
|
shutting down. The ax25_dev_device_down() drops the reference count once
|
|
or twice depending on if we goto unlock_put or not, which will cause
|
|
memory leak.
|
|
|
|
As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
|
|
to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
|
|
issue of ax25_dev_device_down(), increase the reference count of ax25_dev
|
|
once in ax25_dev_device_up() and decrease the reference count of ax25_dev
|
|
after it is removed from the ax25_dev_list.(CVE-2024-38602)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: refine the EOF check in blkdev_iomap_begin
|
|
|
|
blkdev_iomap_begin rounds down the offset to the logical block size
|
|
before stashing it in iomap->offset and checking that it still is
|
|
inside the inode size.
|
|
|
|
Check the i_size check to the raw pos value so that we don't try a
|
|
zero size write if iter->pos is unaligned.(CVE-2024-38604)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
|
|
|
|
Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".
|
|
|
|
Patch #1 fixes a bunch of issues I spotted in the acrn driver. It
|
|
compiles, that's all I know. I'll appreciate some review and testing from
|
|
acrn folks.
|
|
|
|
Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
|
|
more sanity checks, and improving the documentation. Gave it a quick test
|
|
on x86-64 using VM_PAT that ends up using follow_pte().
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
We currently miss handling various cases, resulting in a dangerous
|
|
follow_pte() (previously follow_pfn()) usage.
|
|
|
|
(1) We're not checking PTE write permissions.
|
|
|
|
Maybe we should simply always require pte_write() like we do for
|
|
pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
|
|
ACRN_MEM_ACCESS_WRITE for now.
|
|
|
|
(2) We're not rejecting refcounted pages.
|
|
|
|
As we are not using MMU notifiers, messing with refcounted pages is
|
|
dangerous and can result in use-after-free. Let's make sure to reject them.
|
|
|
|
(3) We are only looking at the first PTE of a bigger range.
|
|
|
|
We only lookup a single PTE, but memmap->len may span a larger area.
|
|
Let's loop over all involved PTEs and make sure the PFN range is
|
|
actually contiguous. Reject everything else: it couldn't have worked
|
|
either way, and rather made use access PFNs we shouldn't be accessing.(CVE-2024-38610)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/msm/dpu: Add callback function pointer check before its call
|
|
|
|
In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
|
|
but then callback function is unconditionally called by this pointer.
|
|
Fix this bug by adding conditional return.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
Patchwork: https://patchwork.freedesktop.org/patch/588237/(CVE-2024-38622)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Use variable length array instead of fixed size
|
|
|
|
Should fix smatch warning:
|
|
ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)(CVE-2024-38623)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
|
|
|
|
For example, in the expression:
|
|
vbo = 2 * vbo + skip(CVE-2024-38624)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Check 'folio' pointer for NULL
|
|
|
|
It can be NULL if bmap is called.(CVE-2024-38625)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
|
|
|
|
Hang on to the control IDs instead of pointers since those are correctly
|
|
handled with locks.(CVE-2024-38628)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Avoid unnecessary destruction of file_ida
|
|
|
|
file_ida is allocated during cdev open and is freed accordingly
|
|
during cdev release. This sequence is guaranteed by driver file
|
|
operations. Therefore, there is no need to destroy an already empty
|
|
file_ida when the WQ cdev is removed.
|
|
|
|
Worse, ida_free() in cdev release may happen after destruction of
|
|
file_ida per WQ cdev. This can lead to accessing an id in file_ida
|
|
after it has been destroyed, resulting in a kernel panic.
|
|
|
|
Remove ida_destroy(&file_ida) to address these issues.(CVE-2024-38629)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.(CVE-2024-38630)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
greybus: lights: check return of get_channel_from_mode
|
|
|
|
If channel for the given node is not found we return null from
|
|
get_channel_from_mode. Make sure we validate the return pointer
|
|
before using it in two of the missing places.
|
|
|
|
This was originally reported in [0]:
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Allow delete from sockmap/sockhash only if update is allowed
|
|
|
|
We have seen an influx of syzkaller reports where a BPF program attached to
|
|
a tracepoint triggers a locking rule violation by performing a map_delete
|
|
on a sockmap/sockhash.
|
|
|
|
We don't intend to support this artificial use scenario. Extend the
|
|
existing verifier allowed-program-type check for updating sockmap/sockhash
|
|
to also cover deleting from a map.
|
|
|
|
From now on only BPF programs which were previously allowed to update
|
|
sockmap/sockhash can delete from these map types.(CVE-2024-38662)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: zynqmp_dpsub: Always register bridge
|
|
|
|
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
|
|
calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
|
|
initialized. We do this before zynqmp_dpsub_drm_init since that calls
|
|
drm_bridge_attach. This fixes the following lockdep warning:
|
|
|
|
[ 19.217084] ------------[ cut here ]------------
|
|
[ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
|
|
[ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550
|
|
[ 19.241696] Modules linked in:
|
|
[ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96
|
|
[ 19.252046] Hardware name: xlnx,zynqmp (DT)
|
|
[ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func
|
|
[ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
[ 19.269104] pc : __mutex_lock+0x4bc/0x550
|
|
[ 19.273364] lr : __mutex_lock+0x4bc/0x550
|
|
[ 19.277592] sp : ffffffc085c5bbe0
|
|
[ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8
|
|
[ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000
|
|
[ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000
|
|
[ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000
|
|
[ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720
|
|
[ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001
|
|
[ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888
|
|
[ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000
|
|
[ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000
|
|
[ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880
|
|
[ 19.356581] Call trace:
|
|
[ 19.359160] __mutex_lock+0x4bc/0x550
|
|
[ 19.363032] mutex_lock_nested+0x24/0x30
|
|
[ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c
|
|
[ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54
|
|
[ 19.376364] process_one_work+0x3ac/0x988
|
|
[ 19.380660] worker_thread+0x398/0x694
|
|
[ 19.384736] kthread+0x1bc/0x1c0
|
|
[ 19.388241] ret_from_fork+0x10/0x20
|
|
[ 19.392031] irq event stamp: 183
|
|
[ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4
|
|
[ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04
|
|
[ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c
|
|
[ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c
|
|
[ 19.432614] ---[ end trace 0000000000000000 ]---
|
|
|
|
(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)(CVE-2024-38664)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
|
|
|
|
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
|
|
known context") by error replaced spin_unlock_irqrestore() with
|
|
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
|
|
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
|
|
inconsistent lock state warning.
|
|
|
|
Use plain spin_{lock,unlock}() for sync_print_obj(), for
|
|
sync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bonding: fix oops during rmmod
|
|
|
|
"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding:
|
|
remove redundant NULL check in debugfs function"). Here are the relevant
|
|
functions being called:
|
|
|
|
bonding_exit()
|
|
bond_destroy_debugfs()
|
|
debugfs_remove_recursive(bonding_debug_root);
|
|
bonding_debug_root = NULL; <--------- SET TO NULL HERE
|
|
bond_netlink_fini()
|
|
rtnl_link_unregister()
|
|
__rtnl_link_unregister()
|
|
unregister_netdevice_many_notify()
|
|
bond_uninit()
|
|
bond_debug_unregister()
|
|
(commit removed check for bonding_debug_root == NULL)
|
|
debugfs_remove()
|
|
simple_recursive_removal()
|
|
down_write() -> OOPS
|
|
|
|
However, reverting the bad commit does not solve the problem completely
|
|
because the original code contains a race that could cause the same
|
|
oops, although it was much less likely to be triggered unintentionally:
|
|
|
|
CPU1
|
|
rmmod bonding
|
|
bonding_exit()
|
|
bond_destroy_debugfs()
|
|
debugfs_remove_recursive(bonding_debug_root);
|
|
|
|
CPU2
|
|
echo -bond0 > /sys/class/net/bonding_masters
|
|
bond_uninit()
|
|
bond_debug_unregister()
|
|
if (!bonding_debug_root)
|
|
|
|
CPU1
|
|
bonding_debug_root = NULL;
|
|
|
|
So do NOT revert the bad commit (since the removed checks were racy
|
|
anyway), and instead change the order of actions taken during module
|
|
removal. The same oops can also happen if there is an error during
|
|
module init, so apply the same fix there.(CVE-2024-39296)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/9p: fix uninit-value in p9_client_rpc()
|
|
|
|
Syzbot with the help of KMSAN reported the following error:
|
|
|
|
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
alloc_slab_page mm/slub.c:2175 [inline]
|
|
allocate_slab mm/slub.c:2338 [inline]
|
|
new_slab+0x2de/0x1400 mm/slub.c:2391
|
|
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
|
|
__slab_alloc mm/slub.c:3610 [inline]
|
|
__slab_alloc_node mm/slub.c:3663 [inline]
|
|
slab_alloc_node mm/slub.c:3835 [inline]
|
|
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
|
|
p9_tag_alloc net/9p/client.c:278 [inline]
|
|
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
|
|
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
|
|
will not be properly initialized. However, trace_9p_client_res()
|
|
ends up trying to print it out anyway before p9_client_rpc()
|
|
finishes.
|
|
|
|
Fix this issue by assigning default values to p9_fcall fields
|
|
such as 'tag' and (just in case KMSAN unearths something new) 'id'
|
|
during the tag allocation stage.(CVE-2024-39301)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: check for non-NULL file pointer in io_file_can_poll()
|
|
|
|
In earlier kernels, it was possible to trigger a NULL pointer
|
|
dereference off the forced async preparation path, if no file had
|
|
been assigned. The trace leading to that looks as follows:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 00000000000000b0
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
|
|
RIP: 0010:io_buffer_select+0xc3/0x210
|
|
Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b
|
|
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
|
|
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
|
|
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
|
|
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
|
|
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
|
|
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
|
|
FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
|
|
Call Trace:
|
|
<TASK>
|
|
? __die+0x1f/0x60
|
|
? page_fault_oops+0x14d/0x420
|
|
? do_user_addr_fault+0x61/0x6a0
|
|
? exc_page_fault+0x6c/0x150
|
|
? asm_exc_page_fault+0x22/0x30
|
|
? io_buffer_select+0xc3/0x210
|
|
__io_import_iovec+0xb5/0x120
|
|
io_readv_prep_async+0x36/0x70
|
|
io_queue_sqe_fallback+0x20/0x260
|
|
io_submit_sqes+0x314/0x630
|
|
__do_sys_io_uring_enter+0x339/0xbc0
|
|
? __do_sys_io_uring_register+0x11b/0xc50
|
|
? vm_mmap_pgoff+0xce/0x160
|
|
do_syscall_64+0x5f/0x180
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0x55e0a110a67e
|
|
Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6
|
|
|
|
because the request is marked forced ASYNC and has a bad file fd, and
|
|
hence takes the forced async prep path.
|
|
|
|
Current kernels with the request async prep cleaned up can no longer hit
|
|
this issue, but for ease of backporting, let's add this safety check in
|
|
here too as it really doesn't hurt. For both cases, this will inevitably
|
|
end with a CQE posted with -EBADF.(CVE-2024-39371)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: bcm: rpi: Assign ->num before accessing ->hws
|
|
|
|
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
|
|
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
|
|
with __counted_by, which informs the bounds sanitizer about the number
|
|
of elements in hws, so that it can warn when hws is accessed out of
|
|
bounds. As noted in that change, the __counted_by member must be
|
|
initialized with the number of elements before the first array access
|
|
happens, otherwise there will be a warning from each access prior to the
|
|
initialization because the number of elements is zero. This occurs in
|
|
raspberrypi_discover_clocks() due to ->num being assigned after ->hws
|
|
has been accessed:
|
|
|
|
UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4
|
|
index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
|
|
|
|
Move the ->num initialization to before the first access of ->hws, which
|
|
clears up the warning.(CVE-2024-39461)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
thermal/drivers/qcom/lmh: Check for SCM availability at probe
|
|
|
|
Up until now, the necessary scm availability check has not been
|
|
performed, leading to possible null pointer dereferences (which did
|
|
happen for me on RB1).
|
|
|
|
Fix that.(CVE-2024-39466)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
|
|
|
|
syzbot reports a kernel bug as below:
|
|
|
|
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
|
|
==================================================================
|
|
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
|
|
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
|
|
|
|
CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-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
|
|
f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
|
|
current_nat_addr fs/f2fs/node.h:213 [inline]
|
|
f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
|
|
f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
|
|
f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
|
|
ioctl_fiemap fs/ioctl.c:220 [inline]
|
|
do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
|
|
__do_sys_ioctl fs/ioctl.c:902 [inline]
|
|
__se_sys_ioctl+0x81/0x170 fs/ioctl.c:890
|
|
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
|
|
|
|
The root cause is we missed to do sanity check on i_xattr_nid during
|
|
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
|
|
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
|
|
kasan bug report, fix it.(CVE-2024-39467)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
smb: client: fix deadlock in smb2_find_smb_tcon()
|
|
|
|
Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
|
|
deadlock.(CVE-2024-39468)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
eventfs: Fix a possible null pointer dereference in eventfs_find_events()
|
|
|
|
In function eventfs_find_events,there is a potential null pointer
|
|
that may be caused by calling update_events_attr which will perform
|
|
some operations on the members of the ei struct when ei is NULL.
|
|
|
|
Hence,When ei->is_freed is set,return NULL directly.(CVE-2024-39470)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of critical. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Critical</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48772</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-31076</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36489</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36949</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36952</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36962</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36965</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37353</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37354</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37356</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38551</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38552</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38554</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38555</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38562</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38564</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38577</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38579</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38582</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38588</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38598</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38599</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38602</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38604</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38610</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38622</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38623</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38624</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38625</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38628</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38629</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38630</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38634</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38637</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38662</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38664</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38780</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39296</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39301</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39362</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39371</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39461</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39466</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39467</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39468</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39470</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48772</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-31076</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36489</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36949</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36952</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36962</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36965</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37353</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37354</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37356</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38551</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38552</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38554</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38555</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38562</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38564</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38577</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38579</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38582</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38588</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38598</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38599</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38602</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38604</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38610</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38622</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38623</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38624</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38625</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38628</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38629</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38630</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38634</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38637</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38662</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38664</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38780</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39296</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39301</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39362</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39371</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39461</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39466</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39467</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39468</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39470</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-6.6.0-33.0.0.40" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-33.0.0.40.oe2403.src.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: lgdt3306a: Add a check against null-pointer-def
|
|
|
|
The driver should check whether the client provides the platform_data.
|
|
|
|
The following log reveals it:
|
|
|
|
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
|
|
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
|
|
[ 29.612820] Call Trace:
|
|
[ 29.613030] <TASK>
|
|
[ 29.613201] dump_stack_lvl+0x56/0x6f
|
|
[ 29.613496] ? kmemdup+0x30/0x40
|
|
[ 29.613754] print_report.cold+0x494/0x6b7
|
|
[ 29.614082] ? kmemdup+0x30/0x40
|
|
[ 29.614340] kasan_report+0x8a/0x190
|
|
[ 29.614628] ? kmemdup+0x30/0x40
|
|
[ 29.614888] kasan_check_range+0x14d/0x1d0
|
|
[ 29.615213] memcpy+0x20/0x60
|
|
[ 29.615454] kmemdup+0x30/0x40
|
|
[ 29.615700] lgdt3306a_probe+0x52/0x310
|
|
[ 29.616339] i2c_device_probe+0x951/0xa90</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48772</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-31076</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tls: fix missing memory barrier in tls_init
|
|
|
|
In tls_init(), a write memory barrier is missing, and store-store
|
|
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.
|
|
|
|
CPU0 CPU1
|
|
----- -----
|
|
// In tls_init()
|
|
// In tls_ctx_create()
|
|
ctx = kzalloc()
|
|
ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)
|
|
|
|
// In update_sk_prot()
|
|
WRITE_ONCE(sk->sk_prot, tls_prots) -(2)
|
|
|
|
// In sock_common_setsockopt()
|
|
READ_ONCE(sk->sk_prot)->setsockopt()
|
|
|
|
// In tls_{setsockopt,getsockopt}()
|
|
ctx->sk_proto->setsockopt() -(3)
|
|
|
|
In the above scenario, when (1) and (2) are reordered, (3) can observe
|
|
the NULL value of ctx->sk_proto, causing NULL dereference.
|
|
|
|
To fix it, we rely on rcu_assign_pointer() which implies the release
|
|
barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is
|
|
initialized, we can ensure that ctx->sk_proto are visible when
|
|
changing sk->sk_prot.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36489</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36949</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
|
|
|
|
There are cases after NPIV deletion where the fabric switch still believes
|
|
the NPIV is logged into the fabric. This occurs when a vport is
|
|
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
|
|
fabric.
|
|
|
|
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
|
|
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
|
|
object. This sometimes causes the race condition where the final DA_ID and
|
|
LOGO are skipped from being sent to the fabric switch.
|
|
|
|
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
|
|
and LOGO are sent.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36952</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs
|
|
|
|
Currently the driver uses local_bh_disable()/local_bh_enable() in its
|
|
IRQ handler to avoid triggering net_rx_action() softirq on exit from
|
|
netif_rx(). The net_rx_action() could trigger this driver .start_xmit
|
|
callback, which is protected by the same lock as the IRQ handler, so
|
|
calling the .start_xmit from netif_rx() from the IRQ handler critical
|
|
section protected by the lock could lead to an attempt to claim the
|
|
already claimed lock, and a hang.
|
|
|
|
The local_bh_disable()/local_bh_enable() approach works only in case
|
|
the IRQ handler is protected by a spinlock, but does not work if the
|
|
IRQ handler is protected by mutex, i.e. this works for KS8851 with
|
|
Parallel bus interface, but not for KS8851 with SPI bus interface.
|
|
|
|
Remove the BH manipulation and instead of calling netif_rx() inside
|
|
the IRQ handler code protected by the lock, queue all the received
|
|
SKBs in the IRQ handler into a queue first, and once the IRQ handler
|
|
exits the critical section protected by the lock, dequeue all the
|
|
queued SKBs and push them all into netif_rx(). At this point, it is
|
|
safe to trigger the net_rx_action() softirq, since the netif_rx()
|
|
call is outside of the lock that protects the IRQ handler.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36962</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.2</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
|
|
|
|
The IPI buffer location is read from the firmware that we load to the
|
|
System Companion Processor, and it's not granted that both the SRAM
|
|
(L2TCM) size that is defined in the devicetree node is large enough
|
|
for that, and while this is especially true for multi-core SCP, it's
|
|
still useful to check on single-core variants as well.
|
|
|
|
Failing to perform this check may make this driver perform R/W
|
|
operations out of the L2TCM boundary, resulting (at best) in a
|
|
kernel panic.
|
|
|
|
To fix that, check that the IPI buffer fits, otherwise return a
|
|
failure and refuse to boot the relevant SCP core (or the SCP at
|
|
all, if this is single core).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36965</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.6</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
|
|
|
|
When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
|
|
present in the list, free_irq() is called for the same vector. That
|
|
causes following splat:
|
|
|
|
[ 0.414355] Trying to free already-free IRQ 27
|
|
[ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
|
|
[ 0.414510] Modules linked in:
|
|
[ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
|
|
[ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
[ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
|
|
[ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
|
|
[ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
|
|
[ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
|
|
[ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
|
|
[ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
|
|
[ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
|
|
[ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
|
|
[ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
|
|
[ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
|
|
[ 0.414540] Call Trace:
|
|
[ 0.414540] <TASK>
|
|
[ 0.414540] ? __warn+0x80/0x120
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] ? report_bug+0x164/0x190
|
|
[ 0.414540] ? handle_bug+0x3b/0x70
|
|
[ 0.414540] ? exc_invalid_op+0x17/0x70
|
|
[ 0.414540] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] vp_del_vqs+0xc1/0x220
|
|
[ 0.414540] vp_find_vqs_msix+0x305/0x470
|
|
[ 0.414540] vp_find_vqs+0x3e/0x1a0
|
|
[ 0.414540] vp_modern_find_vqs+0x1b/0x70
|
|
[ 0.414540] init_vqs+0x387/0x600
|
|
[ 0.414540] virtnet_probe+0x50a/0xc80
|
|
[ 0.414540] virtio_dev_probe+0x1e0/0x2b0
|
|
[ 0.414540] really_probe+0xc0/0x2c0
|
|
[ 0.414540] ? __pfx___driver_attach+0x10/0x10
|
|
[ 0.414540] __driver_probe_device+0x73/0x120
|
|
[ 0.414540] driver_probe_device+0x1f/0xe0
|
|
[ 0.414540] __driver_attach+0x88/0x180
|
|
[ 0.414540] bus_for_each_dev+0x85/0xd0
|
|
[ 0.414540] bus_add_driver+0xec/0x1f0
|
|
[ 0.414540] driver_register+0x59/0x100
|
|
[ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10
|
|
[ 0.414540] virtio_net_driver_init+0x90/0xb0
|
|
[ 0.414540] do_one_initcall+0x58/0x230
|
|
[ 0.414540] kernel_init_freeable+0x1a3/0x2d0
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] kernel_init+0x1a/0x1c0
|
|
[ 0.414540] ret_from_fork+0x31/0x50
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] ret_from_fork_asm+0x1a/0x30
|
|
[ 0.414540] </TASK>
|
|
|
|
Fix this by calling deleting the current vq when request_irq() fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-37353</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix crash on racing fsync and size-extending write into prealloc
|
|
|
|
We have been seeing crashes on duplicate keys in
|
|
btrfs_set_item_key_safe():
|
|
|
|
BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/ctree.c:2620!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
|
|
RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
|
|
|
|
With the following stack trace:
|
|
|
|
#0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
|
|
#1 btrfs_drop_extents (fs/btrfs/file.c:411:4)
|
|
#2 log_one_extent (fs/btrfs/tree-log.c:4732:9)
|
|
#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
|
|
#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
|
|
#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
|
|
#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
|
|
#7 btrfs_sync_file (fs/btrfs/file.c:1933:8)
|
|
#8 vfs_fsync_range (fs/sync.c:188:9)
|
|
#9 vfs_fsync (fs/sync.c:202:9)
|
|
#10 do_fsync (fs/sync.c:212:9)
|
|
#11 __do_sys_fdatasync (fs/sync.c:225:9)
|
|
#12 __se_sys_fdatasync (fs/sync.c:223:1)
|
|
#13 __x64_sys_fdatasync (fs/sync.c:223:1)
|
|
#14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
|
|
#15 do_syscall_64 (arch/x86/entry/common.c:83:7)
|
|
#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
|
|
|
|
So we're logging a changed extent from fsync, which is splitting an
|
|
extent in the log tree. But this split part already exists in the tree,
|
|
triggering the BUG().
|
|
|
|
This is the state of the log tree at the time of the crash, dumped with
|
|
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
|
|
to get more details than btrfs_print_leaf() gives us:
|
|
|
|
>>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
|
|
leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
|
|
leaf 33439744 flags 0x100000000000000
|
|
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
|
|
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
|
|
item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
|
|
generation 7 transid 9 size 8192 nbytes 8473563889606862198
|
|
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
|
|
sequence 204 flags 0x10(PREALLOC)
|
|
atime 1716417703.220000000 (2024-05-22 15:41:43)
|
|
ctime 1716417704.983333333 (2024-05-22 15:41:44)
|
|
mtime 1716417704.983333333 (2024-05-22 15:41:44)
|
|
otime 17592186044416.000000000 (559444-03-08 01:40:16)
|
|
item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
|
|
index 195 namelen 3 name: 193
|
|
item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
|
|
location key (0 UNKNOWN.0 0) type XATTR
|
|
transid 7 data_len 1 name_len 6
|
|
name: user.a
|
|
data a
|
|
item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
|
|
generation 9 type 1 (regular)
|
|
extent data disk byte 303144960 nr 12288
|
|
extent data offset 0 nr 4096 ram 12288
|
|
extent compression 0 (none)
|
|
item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
|
|
generation 9 type 2 (prealloc)
|
|
prealloc data disk byte 303144960 nr 12288
|
|
prealloc data offset 4096 nr 8192
|
|
item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
|
|
generation 9 type 2 (prealloc)
|
|
prealloc data disk byte 303144960 nr 12288
|
|
prealloc data offset 8192 nr 4096
|
|
...
|
|
|
|
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
|
|
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
|
|
item 5 starts at i_size.
|
|
|
|
Here is the state of
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-37354</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-37356</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: mediatek: Assign dummy when codec not specified for a DAI link
|
|
|
|
MediaTek sound card drivers are checking whether a DAI link is present
|
|
and used on a board to assign the correct parameters and this is done
|
|
by checking the codec DAI names at probe time.
|
|
|
|
If no real codec is present, assign the dummy codec to the DAI link
|
|
to avoid NULL pointer during string comparison.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38551</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix potential index out of bounds in color transformation function
|
|
|
|
Fixes index out of bounds issue in the color transformation function.
|
|
The issue could occur when the index 'i' exceeds the number of transfer
|
|
function points (TRANSFER_FUNC_POINTS).
|
|
|
|
The fix adds a check to ensure 'i' is within bounds before accessing the
|
|
transfer function points. If 'i' is out of bounds, an error message is
|
|
logged and the function returns false to indicate an error.
|
|
|
|
Reported by smatch:
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38552</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issue of net_device
|
|
|
|
There is a reference count leak issue of the object "net_device" in
|
|
ax25_dev_device_down(). When the ax25 device is shutting down, the
|
|
ax25_dev_device_down() drops the reference count of net_device one
|
|
or zero times depending on if we goto unlock_put or not, which will
|
|
cause memory leak.
|
|
|
|
In order to solve the above issue, decrease the reference count of
|
|
net_device after dev->ax25_ptr is set to null.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38554</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38555</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: nl80211: Avoid address calculations via out of bounds array indexing
|
|
|
|
Before request->channels[] can be used, request->n_channels must be set.
|
|
Additionally, address calculations for memory after the "channels" array
|
|
need to be calculated from the allocation base ("request") rather than
|
|
via the first "out of bounds" index of "channels", otherwise run-time
|
|
bounds checking will throw a warning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38562</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
|
|
|
|
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
|
|
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
|
|
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
|
|
to properly verify prog_type <> attach_type association.
|
|
|
|
Add missing attach_type enforcement for the link_create case.
|
|
Otherwise, it's currently possible to attach cgroup_skb prog
|
|
types to other cgroup hooks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38564</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
|
|
|
|
There is a possibility of buffer overflow in
|
|
show_rcu_tasks_trace_gp_kthread() if counters, passed
|
|
to sprintf() are huge. Counter numbers, needed for this
|
|
are unrealistically high, but buffer overflow is still
|
|
possible.
|
|
|
|
Use snprintf() with buffer size instead of sprintf().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38577</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: bcm - Fix pointer arithmetic
|
|
|
|
In spu2_dump_omd() value of ptr is increased by ciph_key_len
|
|
instead of hash_iv_len which could lead to going beyond the
|
|
buffer boundaries.
|
|
Fix this bug by changing ciph_key_len to hash_iv_len.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38579</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential hang in nilfs_detach_log_writer()
|
|
|
|
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
|
|
during nilfs2 unmount.
|
|
|
|
Analysis revealed that this is because nilfs_segctor_sync(), which
|
|
synchronizes with the log writer thread, can be called after
|
|
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
|
|
below:
|
|
|
|
nilfs_detach_log_writer
|
|
nilfs_segctor_destroy
|
|
nilfs_segctor_kill_thread --> Shut down log writer thread
|
|
flush_work
|
|
nilfs_iput_work_func
|
|
nilfs_dispose_list
|
|
iput
|
|
nilfs_evict_inode
|
|
nilfs_transaction_commit
|
|
nilfs_construct_segment (if inode needs sync)
|
|
nilfs_segctor_sync --> Attempt to synchronize with
|
|
log writer thread
|
|
*** DEADLOCK ***
|
|
|
|
Fix this issue by changing nilfs_segctor_sync() so that the log writer
|
|
thread returns normally without synchronizing after it terminates, and by
|
|
forcing tasks that are already waiting to complete once after the thread
|
|
terminates.
|
|
|
|
The skipped inode metadata flushout will then be processed together in the
|
|
subsequent cleanup work in nilfs_segctor_destroy().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38582</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ftrace: Fix possible use-after-free issue in ftrace_location()
|
|
|
|
KASAN reports a bug:
|
|
|
|
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
|
|
Read of size 8 at addr ffff888141d40010 by task insmod/424
|
|
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x68/0xa0
|
|
print_report+0xcf/0x610
|
|
kasan_report+0xb5/0xe0
|
|
ftrace_location+0x90/0x120
|
|
register_kprobe+0x14b/0xa40
|
|
kprobe_init+0x2d/0xff0 [kprobe_example]
|
|
do_one_initcall+0x8f/0x2d0
|
|
do_init_module+0x13a/0x3c0
|
|
load_module+0x3082/0x33d0
|
|
init_module_from_file+0xd2/0x130
|
|
__x64_sys_finit_module+0x306/0x440
|
|
do_syscall_64+0x68/0x140
|
|
entry_SYSCALL_64_after_hwframe+0x71/0x79
|
|
|
|
The root cause is that, in lookup_rec(), ftrace record of some address
|
|
is being searched in ftrace pages of some module, but those ftrace pages
|
|
at the same time is being freed in ftrace_release_mod() as the
|
|
corresponding module is being deleted:
|
|
|
|
CPU1 | CPU2
|
|
register_kprobes() { | delete_module() {
|
|
check_kprobe_address_safe() { |
|
|
arch_check_ftrace_location() { |
|
|
ftrace_location() { |
|
|
lookup_rec() // USE! | ftrace_release_mod() // Free!
|
|
|
|
To fix this issue:
|
|
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
|
|
2. Use ftrace_location_range() instead of lookup_rec() in
|
|
ftrace_location();
|
|
3. Call synchronize_rcu() before freeing any ftrace pages both in
|
|
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38588</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md: fix resync softlockup when bitmap size is less than array size
|
|
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
|
trigger following softlockup:
|
|
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
|
Call Trace:
|
|
<TASK>
|
|
md_bitmap_start_sync+0x6b/0xf0
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
|
md_do_sync+0x64b/0x1020
|
|
md_thread+0xa7/0x170
|
|
kthread+0xcf/0x100
|
|
ret_from_fork+0x30/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
And the detailed process is as follows:
|
|
|
|
md_do_sync
|
|
j = mddev->resync_min
|
|
while (j < max_sectors)
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
|
return sync_blocks + sectors_skippe;
|
|
// sectors = 0;
|
|
j += sectors;
|
|
// j never change
|
|
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
|
|
|
Fix this problem by always set returned blocks from
|
|
md_bitmap_get_counter"(), as it used to be.
|
|
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
|
case that bitmap size doesn't match array size still need to be fixed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38598</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38599</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issues of ax25_dev
|
|
|
|
The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
|
|
count leak issue of the object "ax25_dev".
|
|
|
|
Memory leak issue in ax25_addr_ax25dev():
|
|
|
|
The reference count of the object "ax25_dev" can be increased multiple
|
|
times in ax25_addr_ax25dev(). This will cause a memory leak.
|
|
|
|
Memory leak issues in ax25_dev_device_down():
|
|
|
|
The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
|
|
then increase the reference count when ax25_dev is added to ax25_dev_list.
|
|
As a result, the reference count of ax25_dev is 2. But when the device is
|
|
shutting down. The ax25_dev_device_down() drops the reference count once
|
|
or twice depending on if we goto unlock_put or not, which will cause
|
|
memory leak.
|
|
|
|
As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
|
|
to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
|
|
issue of ax25_dev_device_down(), increase the reference count of ax25_dev
|
|
once in ax25_dev_device_up() and decrease the reference count of ax25_dev
|
|
after it is removed from the ax25_dev_list.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38602</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: refine the EOF check in blkdev_iomap_begin
|
|
|
|
blkdev_iomap_begin rounds down the offset to the logical block size
|
|
before stashing it in iomap->offset and checking that it still is
|
|
inside the inode size.
|
|
|
|
Check the i_size check to the raw pos value so that we don't try a
|
|
zero size write if iter->pos is unaligned.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38604</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
|
|
|
|
Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".
|
|
|
|
Patch #1 fixes a bunch of issues I spotted in the acrn driver. It
|
|
compiles, that's all I know. I'll appreciate some review and testing from
|
|
acrn folks.
|
|
|
|
Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
|
|
more sanity checks, and improving the documentation. Gave it a quick test
|
|
on x86-64 using VM_PAT that ends up using follow_pte().
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
We currently miss handling various cases, resulting in a dangerous
|
|
follow_pte() (previously follow_pfn()) usage.
|
|
|
|
(1) We're not checking PTE write permissions.
|
|
|
|
Maybe we should simply always require pte_write() like we do for
|
|
pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
|
|
ACRN_MEM_ACCESS_WRITE for now.
|
|
|
|
(2) We're not rejecting refcounted pages.
|
|
|
|
As we are not using MMU notifiers, messing with refcounted pages is
|
|
dangerous and can result in use-after-free. Let's make sure to reject them.
|
|
|
|
(3) We are only looking at the first PTE of a bigger range.
|
|
|
|
We only lookup a single PTE, but memmap->len may span a larger area.
|
|
Let's loop over all involved PTEs and make sure the PFN range is
|
|
actually contiguous. Reject everything else: it couldn't have worked
|
|
either way, and rather made use access PFNs we shouldn't be accessing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38610</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/msm/dpu: Add callback function pointer check before its call
|
|
|
|
In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
|
|
but then callback function is unconditionally called by this pointer.
|
|
Fix this bug by adding conditional return.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
Patchwork: https://patchwork.freedesktop.org/patch/588237/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38622</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Use variable length array instead of fixed size
|
|
|
|
Should fix smatch warning:
|
|
ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38623</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Critical</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>9.8</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
|
|
|
|
For example, in the expression:
|
|
vbo = 2 * vbo + skip</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38624</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Check 'folio' pointer for NULL
|
|
|
|
It can be NULL if bmap is called.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38625</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
|
|
|
|
Hang on to the control IDs instead of pointers since those are correctly
|
|
handled with locks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38628</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Avoid unnecessary destruction of file_ida
|
|
|
|
file_ida is allocated during cdev open and is freed accordingly
|
|
during cdev release. This sequence is guaranteed by driver file
|
|
operations. Therefore, there is no need to destroy an already empty
|
|
file_ida when the WQ cdev is removed.
|
|
|
|
Worse, ida_free() in cdev release may happen after destruction of
|
|
file_ida per WQ cdev. This can lead to accessing an id in file_ida
|
|
after it has been destroyed, resulting in a kernel panic.
|
|
|
|
Remove ida_destroy(&file_ida) to address these issues.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38629</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38630</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38634</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
greybus: lights: check return of get_channel_from_mode
|
|
|
|
If channel for the given node is not found we return null from
|
|
get_channel_from_mode. Make sure we validate the return pointer
|
|
before using it in two of the missing places.
|
|
|
|
This was originally reported in [0]:
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38637</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38662</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_dpsub: Always register bridgeWe must always register the DRM bridge, since zynqmp_dp_hpd_work_funccalls drm_bridge_hpd_notify, which in turn expects hpd_mutex to beinitialized. We do this before zynqmp_dpsub_drm_init since that callsdrm_bridge_attach. This fixes the following lockdep warning:[ 19.217084] ------------[ cut here ]------------[ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock)[ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550[ 19.241696] Modules linked in:[ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96[ 19.252046] Hardware name: xlnx,zynqmp (DT)[ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func[ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 19.269104] pc : __mutex_lock+0x4bc/0x550[ 19.273364] lr : __mutex_lock+0x4bc/0x550[ 19.277592] sp : ffffffc085c5bbe0[ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8[ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000[ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000[ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000[ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720[ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001[ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888[ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000[ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000[ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880[ 19.356581] Call trace:[ 19.359160] __mutex_lock+0x4bc/0x550[ 19.363032] mutex_lock_nested+0x24/0x30[ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c[ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54[ 19.376364] process_one_work+0x3ac/0x988[ 19.380660] worker_thread+0x398/0x694[ 19.384736] kthread+0x1bc/0x1c0[ 19.388241] ret_from_fork+0x10/0x20[ 19.392031] irq event stamp: 183[ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4[ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04[ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c[ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c[ 19.432614] ---[ end trace 0000000000000000 ]---(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38664</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ( dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context ) by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38780</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bonding: fix oops during rmmod
|
|
|
|
"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding:
|
|
remove redundant NULL check in debugfs function"). Here are the relevant
|
|
functions being called:
|
|
|
|
bonding_exit()
|
|
bond_destroy_debugfs()
|
|
debugfs_remove_recursive(bonding_debug_root);
|
|
bonding_debug_root = NULL; <--------- SET TO NULL HERE
|
|
bond_netlink_fini()
|
|
rtnl_link_unregister()
|
|
__rtnl_link_unregister()
|
|
unregister_netdevice_many_notify()
|
|
bond_uninit()
|
|
bond_debug_unregister()
|
|
(commit removed check for bonding_debug_root == NULL)
|
|
debugfs_remove()
|
|
simple_recursive_removal()
|
|
down_write() -> OOPS
|
|
|
|
However, reverting the bad commit does not solve the problem completely
|
|
because the original code contains a race that could cause the same
|
|
oops, although it was much less likely to be triggered unintentionally:
|
|
|
|
CPU1
|
|
rmmod bonding
|
|
bonding_exit()
|
|
bond_destroy_debugfs()
|
|
debugfs_remove_recursive(bonding_debug_root);
|
|
|
|
CPU2
|
|
echo -bond0 > /sys/class/net/bonding_masters
|
|
bond_uninit()
|
|
bond_debug_unregister()
|
|
if (!bonding_debug_root)
|
|
|
|
CPU1
|
|
bonding_debug_root = NULL;
|
|
|
|
So do NOT revert the bad commit (since the removed checks were racy
|
|
anyway), and instead change the order of actions taken during module
|
|
removal. The same oops can also happen if there is an error during
|
|
module init, so apply the same fix there.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39296</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/9p: fix uninit-value in p9_client_rpc()
|
|
|
|
Syzbot with the help of KMSAN reported the following error:
|
|
|
|
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
alloc_slab_page mm/slub.c:2175 [inline]
|
|
allocate_slab mm/slub.c:2338 [inline]
|
|
new_slab+0x2de/0x1400 mm/slub.c:2391
|
|
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
|
|
__slab_alloc mm/slub.c:3610 [inline]
|
|
__slab_alloc_node mm/slub.c:3663 [inline]
|
|
slab_alloc_node mm/slub.c:3835 [inline]
|
|
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
|
|
p9_tag_alloc net/9p/client.c:278 [inline]
|
|
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
|
|
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
|
|
will not be properly initialized. However, trace_9p_client_res()
|
|
ends up trying to print it out anyway before p9_client_rpc()
|
|
finishes.
|
|
|
|
Fix this issue by assigning default values to p9_fcall fields
|
|
such as 'tag' and (just in case KMSAN unearths something new) 'id'
|
|
during the tag allocation stage.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39301</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39362</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: check for non-NULL file pointer in io_file_can_poll()
|
|
|
|
In earlier kernels, it was possible to trigger a NULL pointer
|
|
dereference off the forced async preparation path, if no file had
|
|
been assigned. The trace leading to that looks as follows:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 00000000000000b0
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
|
|
RIP: 0010:io_buffer_select+0xc3/0x210
|
|
Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b
|
|
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
|
|
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
|
|
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
|
|
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
|
|
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
|
|
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
|
|
FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
|
|
Call Trace:
|
|
<TASK>
|
|
? __die+0x1f/0x60
|
|
? page_fault_oops+0x14d/0x420
|
|
? do_user_addr_fault+0x61/0x6a0
|
|
? exc_page_fault+0x6c/0x150
|
|
? asm_exc_page_fault+0x22/0x30
|
|
? io_buffer_select+0xc3/0x210
|
|
__io_import_iovec+0xb5/0x120
|
|
io_readv_prep_async+0x36/0x70
|
|
io_queue_sqe_fallback+0x20/0x260
|
|
io_submit_sqes+0x314/0x630
|
|
__do_sys_io_uring_enter+0x339/0xbc0
|
|
? __do_sys_io_uring_register+0x11b/0xc50
|
|
? vm_mmap_pgoff+0xce/0x160
|
|
do_syscall_64+0x5f/0x180
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0x55e0a110a67e
|
|
Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6
|
|
|
|
because the request is marked forced ASYNC and has a bad file fd, and
|
|
hence takes the forced async prep path.
|
|
|
|
Current kernels with the request async prep cleaned up can no longer hit
|
|
this issue, but for ease of backporting, let's add this safety check in
|
|
here too as it really doesn't hurt. For both cases, this will inevitably
|
|
end with a CQE posted with -EBADF.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39371</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: bcm: rpi: Assign ->num before accessing ->hws
|
|
|
|
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
|
|
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
|
|
with __counted_by, which informs the bounds sanitizer about the number
|
|
of elements in hws, so that it can warn when hws is accessed out of
|
|
bounds. As noted in that change, the __counted_by member must be
|
|
initialized with the number of elements before the first array access
|
|
happens, otherwise there will be a warning from each access prior to the
|
|
initialization because the number of elements is zero. This occurs in
|
|
raspberrypi_discover_clocks() due to ->num being assigned after ->hws
|
|
has been accessed:
|
|
|
|
UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4
|
|
index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
|
|
|
|
Move the ->num initialization to before the first access of ->hws, which
|
|
clears up the warning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39461</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
thermal/drivers/qcom/lmh: Check for SCM availability at probe
|
|
|
|
Up until now, the necessary scm availability check has not been
|
|
performed, leading to possible null pointer dereferences (which did
|
|
happen for me on RB1).
|
|
|
|
Fix that.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39466</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
|
|
|
|
syzbot reports a kernel bug as below:
|
|
|
|
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
|
|
==================================================================
|
|
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
|
|
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
|
|
|
|
CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-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
|
|
f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
|
|
current_nat_addr fs/f2fs/node.h:213 [inline]
|
|
f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
|
|
f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
|
|
f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
|
|
ioctl_fiemap fs/ioctl.c:220 [inline]
|
|
do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
|
|
__do_sys_ioctl fs/ioctl.c:902 [inline]
|
|
__se_sys_ioctl+0x81/0x170 fs/ioctl.c:890
|
|
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
|
|
|
|
The root cause is we missed to do sanity check on i_xattr_nid during
|
|
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
|
|
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
|
|
kasan bug report, fix it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39467</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
smb: client: fix deadlock in smb2_find_smb_tcon()
|
|
|
|
Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
|
|
deadlock.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39468</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
eventfs: Fix a possible null pointer dereference in eventfs_find_events()
|
|
|
|
In function eventfs_find_events,there is a potential null pointer
|
|
that may be caused by calling update_events_attr which will perform
|
|
some operations on the members of the ei struct when ei is NULL.
|
|
|
|
Hence,When ei->is_freed is set,return NULL directly.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39470</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |