3323 lines
140 KiB
XML
3323 lines
140 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-22.03-LTS-SP1</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-1838</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-22.03-LTS-SP1</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:
|
|
|
|
ARM: 9170/1: fix panic when kasan and kprobe are enabled
|
|
|
|
arm32 uses software to simulate the instruction replaced
|
|
by kprobe. some instructions may be simulated by constructing
|
|
assembly functions. therefore, before executing instruction
|
|
simulation, it is necessary to construct assembly function
|
|
execution environment in C language through binding registers.
|
|
after kasan is enabled, the register binding relationship will
|
|
be destroyed, resulting in instruction simulation errors and
|
|
causing kernel panic.
|
|
|
|
the kprobe emulate instruction function is distributed in three
|
|
files: actions-common.c actions-arm.c actions-thumb.c, so disable
|
|
KASAN when compiling these files.
|
|
|
|
for example, use kprobe insert on cap_capable+20 after kasan
|
|
enabled, the cap_capable assembly code is as follows:
|
|
<cap_capable>:
|
|
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
|
|
e1a05000 mov r5, r0
|
|
e280006c add r0, r0, #108 ; 0x6c
|
|
e1a04001 mov r4, r1
|
|
e1a06002 mov r6, r2
|
|
e59fa090 ldr sl, [pc, #144] ;
|
|
ebfc7bf8 bl c03aa4b4 <__asan_load4>
|
|
e595706c ldr r7, [r5, #108] ; 0x6c
|
|
e2859014 add r9, r5, #20
|
|
......
|
|
The emulate_ldr assembly code after enabling kasan is as follows:
|
|
c06f1384 <emulate_ldr>:
|
|
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
|
|
e282803c add r8, r2, #60 ; 0x3c
|
|
e1a05000 mov r5, r0
|
|
e7e37855 ubfx r7, r5, #16, #4
|
|
e1a00008 mov r0, r8
|
|
e1a09001 mov r9, r1
|
|
e1a04002 mov r4, r2
|
|
ebf35462 bl c03c6530 <__asan_load4>
|
|
e357000f cmp r7, #15
|
|
e7e36655 ubfx r6, r5, #12, #4
|
|
e205a00f and sl, r5, #15
|
|
0a000001 beq c06f13bc <emulate_ldr+0x38>
|
|
e0840107 add r0, r4, r7, lsl #2
|
|
ebf3545c bl c03c6530 <__asan_load4>
|
|
e084010a add r0, r4, sl, lsl #2
|
|
ebf3545a bl c03c6530 <__asan_load4>
|
|
e2890010 add r0, r9, #16
|
|
ebf35458 bl c03c6530 <__asan_load4>
|
|
e5990010 ldr r0, [r9, #16]
|
|
e12fff30 blx r0
|
|
e356000f cm r6, #15
|
|
1a000014 bne c06f1430 <emulate_ldr+0xac>
|
|
e1a06000 mov r6, r0
|
|
e2840040 add r0, r4, #64 ; 0x40
|
|
......
|
|
|
|
when running in emulate_ldr to simulate the ldr instruction, panic
|
|
occurred, and the log is as follows:
|
|
Unable to handle kernel NULL pointer dereference at virtual address
|
|
00000090
|
|
pgd = ecb46400
|
|
[00000090] *pgd=2e0fa003, *pmd=00000000
|
|
Internal error: Oops: 206 [#1] SMP ARM
|
|
PC is at cap_capable+0x14/0xb0
|
|
LR is at emulate_ldr+0x50/0xc0
|
|
psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
|
|
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
|
|
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98
|
|
r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
|
|
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
|
|
Control: 32c5387d Table: 2d546400 DAC: 55555555
|
|
Process bash (pid: 1643, stack limit = 0xecd60190)
|
|
(cap_capable) from (kprobe_handler+0x218/0x340)
|
|
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
|
|
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
|
|
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
|
|
(__und_svc_finish) from (cap_capable+0x18/0xb0)
|
|
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
|
|
(cap_vm_enough_memory) from
|
|
(security_vm_enough_memory_mm+0x48/0x6c)
|
|
(security_vm_enough_memory_mm) from
|
|
(copy_process.constprop.5+0x16b4/0x25c8)
|
|
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
|
|
(_do_fork) from (SyS_clone+0x1c/0x24)
|
|
(SyS_clone) from (__sys_trace_return+0x0/0x10)
|
|
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix use-after-free after failure to create a snapshot
|
|
|
|
At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
|
|
then attach it to the transaction's list of pending snapshots. After that
|
|
we call btrfs_commit_transaction(), and if that returns an error we jump
|
|
to 'fail' label, where we kfree() the pending snapshot structure. This can
|
|
result in a later use-after-free of the pending snapshot:
|
|
|
|
1) We allocated the pending snapshot and added it to the transaction's
|
|
list of pending snapshots;
|
|
|
|
2) We call btrfs_commit_transaction(), and it fails either at the first
|
|
call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
|
|
In both cases, we don't abort the transaction and we release our
|
|
transaction handle. We jump to the 'fail' label and free the pending
|
|
snapshot structure. We return with the pending snapshot still in the
|
|
transaction's list;
|
|
|
|
3) Another task commits the transaction. This time there's no error at
|
|
all, and then during the transaction commit it accesses a pointer
|
|
to the pending snapshot structure that the snapshot creation task
|
|
has already freed, resulting in a user-after-free.
|
|
|
|
This issue could actually be detected by smatch, which produced the
|
|
following warning:
|
|
|
|
fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list
|
|
|
|
So fix this by not having the snapshot creation ioctl directly add the
|
|
pending snapshot to the transaction's list. Instead add the pending
|
|
snapshot to the transaction handle, and then at btrfs_commit_transaction()
|
|
we add the snapshot to the list only when we can guarantee that any error
|
|
returned after that point will result in a transaction abort, in which
|
|
case the ioctl code can safely free the pending snapshot and no one can
|
|
access it anymore.(CVE-2022-48733)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: Avoid field-overflowing memcpy()
|
|
|
|
In preparation for FORTIFY_SOURCE performing compile-time and run-time
|
|
field bounds checking for memcpy(), memmove(), and memset(), avoid
|
|
intentionally writing across neighboring fields.
|
|
|
|
Use flexible arrays instead of zero-element arrays (which look like they
|
|
are always overflowing) and split the cross-field memcpy() into two halves
|
|
that can be appropriately bounds-checked by the compiler.
|
|
|
|
We were doing:
|
|
|
|
#define ETH_HLEN 14
|
|
#define VLAN_HLEN 4
|
|
...
|
|
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
|
|
...
|
|
struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);
|
|
...
|
|
struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
|
|
struct mlx5_wqe_data_seg *dseg = wqe->data;
|
|
...
|
|
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
|
|
|
|
target is wqe->eth.inline_hdr.start (which the compiler sees as being
|
|
2 bytes in size), but copying 18, intending to write across start
|
|
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
|
|
wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
|
|
(8 bytes).
|
|
|
|
struct mlx5e_tx_wqe {
|
|
struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */
|
|
struct mlx5_wqe_eth_seg eth; /* 16 16 */
|
|
struct mlx5_wqe_data_seg data[]; /* 32 0 */
|
|
|
|
/* size: 32, cachelines: 1, members: 3 */
|
|
/* last cacheline: 32 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_eth_seg {
|
|
u8 swp_outer_l4_offset; /* 0 1 */
|
|
u8 swp_outer_l3_offset; /* 1 1 */
|
|
u8 swp_inner_l4_offset; /* 2 1 */
|
|
u8 swp_inner_l3_offset; /* 3 1 */
|
|
u8 cs_flags; /* 4 1 */
|
|
u8 swp_flags; /* 5 1 */
|
|
__be16 mss; /* 6 2 */
|
|
__be32 flow_table_metadata; /* 8 4 */
|
|
union {
|
|
struct {
|
|
__be16 sz; /* 12 2 */
|
|
u8 start[2]; /* 14 2 */
|
|
} inline_hdr; /* 12 4 */
|
|
struct {
|
|
__be16 type; /* 12 2 */
|
|
__be16 vlan_tci; /* 14 2 */
|
|
} insert; /* 12 4 */
|
|
__be32 trailer; /* 12 4 */
|
|
}; /* 12 4 */
|
|
|
|
/* size: 16, cachelines: 1, members: 9 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_data_seg {
|
|
__be32 byte_count; /* 0 4 */
|
|
__be32 lkey; /* 4 4 */
|
|
__be64 addr; /* 8 8 */
|
|
|
|
/* size: 16, cachelines: 1, members: 3 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
So, split the memcpy() so the compiler can reason about the buffer
|
|
sizes.
|
|
|
|
"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
|
|
nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
|
|
code changes (i.e. only source line number induced differences and
|
|
optimizations).(CVE-2022-48744)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
|
|
|
|
The below warning is splatting during guest reboot.
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
|
|
CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5
|
|
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
kvm_vcpu_ioctl+0x279/0x710 [kvm]
|
|
__x64_sys_ioctl+0x83/0xb0
|
|
do_syscall_64+0x3b/0xc0
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7fd39797350b
|
|
|
|
This can be triggered by not exposing tsc-deadline mode and doing a reboot in
|
|
the guest. The lapic_shutdown() function which is called in sys_reboot path
|
|
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
|
|
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
|
|
switch between tsc-deadline and oneshot/periodic, which can result in preemption
|
|
timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
|
|
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
|
|
timer. Qemu will synchronise states around reset, let's cancel preemption timer
|
|
under KVM_SET_LAPIC.(CVE-2022-48765)
|
|
|
|
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:
|
|
|
|
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.(CVE-2023-52873)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
|
|
|
|
In the following sequence:
|
|
1) of_platform_depopulate()
|
|
2) of_overlay_remove()
|
|
|
|
During the step 1, devices are destroyed and devlinks are removed.
|
|
During the step 2, OF nodes are destroyed but
|
|
__of_changeset_entry_destroy() can raise warnings related to missing
|
|
of_node_put():
|
|
ERROR: memory leak, expected refcount 1 instead of 2 ...
|
|
|
|
Indeed, during the devlink removals performed at step 1, the removal
|
|
itself releasing the device (and the attached of_node) is done by a job
|
|
queued in a workqueue and so, it is done asynchronously with respect to
|
|
function calls.
|
|
When the warning is present, of_node_put() will be called but wrongly
|
|
too late from the workqueue job.
|
|
|
|
In order to be sure that any ongoing devlink removals are done before
|
|
the of_node destruction, synchronize the of_changeset_destroy() with the
|
|
devlink removals.(CVE-2024-35879)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_skbmod: prevent kernel-infoleak
|
|
|
|
syzbot found that tcf_skbmod_dump() was copying four bytes
|
|
from kernel stack to user space [1].
|
|
|
|
The issue here is that 'struct tc_skbmod' has a four bytes hole.
|
|
|
|
We need to clear the structure before filling fields.
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
copy_to_iter include/linux/uio.h:196 [inline]
|
|
simple_copy_to_iter net/core/datagram.c:532 [inline]
|
|
__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
|
|
netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
|
__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
|
|
__do_sys_recvfrom net/socket.c:2260 [inline]
|
|
__se_sys_recvfrom net/socket.c:2256 [inline]
|
|
__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
|
|
netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
|
|
netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
|
|
nlmsg_unicast include/net/netlink.h:1144 [inline]
|
|
nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
|
|
rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
|
|
rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2048 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
|
|
rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
|
netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
|
|
netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
__nla_put lib/nlattr.c:1041 [inline]
|
|
nla_put+0x1c6/0x230 lib/nlattr.c:1099
|
|
tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
|
|
tcf_action_dump_old net/sched/act_api.c:1191 [inline]
|
|
tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
|
|
tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
|
|
tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
|
|
tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2042 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
|
|
---truncated---(CVE-2024-35893)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
|
|
|
|
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
|
|
still means hlist_for_each_entry_rcu can return an item that got removed
|
|
from the list. The memory itself of such item is not freed thanks to RCU
|
|
but nothing guarantees the actual content of the memory is sane.
|
|
|
|
In particular, the reference count can be zero. This can happen if
|
|
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
|
|
from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
|
|
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
|
|
timing, this can happen:
|
|
|
|
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
|
|
|
|
2. Then, the whole ipv6_del_addr is executed for the given entry. The
|
|
reference count drops to zero and kfree_rcu is scheduled.
|
|
|
|
3. ipv6_get_ifaddr continues and tries to increments the reference count
|
|
(in6_ifa_hold).
|
|
|
|
4. The rcu is unlocked and the entry is freed.
|
|
|
|
5. The freed entry is returned.
|
|
|
|
Prevent increasing of the reference count in such case. The name
|
|
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
|
|
|
|
[ 41.506330] refcount_t: addition on 0; use-after-free.
|
|
[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
|
|
[ 41.507413] Modules linked in: veth bridge stp llc
|
|
[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
|
|
[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
|
|
[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
|
|
[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
|
|
[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
|
|
[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
|
|
[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
|
|
[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
|
|
[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
|
|
[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
|
|
[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
|
|
[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
|
|
[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 41.516799] Call Trace:
|
|
[ 41.517037] <TASK>
|
|
[ 41.517249] ? __warn+0x7b/0x120
|
|
[ 41.517535] ? refcount_warn_saturate+0xa5/0x130
|
|
[ 41.517923] ? report_bug+0x164/0x190
|
|
[ 41.518240] ? handle_bug+0x3d/0x70
|
|
[ 41.518541] ? exc_invalid_op+0x17/0x70
|
|
[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 41.521325] ? refcount_warn_saturate+0xa5/0x130
|
|
[ 41.521708] ipv6_get_ifaddr+0xda/0xe0
|
|
[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0
|
|
[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10
|
|
[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0
|
|
[ 41.523102] ? netlink_unicast+0x30f/0x390
|
|
[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
|
|
[ 41.523832] netlink_rcv_skb+0x53/0x100
|
|
[ 41.524157] netlink_unicast+0x23b/0x390
|
|
[ 41.524484] netlink_sendmsg+0x1f2/0x440
|
|
[ 41.524826] __sys_sendto+0x1d8/0x1f0
|
|
[ 41.525145] __x64_sys_sendto+0x1f/0x30
|
|
[ 41.525467] do_syscall_64+0xa5/0x1b0
|
|
[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
[ 41.526213] RIP: 0033:0x7fbc4cfcea9a
|
|
[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
|
|
[ 41.527942] RSP: 002b:00007f
|
|
---truncated---(CVE-2024-35969)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: Fix TASK_SIZE on 64-bit NOMMU
|
|
|
|
On NOMMU, userspace memory can come from anywhere in physical RAM. The
|
|
current definition of TASK_SIZE is wrong if any RAM exists above 4G,
|
|
causing spurious failures in the userspace access routines.(CVE-2024-35988)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
|
|
|
|
During the removal of the idxd driver, registered offline callback is
|
|
invoked as part of the clean up process. However, on systems with only
|
|
one CPU online, no valid target is available to migrate the
|
|
perf context, resulting in a kernel oops:
|
|
|
|
BUG: unable to handle page fault for address: 000000000002a2b8
|
|
#PF: supervisor write access in kernel mode
|
|
#PF: error_code(0x0002) - not-present page
|
|
PGD 1470e1067 P4D 0
|
|
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
|
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
|
|
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
|
|
RIP: 0010:mutex_lock+0x2e/0x50
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__die+0x24/0x70
|
|
page_fault_oops+0x82/0x160
|
|
do_user_addr_fault+0x65/0x6b0
|
|
__pfx___rdmsr_safe_on_cpu+0x10/0x10
|
|
exc_page_fault+0x7d/0x170
|
|
asm_exc_page_fault+0x26/0x30
|
|
mutex_lock+0x2e/0x50
|
|
mutex_lock+0x1e/0x50
|
|
perf_pmu_migrate_context+0x87/0x1f0
|
|
perf_event_cpu_offline+0x76/0x90 [idxd]
|
|
cpuhp_invoke_callback+0xa2/0x4f0
|
|
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
|
|
cpuhp_thread_fun+0x98/0x150
|
|
smpboot_thread_fn+0x27/0x260
|
|
smpboot_thread_fn+0x1af/0x260
|
|
__pfx_smpboot_thread_fn+0x10/0x10
|
|
kthread+0x103/0x140
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x31/0x50
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1b/0x30
|
|
<TASK>
|
|
|
|
Fix the issue by preventing the migration of the perf context to an
|
|
invalid target.(CVE-2024-35989)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/arm/malidp: fix a possible null pointer dereference
|
|
|
|
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
|
|
no check is performed. In order to prevent null pointer dereferencing,
|
|
ensure that mw_state is checked before calling
|
|
__drm_atomic_helper_connector_reset.(CVE-2024-36014)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
nfc: nci: Fix uninit-value in nci_rx_work
|
|
|
|
syzbot reported the following uninit-value access issue [1]
|
|
|
|
nci_rx_work() parses received packet from ndev->rx_q. It should be
|
|
validated header size, payload size and total packet size before
|
|
processing the packet. If an invalid packet is detected, it should be
|
|
silently discarded.(CVE-2024-38381)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
|
|
|
|
The allocation failure of mycs->yuv_scaler_binary in load_video_binaries()
|
|
is followed with a dereference of mycs->yuv_scaler_binary after the
|
|
following call chain:
|
|
|
|
sh_css_pipe_load_binaries()
|
|
|-> load_video_binaries(mycs->yuv_scaler_binary == NULL)
|
|
|
|
|
|-> sh_css_pipe_unload_binaries()
|
|
|-> unload_video_binaries()
|
|
|
|
In unload_video_binaries(), it calls to ia_css_binary_unload with argument
|
|
&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the
|
|
same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer
|
|
dereference is triggered.(CVE-2024-38547)
|
|
|
|
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:
|
|
|
|
net: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.(CVE-2024-38553)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
nilfs2: fix use-after-free of timer for log writer thread
|
|
|
|
Patch series "nilfs2: fix log writer related issues".
|
|
|
|
This bug fix series covers three nilfs2 log writer-related issues,
|
|
including a timer use-after-free issue and potential deadlock issue on
|
|
unmount, and a potential freeze issue in event synchronization found
|
|
during their analysis. Details are described in each commit log.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
A use-after-free issue has been reported regarding the timer sc_timer on
|
|
the nilfs_sc_info structure.
|
|
|
|
The problem is that even though it is used to wake up a sleeping log
|
|
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
|
|
is about to be freed, and is used regardless of the thread's lifetime.
|
|
|
|
Fix this issue by limiting the use of sc_timer only while the log writer
|
|
thread is alive.(CVE-2024-38583)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/hns: Modify the print level of CQE error
|
|
|
|
Too much print may lead to a panic in kernel. Change ibdev_err() to
|
|
ibdev_err_ratelimited(), and change the printing level of cqe dump
|
|
to debug level.(CVE-2024-38590)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)
|
|
|
|
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:
|
|
|
|
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
|
|
|
|
pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
|
|
fails, the irq vector is not freed, which leads to a memory leak.
|
|
|
|
Replace the devm_add_action with devm_add_action_or_reset to ensure
|
|
the irq vector can be destroyed when it fails.(CVE-2024-38603)
|
|
|
|
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:
|
|
|
|
serial: max3100: Update uart_driver_registered on driver removal
|
|
|
|
The removal of the last MAX3100 device triggers the removal of
|
|
the driver. However, code doesn't update the respective global
|
|
variable and after insmod — rmmod — insmod cycle the kernel
|
|
oopses:
|
|
|
|
max3100 spi-PRP0001:01: max3100_probe: adding port 0
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000408
|
|
...
|
|
RIP: 0010:serial_core_register_port+0xa0/0x840
|
|
...
|
|
max3100_probe+0x1b6/0x280 [max3100]
|
|
spi_probe+0x8d/0xb0
|
|
|
|
Update the actual state so next time UART driver will be registered
|
|
again.
|
|
|
|
Hugo also noticed, that the error path in the probe also affected
|
|
by having the variable set, and not cleared. Instead of clearing it
|
|
move the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. 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">High</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-1838</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47618</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48733</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48744</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48765</URL>
|
|
<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-2023-52873</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35879</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35893</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35969</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35988</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35989</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36014</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-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-38381</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38547</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-38553</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-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-38583</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38590</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38596</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-38603</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-38633</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-38780</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-39467</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48733</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48744</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48765</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48772</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52873</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35879</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35893</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35969</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35988</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35989</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36014</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36489</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-38381</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38547</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38552</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38553</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38554</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-38583</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38590</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38596</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38602</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38603</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38625</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38637</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38780</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-39467</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.84.0.165.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.84.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.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:
|
|
|
|
ARM: 9170/1: fix panic when kasan and kprobe are enabled
|
|
|
|
arm32 uses software to simulate the instruction replaced
|
|
by kprobe. some instructions may be simulated by constructing
|
|
assembly functions. therefore, before executing instruction
|
|
simulation, it is necessary to construct assembly function
|
|
execution environment in C language through binding registers.
|
|
after kasan is enabled, the register binding relationship will
|
|
be destroyed, resulting in instruction simulation errors and
|
|
causing kernel panic.
|
|
|
|
the kprobe emulate instruction function is distributed in three
|
|
files: actions-common.c actions-arm.c actions-thumb.c, so disable
|
|
KASAN when compiling these files.
|
|
|
|
for example, use kprobe insert on cap_capable+20 after kasan
|
|
enabled, the cap_capable assembly code is as follows:
|
|
<cap_capable>:
|
|
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
|
|
e1a05000 mov r5, r0
|
|
e280006c add r0, r0, #108 ; 0x6c
|
|
e1a04001 mov r4, r1
|
|
e1a06002 mov r6, r2
|
|
e59fa090 ldr sl, [pc, #144] ;
|
|
ebfc7bf8 bl c03aa4b4 <__asan_load4>
|
|
e595706c ldr r7, [r5, #108] ; 0x6c
|
|
e2859014 add r9, r5, #20
|
|
......
|
|
The emulate_ldr assembly code after enabling kasan is as follows:
|
|
c06f1384 <emulate_ldr>:
|
|
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
|
|
e282803c add r8, r2, #60 ; 0x3c
|
|
e1a05000 mov r5, r0
|
|
e7e37855 ubfx r7, r5, #16, #4
|
|
e1a00008 mov r0, r8
|
|
e1a09001 mov r9, r1
|
|
e1a04002 mov r4, r2
|
|
ebf35462 bl c03c6530 <__asan_load4>
|
|
e357000f cmp r7, #15
|
|
e7e36655 ubfx r6, r5, #12, #4
|
|
e205a00f and sl, r5, #15
|
|
0a000001 beq c06f13bc <emulate_ldr+0x38>
|
|
e0840107 add r0, r4, r7, lsl #2
|
|
ebf3545c bl c03c6530 <__asan_load4>
|
|
e084010a add r0, r4, sl, lsl #2
|
|
ebf3545a bl c03c6530 <__asan_load4>
|
|
e2890010 add r0, r9, #16
|
|
ebf35458 bl c03c6530 <__asan_load4>
|
|
e5990010 ldr r0, [r9, #16]
|
|
e12fff30 blx r0
|
|
e356000f cm r6, #15
|
|
1a000014 bne c06f1430 <emulate_ldr+0xac>
|
|
e1a06000 mov r6, r0
|
|
e2840040 add r0, r4, #64 ; 0x40
|
|
......
|
|
|
|
when running in emulate_ldr to simulate the ldr instruction, panic
|
|
occurred, and the log is as follows:
|
|
Unable to handle kernel NULL pointer dereference at virtual address
|
|
00000090
|
|
pgd = ecb46400
|
|
[00000090] *pgd=2e0fa003, *pmd=00000000
|
|
Internal error: Oops: 206 [#1] SMP ARM
|
|
PC is at cap_capable+0x14/0xb0
|
|
LR is at emulate_ldr+0x50/0xc0
|
|
psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
|
|
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
|
|
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98
|
|
r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
|
|
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
|
|
Control: 32c5387d Table: 2d546400 DAC: 55555555
|
|
Process bash (pid: 1643, stack limit = 0xecd60190)
|
|
(cap_capable) from (kprobe_handler+0x218/0x340)
|
|
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
|
|
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
|
|
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
|
|
(__und_svc_finish) from (cap_capable+0x18/0xb0)
|
|
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
|
|
(cap_vm_enough_memory) from
|
|
(security_vm_enough_memory_mm+0x48/0x6c)
|
|
(security_vm_enough_memory_mm) from
|
|
(copy_process.constprop.5+0x16b4/0x25c8)
|
|
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
|
|
(_do_fork) from (SyS_clone+0x1c/0x24)
|
|
(SyS_clone) from (__sys_trace_return+0x0/0x10)
|
|
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47618</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
btrfs: fix use-after-free after failure to create a snapshot
|
|
|
|
At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
|
|
then attach it to the transaction's list of pending snapshots. After that
|
|
we call btrfs_commit_transaction(), and if that returns an error we jump
|
|
to 'fail' label, where we kfree() the pending snapshot structure. This can
|
|
result in a later use-after-free of the pending snapshot:
|
|
|
|
1) We allocated the pending snapshot and added it to the transaction's
|
|
list of pending snapshots;
|
|
|
|
2) We call btrfs_commit_transaction(), and it fails either at the first
|
|
call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
|
|
In both cases, we don't abort the transaction and we release our
|
|
transaction handle. We jump to the 'fail' label and free the pending
|
|
snapshot structure. We return with the pending snapshot still in the
|
|
transaction's list;
|
|
|
|
3) Another task commits the transaction. This time there's no error at
|
|
all, and then during the transaction commit it accesses a pointer
|
|
to the pending snapshot structure that the snapshot creation task
|
|
has already freed, resulting in a user-after-free.
|
|
|
|
This issue could actually be detected by smatch, which produced the
|
|
following warning:
|
|
|
|
fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list
|
|
|
|
So fix this by not having the snapshot creation ioctl directly add the
|
|
pending snapshot to the transaction's list. Instead add the pending
|
|
snapshot to the transaction handle, and then at btrfs_commit_transaction()
|
|
we add the snapshot to the list only when we can guarantee that any error
|
|
returned after that point will result in a transaction abort, in which
|
|
case the ioctl code can safely free the pending snapshot and no one can
|
|
access it anymore.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48733</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/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-1838</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:
|
|
|
|
net/mlx5e: Avoid field-overflowing memcpy()
|
|
|
|
In preparation for FORTIFY_SOURCE performing compile-time and run-time
|
|
field bounds checking for memcpy(), memmove(), and memset(), avoid
|
|
intentionally writing across neighboring fields.
|
|
|
|
Use flexible arrays instead of zero-element arrays (which look like they
|
|
are always overflowing) and split the cross-field memcpy() into two halves
|
|
that can be appropriately bounds-checked by the compiler.
|
|
|
|
We were doing:
|
|
|
|
#define ETH_HLEN 14
|
|
#define VLAN_HLEN 4
|
|
...
|
|
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
|
|
...
|
|
struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);
|
|
...
|
|
struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
|
|
struct mlx5_wqe_data_seg *dseg = wqe->data;
|
|
...
|
|
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
|
|
|
|
target is wqe->eth.inline_hdr.start (which the compiler sees as being
|
|
2 bytes in size), but copying 18, intending to write across start
|
|
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
|
|
wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
|
|
(8 bytes).
|
|
|
|
struct mlx5e_tx_wqe {
|
|
struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */
|
|
struct mlx5_wqe_eth_seg eth; /* 16 16 */
|
|
struct mlx5_wqe_data_seg data[]; /* 32 0 */
|
|
|
|
/* size: 32, cachelines: 1, members: 3 */
|
|
/* last cacheline: 32 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_eth_seg {
|
|
u8 swp_outer_l4_offset; /* 0 1 */
|
|
u8 swp_outer_l3_offset; /* 1 1 */
|
|
u8 swp_inner_l4_offset; /* 2 1 */
|
|
u8 swp_inner_l3_offset; /* 3 1 */
|
|
u8 cs_flags; /* 4 1 */
|
|
u8 swp_flags; /* 5 1 */
|
|
__be16 mss; /* 6 2 */
|
|
__be32 flow_table_metadata; /* 8 4 */
|
|
union {
|
|
struct {
|
|
__be16 sz; /* 12 2 */
|
|
u8 start[2]; /* 14 2 */
|
|
} inline_hdr; /* 12 4 */
|
|
struct {
|
|
__be16 type; /* 12 2 */
|
|
__be16 vlan_tci; /* 14 2 */
|
|
} insert; /* 12 4 */
|
|
__be32 trailer; /* 12 4 */
|
|
}; /* 12 4 */
|
|
|
|
/* size: 16, cachelines: 1, members: 9 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_data_seg {
|
|
__be32 byte_count; /* 0 4 */
|
|
__be32 lkey; /* 4 4 */
|
|
__be64 addr; /* 8 8 */
|
|
|
|
/* size: 16, cachelines: 1, members: 3 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
So, split the memcpy() so the compiler can reason about the buffer
|
|
sizes.
|
|
|
|
"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
|
|
nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
|
|
code changes (i.e. only source line number induced differences and
|
|
optimizations).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48744</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
|
|
|
|
The below warning is splatting during guest reboot.
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
|
|
CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5
|
|
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
kvm_vcpu_ioctl+0x279/0x710 [kvm]
|
|
__x64_sys_ioctl+0x83/0xb0
|
|
do_syscall_64+0x3b/0xc0
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7fd39797350b
|
|
|
|
This can be triggered by not exposing tsc-deadline mode and doing a reboot in
|
|
the guest. The lapic_shutdown() function which is called in sys_reboot path
|
|
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
|
|
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
|
|
switch between tsc-deadline and oneshot/periodic, which can result in preemption
|
|
timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
|
|
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
|
|
timer. Qemu will synchronise states around reset, let's cancel preemption timer
|
|
under KVM_SET_LAPIC.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48765</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2023-52873</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
|
|
|
|
In the following sequence:
|
|
1) of_platform_depopulate()
|
|
2) of_overlay_remove()
|
|
|
|
During the step 1, devices are destroyed and devlinks are removed.
|
|
During the step 2, OF nodes are destroyed but
|
|
__of_changeset_entry_destroy() can raise warnings related to missing
|
|
of_node_put():
|
|
ERROR: memory leak, expected refcount 1 instead of 2 ...
|
|
|
|
Indeed, during the devlink removals performed at step 1, the removal
|
|
itself releasing the device (and the attached of_node) is done by a job
|
|
queued in a workqueue and so, it is done asynchronously with respect to
|
|
function calls.
|
|
When the warning is present, of_node_put() will be called but wrongly
|
|
too late from the workqueue job.
|
|
|
|
In order to be sure that any ongoing devlink removals are done before
|
|
the of_node destruction, synchronize the of_changeset_destroy() with the
|
|
devlink removals.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35879</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
net/sched: act_skbmod: prevent kernel-infoleak
|
|
|
|
syzbot found that tcf_skbmod_dump() was copying four bytes
|
|
from kernel stack to user space [1].
|
|
|
|
The issue here is that 'struct tc_skbmod' has a four bytes hole.
|
|
|
|
We need to clear the structure before filling fields.
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
copy_to_iter include/linux/uio.h:196 [inline]
|
|
simple_copy_to_iter net/core/datagram.c:532 [inline]
|
|
__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
|
|
netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
|
__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
|
|
__do_sys_recvfrom net/socket.c:2260 [inline]
|
|
__se_sys_recvfrom net/socket.c:2256 [inline]
|
|
__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
|
|
netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
|
|
netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
|
|
nlmsg_unicast include/net/netlink.h:1144 [inline]
|
|
nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
|
|
rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
|
|
rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2048 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
|
|
rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
|
netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
|
|
netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
__nla_put lib/nlattr.c:1041 [inline]
|
|
nla_put+0x1c6/0x230 lib/nlattr.c:1099
|
|
tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
|
|
tcf_action_dump_old net/sched/act_api.c:1191 [inline]
|
|
tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
|
|
tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
|
|
tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
|
|
tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2042 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35893</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
|
|
|
|
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
|
|
still means hlist_for_each_entry_rcu can return an item that got removed
|
|
from the list. The memory itself of such item is not freed thanks to RCU
|
|
but nothing guarantees the actual content of the memory is sane.
|
|
|
|
In particular, the reference count can be zero. This can happen if
|
|
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
|
|
from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
|
|
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
|
|
timing, this can happen:
|
|
|
|
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
|
|
|
|
2. Then, the whole ipv6_del_addr is executed for the given entry. The
|
|
reference count drops to zero and kfree_rcu is scheduled.
|
|
|
|
3. ipv6_get_ifaddr continues and tries to increments the reference count
|
|
(in6_ifa_hold).
|
|
|
|
4. The rcu is unlocked and the entry is freed.
|
|
|
|
5. The freed entry is returned.
|
|
|
|
Prevent increasing of the reference count in such case. The name
|
|
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
|
|
|
|
[ 41.506330] refcount_t: addition on 0; use-after-free.
|
|
[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
|
|
[ 41.507413] Modules linked in: veth bridge stp llc
|
|
[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
|
|
[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
|
|
[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
|
|
[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
|
|
[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
|
|
[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
|
|
[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
|
|
[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
|
|
[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
|
|
[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
|
|
[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
|
|
[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
|
|
[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 41.516799] Call Trace:
|
|
[ 41.517037] <TASK>
|
|
[ 41.517249] ? __warn+0x7b/0x120
|
|
[ 41.517535] ? refcount_warn_saturate+0xa5/0x130
|
|
[ 41.517923] ? report_bug+0x164/0x190
|
|
[ 41.518240] ? handle_bug+0x3d/0x70
|
|
[ 41.518541] ? exc_invalid_op+0x17/0x70
|
|
[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 41.521325] ? refcount_warn_saturate+0xa5/0x130
|
|
[ 41.521708] ipv6_get_ifaddr+0xda/0xe0
|
|
[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0
|
|
[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10
|
|
[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0
|
|
[ 41.523102] ? netlink_unicast+0x30f/0x390
|
|
[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
|
|
[ 41.523832] netlink_rcv_skb+0x53/0x100
|
|
[ 41.524157] netlink_unicast+0x23b/0x390
|
|
[ 41.524484] netlink_sendmsg+0x1f2/0x440
|
|
[ 41.524826] __sys_sendto+0x1d8/0x1f0
|
|
[ 41.525145] __x64_sys_sendto+0x1f/0x30
|
|
[ 41.525467] do_syscall_64+0xa5/0x1b0
|
|
[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
[ 41.526213] RIP: 0033:0x7fbc4cfcea9a
|
|
[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
|
|
[ 41.527942] RSP: 002b:00007f
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35969</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
riscv: Fix TASK_SIZE on 64-bit NOMMU
|
|
|
|
On NOMMU, userspace memory can come from anywhere in physical RAM. The
|
|
current definition of TASK_SIZE is wrong if any RAM exists above 4G,
|
|
causing spurious failures in the userspace access routines.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35988</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
|
|
|
|
During the removal of the idxd driver, registered offline callback is
|
|
invoked as part of the clean up process. However, on systems with only
|
|
one CPU online, no valid target is available to migrate the
|
|
perf context, resulting in a kernel oops:
|
|
|
|
BUG: unable to handle page fault for address: 000000000002a2b8
|
|
#PF: supervisor write access in kernel mode
|
|
#PF: error_code(0x0002) - not-present page
|
|
PGD 1470e1067 P4D 0
|
|
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
|
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
|
|
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
|
|
RIP: 0010:mutex_lock+0x2e/0x50
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__die+0x24/0x70
|
|
page_fault_oops+0x82/0x160
|
|
do_user_addr_fault+0x65/0x6b0
|
|
__pfx___rdmsr_safe_on_cpu+0x10/0x10
|
|
exc_page_fault+0x7d/0x170
|
|
asm_exc_page_fault+0x26/0x30
|
|
mutex_lock+0x2e/0x50
|
|
mutex_lock+0x1e/0x50
|
|
perf_pmu_migrate_context+0x87/0x1f0
|
|
perf_event_cpu_offline+0x76/0x90 [idxd]
|
|
cpuhp_invoke_callback+0xa2/0x4f0
|
|
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
|
|
cpuhp_thread_fun+0x98/0x150
|
|
smpboot_thread_fn+0x27/0x260
|
|
smpboot_thread_fn+0x1af/0x260
|
|
__pfx_smpboot_thread_fn+0x10/0x10
|
|
kthread+0x103/0x140
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x31/0x50
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1b/0x30
|
|
<TASK>
|
|
|
|
Fix the issue by preventing the migration of the perf context to an
|
|
invalid target.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35989</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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/arm/malidp: fix a possible null pointer dereference
|
|
|
|
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
|
|
no check is performed. In order to prevent null pointer dereferencing,
|
|
ensure that mw_state is checked before calling
|
|
__drm_atomic_helper_connector_reset.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36014</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
nfc: nci: Fix uninit-value in nci_rx_work
|
|
|
|
syzbot reported the following uninit-value access issue [1]
|
|
|
|
nci_rx_work() parses received packet from ndev->rx_q. It should be
|
|
validated header size, payload size and total packet size before
|
|
processing the packet. If an invalid packet is detected, it should be
|
|
silently discarded.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38381</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/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-1838</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:
|
|
|
|
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
|
|
|
|
The allocation failure of mycs->yuv_scaler_binary in load_video_binaries()
|
|
is followed with a dereference of mycs->yuv_scaler_binary after the
|
|
following call chain:
|
|
|
|
sh_css_pipe_load_binaries()
|
|
|-> load_video_binaries(mycs->yuv_scaler_binary == NULL)
|
|
|
|
|
|-> sh_css_pipe_unload_binaries()
|
|
|-> unload_video_binaries()
|
|
|
|
In unload_video_binaries(), it calls to ia_css_binary_unload with argument
|
|
&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the
|
|
same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer
|
|
dereference is triggered.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38547</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
net: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38553</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
nilfs2: fix use-after-free of timer for log writer thread
|
|
|
|
Patch series "nilfs2: fix log writer related issues".
|
|
|
|
This bug fix series covers three nilfs2 log writer-related issues,
|
|
including a timer use-after-free issue and potential deadlock issue on
|
|
unmount, and a potential freeze issue in event synchronization found
|
|
during their analysis. Details are described in each commit log.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
A use-after-free issue has been reported regarding the timer sc_timer on
|
|
the nilfs_sc_info structure.
|
|
|
|
The problem is that even though it is used to wake up a sleeping log
|
|
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
|
|
is about to be freed, and is used regardless of the thread's lifetime.
|
|
|
|
Fix this issue by limiting the use of sc_timer only while the log writer
|
|
thread is alive.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38583</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/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-1838</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:
|
|
|
|
RDMA/hns: Modify the print level of CQE error
|
|
|
|
Too much print may lead to a panic in kernel. Change ibdev_err() to
|
|
ibdev_err_ratelimited(), and change the printing level of cqe dump
|
|
to debug level.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38590</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38596</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>2.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
|
|
|
|
pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
|
|
fails, the irq vector is not freed, which leads to a memory leak.
|
|
|
|
Replace the devm_add_action with devm_add_action_or_reset to ensure
|
|
the irq vector can be destroyed when it fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38603</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
serial: max3100: Update uart_driver_registered on driver removal
|
|
|
|
The removal of the last MAX3100 device triggers the removal of
|
|
the driver. However, code doesn't update the respective global
|
|
variable and after insmod — rmmod — insmod cycle the kernel
|
|
oopses:
|
|
|
|
max3100 spi-PRP0001:01: max3100_probe: adding port 0
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000408
|
|
...
|
|
RIP: 0010:serial_core_register_port+0xa0/0x840
|
|
...
|
|
max3100_probe+0x1b6/0x280 [max3100]
|
|
spi_probe+0x8d/0xb0
|
|
|
|
Update the actual state so next time UART driver will be registered
|
|
again.
|
|
|
|
Hugo also noticed, that the error path in the probe also affected
|
|
by having the variable set, and not cleared. Instead of clearing it
|
|
move the assignment after the successfull uart_register_driver() call.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38633</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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: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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</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">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-22.03-LTS-SP1</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-1838</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:
|
|
|
|
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-22.03-LTS-SP1</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-1838</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |