3599 lines
151 KiB
XML
3599 lines
151 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-SP3</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-1839</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-SP3</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:
|
||
|
|
|
||
|
|
ASoC: SOF: Fix DSP oops stack dump output contents
|
||
|
|
|
||
|
|
Fix @buf arg given to hex_dump_to_buffer() and stack address used
|
||
|
|
in dump error output.(CVE-2021-47381)
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
Bluetooth: btusb: Add date->evt_skb is NULL check
|
||
|
|
|
||
|
|
fix crash because of null pointers
|
||
|
|
|
||
|
|
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
|
||
|
|
[ 6104.969667] #PF: supervisor read access in kernel mode
|
||
|
|
[ 6104.969668] #PF: error_code(0x0000) - not-present page
|
||
|
|
[ 6104.969670] PGD 0 P4D 0
|
||
|
|
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
|
||
|
|
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
|
||
|
|
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
|
||
|
|
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
|
||
|
|
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
|
||
|
|
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
|
||
|
|
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
|
||
|
|
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
|
||
|
|
[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
|
||
|
|
[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
|
|
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
|
||
|
|
[ 6104.969701] PKRU: 55555554
|
||
|
|
[ 6104.969702] Call Trace:
|
||
|
|
[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]
|
||
|
|
[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]
|
||
|
|
[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
|
||
|
|
[ 6104.969753] rfkill_set_block+0x92/0x160
|
||
|
|
[ 6104.969755] rfkill_fop_write+0x136/0x1e0
|
||
|
|
[ 6104.969759] __vfs_write+0x18/0x40
|
||
|
|
[ 6104.969761] vfs_write+0xdf/0x1c0
|
||
|
|
[ 6104.969763] ksys_write+0xb1/0xe0
|
||
|
|
[ 6104.969765] __x64_sys_write+0x1a/0x20
|
||
|
|
[ 6104.969769] do_syscall_64+0x51/0x180
|
||
|
|
[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
||
|
|
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
|
||
|
|
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
||
|
|
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
|
||
|
|
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
|
||
|
|
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
|
||
|
|
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
|
||
|
|
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
||
|
|
|
||
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
||
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
||
|
|
deferred until the next instance of the interrupt being triggered on the
|
||
|
|
original CPU.
|
||
|
|
|
||
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
||
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
||
|
|
but the old vector on the original CPU remains and is not immediately
|
||
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
||
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
||
|
|
|
||
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
||
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
||
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
||
|
|
vector_cleanup list, reclaiming old vectors.
|
||
|
|
|
||
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
||
|
|
interrupt triggers again on the new CPU.
|
||
|
|
|
||
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
||
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
||
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
||
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
||
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
||
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
||
|
|
|
||
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
||
|
|
CPU vector leak.
|
||
|
|
|
||
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
||
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
||
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
||
|
|
|
||
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
||
|
|
following a warning message, although theoretically it should never see
|
||
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
md: fix resync softlockup when bitmap size is less than array size
|
||
|
|
|
||
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
||
|
|
trigger following softlockup:
|
||
|
|
|
||
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
||
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
||
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
||
|
|
Call Trace:
|
||
|
|
<TASK>
|
||
|
|
md_bitmap_start_sync+0x6b/0xf0
|
||
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
||
|
|
md_do_sync+0x64b/0x1020
|
||
|
|
md_thread+0xa7/0x170
|
||
|
|
kthread+0xcf/0x100
|
||
|
|
ret_from_fork+0x30/0x50
|
||
|
|
ret_from_fork_asm+0x1a/0x30
|
||
|
|
|
||
|
|
And the detailed process is as follows:
|
||
|
|
|
||
|
|
md_do_sync
|
||
|
|
j = mddev->resync_min
|
||
|
|
while (j < max_sectors)
|
||
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
||
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
||
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
||
|
|
return sync_blocks + sectors_skippe;
|
||
|
|
// sectors = 0;
|
||
|
|
j += sectors;
|
||
|
|
// j never change
|
||
|
|
|
||
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
||
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
||
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
||
|
|
|
||
|
|
Fix this problem by always set returned blocks from
|
||
|
|
md_bitmap_get_counter"(), as it used to be.
|
||
|
|
|
||
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
||
|
|
case that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
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:
|
||
|
|
|
||
|
|
cpufreq: exit() callback is optional
|
||
|
|
|
||
|
|
The exit() callback is optional and shouldn't be called without checking
|
||
|
|
a valid pointer first.
|
||
|
|
|
||
|
|
Also, we must clear freq_table pointer even if the exit() callback isn't
|
||
|
|
present.(CVE-2024-38615)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
media: stk1160: fix bounds checking in stk1160_copy_video()
|
||
|
|
|
||
|
|
The subtract in this condition is reversed. The ->length is the length
|
||
|
|
of the buffer. The ->bytesused is how many bytes we have copied thus
|
||
|
|
far. When the condition is reversed that means the result of the
|
||
|
|
subtraction is always negative but since it's unsigned then the result
|
||
|
|
is a very high positive value. That means the overflow check is never
|
||
|
|
true.
|
||
|
|
|
||
|
|
Additionally, the ->bytesused doesn't actually work for this purpose
|
||
|
|
because we're not writing to "buf->mem + buf->bytesused". Instead, the
|
||
|
|
math to calculate the destination where we are writing is a bit
|
||
|
|
involved. You calculate the number of full lines already written,
|
||
|
|
multiply by two, skip a line if necessary so that we start on an odd
|
||
|
|
numbered line, and add the offset into the line.
|
||
|
|
|
||
|
|
To fix this buffer overflow, just take the actual destination where we
|
||
|
|
are writing, if the offset is already out of bounds print an error and
|
||
|
|
return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
fs/ntfs3: Use variable length array instead of fixed size
|
||
|
|
|
||
|
|
Should fix smatch warning:
|
||
|
|
ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)(CVE-2024-38623)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
fs/ntfs3: 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:
|
||
|
|
|
||
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
||
|
|
|
||
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
||
|
|
Since we run it in a separate work, the lock may not be taken at
|
||
|
|
the time of running. Make sure that it's taken by explicitly doing
|
||
|
|
that. Without it we got a splat:
|
||
|
|
|
||
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
||
|
|
...
|
||
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
||
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
||
|
|
...
|
||
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
||
|
|
max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
greybus: lights: check return of get_channel_from_mode
|
||
|
|
|
||
|
|
If channel for the given node is not found we return null from
|
||
|
|
get_channel_from_mode. Make sure we validate the return pointer
|
||
|
|
before using it in two of the missing places.
|
||
|
|
|
||
|
|
This was originally reported in [0]:
|
||
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
||
|
|
|
||
|
|
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)
|
||
|
|
|
||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
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-SP3.
|
||
|
|
|
||
|
|
openEuler Security has rated this update as having a security impact of critical. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
||
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Critical</Note>
|
||
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
||
|
|
</DocumentNotes>
|
||
|
|
<DocumentReferences>
|
||
|
|
<Reference Type="Self">
|
||
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
|
||
|
|
</Reference>
|
||
|
|
<Reference Type="openEuler CVE">
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47381</URL>
|
||
|
|
<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-52833</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-31076</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-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-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-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-38598</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-38615</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38621</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38623</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-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-38634</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38637</URL>
|
||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-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-47381</URL>
|
||
|
|
<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-52833</URL>
|
||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-31076</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-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-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-38598</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-38615</URL>
|
||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38621</URL>
|
||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38623</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-38634</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-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
||
|
|
</Branch>
|
||
|
|
<Branch Type="Package Arch" Name="x86_64">
|
||
|
|
<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-source-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="python3-perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
|
||
|
|
</Branch>
|
||
|
|
<Branch Type="Package Arch" Name="aarch64">
|
||
|
|
<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-source-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="python3-perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
|
||
|
|
</Branch>
|
||
|
|
<Branch Type="Package Arch" Name="src">
|
||
|
|
<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.src.rpm</FullProductName>
|
||
|
|
</Branch>
|
||
|
|
</ProductTree>
|
||
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
ASoC: SOF: Fix DSP oops stack dump output contents
|
||
|
|
|
||
|
|
Fix @buf arg given to hex_dump_to_buffer() and stack address used
|
||
|
|
in dump error output.</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2021-47381</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
Bluetooth: btusb: Add date->evt_skb is NULL check
|
||
|
|
|
||
|
|
fix crash because of null pointers
|
||
|
|
|
||
|
|
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
|
||
|
|
[ 6104.969667] #PF: supervisor read access in kernel mode
|
||
|
|
[ 6104.969668] #PF: error_code(0x0000) - not-present page
|
||
|
|
[ 6104.969670] PGD 0 P4D 0
|
||
|
|
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
|
||
|
|
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
|
||
|
|
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
|
||
|
|
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
|
||
|
|
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
|
||
|
|
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
|
||
|
|
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
|
||
|
|
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
|
||
|
|
[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
|
||
|
|
[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
|
|
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
|
||
|
|
[ 6104.969701] PKRU: 55555554
|
||
|
|
[ 6104.969702] Call Trace:
|
||
|
|
[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]
|
||
|
|
[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]
|
||
|
|
[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
|
||
|
|
[ 6104.969753] rfkill_set_block+0x92/0x160
|
||
|
|
[ 6104.969755] rfkill_fop_write+0x136/0x1e0
|
||
|
|
[ 6104.969759] __vfs_write+0x18/0x40
|
||
|
|
[ 6104.969761] vfs_write+0xdf/0x1c0
|
||
|
|
[ 6104.969763] ksys_write+0xb1/0xe0
|
||
|
|
[ 6104.969765] __x64_sys_write+0x1a/0x20
|
||
|
|
[ 6104.969769] do_syscall_64+0x51/0x180
|
||
|
|
[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
||
|
|
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
|
||
|
|
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
||
|
|
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
|
||
|
|
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
|
||
|
|
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
|
||
|
|
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
|
||
|
|
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2023-52833</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
||
|
|
|
||
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
||
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
||
|
|
deferred until the next instance of the interrupt being triggered on the
|
||
|
|
original CPU.
|
||
|
|
|
||
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
||
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
||
|
|
but the old vector on the original CPU remains and is not immediately
|
||
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
||
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
||
|
|
|
||
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
||
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
||
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
||
|
|
vector_cleanup list, reclaiming old vectors.
|
||
|
|
|
||
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
||
|
|
interrupt triggers again on the new CPU.
|
||
|
|
|
||
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
||
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
||
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
||
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
||
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
||
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
||
|
|
|
||
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
||
|
|
CPU vector leak.
|
||
|
|
|
||
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
||
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
||
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
||
|
|
|
||
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
||
|
|
following a warning message, although theoretically it should never see
|
||
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-31076</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
md: fix resync softlockup when bitmap size is less than array size
|
||
|
|
|
||
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
||
|
|
trigger following softlockup:
|
||
|
|
|
||
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
||
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
||
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
||
|
|
Call Trace:
|
||
|
|
<TASK>
|
||
|
|
md_bitmap_start_sync+0x6b/0xf0
|
||
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
||
|
|
md_do_sync+0x64b/0x1020
|
||
|
|
md_thread+0xa7/0x170
|
||
|
|
kthread+0xcf/0x100
|
||
|
|
ret_from_fork+0x30/0x50
|
||
|
|
ret_from_fork_asm+0x1a/0x30
|
||
|
|
|
||
|
|
And the detailed process is as follows:
|
||
|
|
|
||
|
|
md_do_sync
|
||
|
|
j = mddev->resync_min
|
||
|
|
while (j < max_sectors)
|
||
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
||
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
||
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
||
|
|
return sync_blocks + sectors_skippe;
|
||
|
|
// sectors = 0;
|
||
|
|
j += sectors;
|
||
|
|
// j never change
|
||
|
|
|
||
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
||
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
||
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
||
|
|
|
||
|
|
Fix this problem by always set returned blocks from
|
||
|
|
md_bitmap_get_counter"(), as it used to be.
|
||
|
|
|
||
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
||
|
|
case that bitmap size doesn't match array size still need to be fixed.</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-38598</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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-SP3</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-1839</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-SP3</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-1839</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:
|
||
|
|
|
||
|
|
cpufreq: exit() callback is optional
|
||
|
|
|
||
|
|
The exit() callback is optional and shouldn't be called without checking
|
||
|
|
a valid pointer first.
|
||
|
|
|
||
|
|
Also, we must clear freq_table pointer even if the exit() callback isn't
|
||
|
|
present.</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-38615</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
media: stk1160: fix bounds checking in stk1160_copy_video()
|
||
|
|
|
||
|
|
The subtract in this condition is reversed. The ->length is the length
|
||
|
|
of the buffer. The ->bytesused is how many bytes we have copied thus
|
||
|
|
far. When the condition is reversed that means the result of the
|
||
|
|
subtraction is always negative but since it's unsigned then the result
|
||
|
|
is a very high positive value. That means the overflow check is never
|
||
|
|
true.
|
||
|
|
|
||
|
|
Additionally, the ->bytesused doesn't actually work for this purpose
|
||
|
|
because we're not writing to "buf->mem + buf->bytesused". Instead, the
|
||
|
|
math to calculate the destination where we are writing is a bit
|
||
|
|
involved. You calculate the number of full lines already written,
|
||
|
|
multiply by two, skip a line if necessary so that we start on an odd
|
||
|
|
numbered line, and add the offset into the line.
|
||
|
|
|
||
|
|
To fix this buffer overflow, just take the actual destination where we
|
||
|
|
are writing, if the offset is already out of bounds print an error and
|
||
|
|
return. Otherwise, write up to buf->length bytes.</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-38621</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
fs/ntfs3: Use variable length array instead of fixed size
|
||
|
|
|
||
|
|
Should fix smatch warning:
|
||
|
|
ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-38623</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
|
|
</Status>
|
||
|
|
</ProductStatuses>
|
||
|
|
<Threats>
|
||
|
|
<Threat Type="Impact">
|
||
|
|
<Description>Critical</Description>
|
||
|
|
</Threat>
|
||
|
|
</Threats>
|
||
|
|
<CVSSScoreSets>
|
||
|
|
<ScoreSet>
|
||
|
|
<BaseScore>9.8</BaseScore>
|
||
|
|
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
|
|
</ScoreSet>
|
||
|
|
</CVSSScoreSets>
|
||
|
|
<Remediations>
|
||
|
|
<Remediation Type="Vendor Fix">
|
||
|
|
<Description>kernel security update</Description>
|
||
|
|
<DATE>2024-07-12</DATE>
|
||
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
serial: max3100: 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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
||
|
|
|
||
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
||
|
|
Since we run it in a separate work, the lock may not be taken at
|
||
|
|
the time of running. Make sure that it's taken by explicitly doing
|
||
|
|
that. Without it we got a splat:
|
||
|
|
|
||
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
||
|
|
...
|
||
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
||
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
||
|
|
...
|
||
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
||
|
|
max3100_work+0x12a/0x340 [max3100]</Note>
|
||
|
|
</Notes>
|
||
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
||
|
|
<CVE>CVE-2024-38634</CVE>
|
||
|
|
<ProductStatuses>
|
||
|
|
<Status Type="Fixed">
|
||
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1839</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:
|
||
|
|
|
||
|
|
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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved: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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
|
|
<Notes>
|
||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
|
|
||
|
|
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-SP3</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-1839</URL>
|
||
|
|
</Remediation>
|
||
|
|
</Remediations>
|
||
|
|
</Vulnerability>
|
||
|
|
</cvrfdoc>
|