1749 lines
80 KiB
XML
1749 lines
80 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-20.03-LTS-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1651</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-24</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-24</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-24</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-24</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-20.03-LTS-SP1.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
|
|
|
|
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
|
|
pointer being NULL.
|
|
|
|
The pavgroup pointer is checked on the entrance of the function but
|
|
without the lcu->lock being held. Therefore there is a race window
|
|
between dasd_alias_get_start_dev() and _lcu_update() which sets
|
|
pavgroup to NULL with the lcu->lock held.
|
|
|
|
Fix by checking the pavgroup pointer with lcu->lock held.(CVE-2022-48636)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix hang during unmount when stopping a space reclaim worker
|
|
|
|
Often when running generic/562 from fstests we can hang during unmount,
|
|
resulting in a trace like this:
|
|
|
|
Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00
|
|
Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.
|
|
Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1
|
|
Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000
|
|
Sep 07 11:55:32 debian9 kernel: Call Trace:
|
|
Sep 07 11:55:32 debian9 kernel: <TASK>
|
|
Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0
|
|
Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70
|
|
Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0
|
|
Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130
|
|
Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0
|
|
Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420
|
|
Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0
|
|
Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200
|
|
Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0
|
|
Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530
|
|
Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140
|
|
Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30
|
|
Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0
|
|
Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170
|
|
Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0
|
|
Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120
|
|
Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30
|
|
Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0
|
|
Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160
|
|
Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0
|
|
Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0
|
|
Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40
|
|
Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90
|
|
Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7
|
|
Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
|
|
Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7
|
|
Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0
|
|
Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570
|
|
Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000
|
|
Sep 07 11:55:32 debian9 kernel: </TASK>
|
|
|
|
What happens is the following:
|
|
|
|
1) The cleaner kthread tries to start a transaction to delete an unused
|
|
block group, but the metadata reservation can not be satisfied right
|
|
away, so a reservation ticket is created and it starts the async
|
|
metadata reclaim task (fs_info->async_reclaim_work);
|
|
|
|
2) Writeback for all the filler inodes with an i_size of 2K starts
|
|
(generic/562 creates a lot of 2K files with the goal of filling
|
|
metadata space). We try to create an inline extent for them, but we
|
|
fail when trying to insert the inline extent with -ENOSPC (at
|
|
cow_file_range_inline()) - since this is not critical, we fallback
|
|
to non-inline mode (back to cow_file_range()), reserve extents
|
|
---truncated---(CVE-2022-48664)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.(CVE-2023-52675)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.(CVE-2023-52685)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
|
|
|
|
rx_data_reassembly skb is stored during NCI data exchange for processing
|
|
fragmented packets. It is dropped only when the last fragment is processed
|
|
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
|
|
However, the NCI device may be deallocated before that which leads to skb
|
|
leak.
|
|
|
|
As by design the rx_data_reassembly skb is bound to the NCI device and
|
|
nothing prevents the device to be freed before the skb is processed in
|
|
some way and cleaned, free it on the NCI device cleanup.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-26825)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
|
|
|
|
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
|
|
that are out of bounds for their data type.
|
|
|
|
vmlinux get_bitmap(b=75) + 712
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:0>
|
|
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:592>
|
|
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:576>
|
|
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux DecodeRasMessage() + 304
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:833>
|
|
vmlinux ras_help() + 684
|
|
<net/netfilter/nf_conntrack_h323_main.c:1728>
|
|
vmlinux nf_confirm() + 188
|
|
<net/netfilter/nf_conntrack_proto.c:137>
|
|
|
|
Due to abnormal data in skb->data, the extension bitmap length
|
|
exceeds 32 when decoding ras message then uses the length to make
|
|
a shift operation. It will change into negative after several loop.
|
|
UBSAN load could detect a negative shift as an undefined behaviour
|
|
and reports exception.
|
|
So we add the protection to avoid the length exceeding 32. Or else
|
|
it will return out of range error and stop decoding.(CVE-2024-26851)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
|
|
|
|
syzkaller reported a warning of netns tracker [0] followed by KASAN
|
|
splat [1] and another ref tracker warning [1].
|
|
|
|
syzkaller could not find a repro, but in the log, the only suspicious
|
|
sequence was as follows:
|
|
|
|
18:26:22 executing program 1:
|
|
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
|
|
...
|
|
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
|
|
|
|
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
|
|
|
|
So, the scenario would be:
|
|
|
|
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
|
|
rds_tcp_listen_init().
|
|
2. syz-executor connect()s to it and creates a reqsk.
|
|
3. syz-executor exit()s immediately.
|
|
4. netns is dismantled. [0]
|
|
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
|
|
6. listener is freed after RCU grace period. [2]
|
|
|
|
Basically, reqsk assumes that the listener guarantees netns safety
|
|
until all reqsk timers are expired by holding the listener's refcount.
|
|
However, this was not the case for kernel sockets.
|
|
|
|
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
|
|
inet_twsk_purge()") fixed this issue only for per-netns ehash.
|
|
|
|
Let's apply the same fix for the global ehash.
|
|
|
|
[0]:
|
|
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
|
|
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
|
|
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
|
|
__sock_create (net/socket.c:1572)
|
|
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
|
|
rds_tcp_init_net (net/rds/tcp.c:577)
|
|
ops_init (net/core/net_namespace.c:137)
|
|
setup_net (net/core/net_namespace.c:340)
|
|
copy_net_ns (net/core/net_namespace.c:497)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
|
|
ksys_unshare (kernel/fork.c:3429)
|
|
__x64_sys_unshare (kernel/fork.c:3496)
|
|
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
...
|
|
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
|
|
|
|
[1]:
|
|
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
|
|
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
|
|
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
|
|
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
|
|
run_timer_softirq (kernel/time/timer.c:2053)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
|
|
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
|
|
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
|
|
</IRQ>
|
|
|
|
Allocated by task 258 on cpu 0 at 83.612050s:
|
|
kasan_save_stack (mm/kasan/common.c:48)
|
|
kasan_save_track (mm/kasan/common.c:68)
|
|
__kasan_slab_alloc (mm/kasan/common.c:343)
|
|
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
|
|
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_name
|
|
---truncated---(CVE-2024-26865)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
|
|
|
|
syzbot identified a kernel information leak vulnerability in
|
|
do_sys_name_to_handle() and issued the following report [1].
|
|
|
|
[1]
|
|
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
do_sys_name_to_handle fs/fhandle.c:73 [inline]
|
|
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
|
|
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
|
|
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
|
|
...
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
|
|
kmalloc include/linux/slab.h:604 [inline]
|
|
do_sys_name_to_handle fs/fhandle.c:39 [inline]
|
|
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
|
|
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
|
|
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
|
|
...
|
|
|
|
Bytes 18-19 of 20 are uninitialized
|
|
Memory access of size 20 starts at ffff888128a46380
|
|
Data copied to user address 0000000020000240"
|
|
|
|
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
|
|
solve the problem.(CVE-2024-26901)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
|
|
|
|
During our fuzz testing of the connection and disconnection process at the
|
|
RFCOMM layer, we discovered this bug. By comparing the packets from a
|
|
normal connection and disconnection process with the testcase that
|
|
triggered a KASAN report. We analyzed the cause of this bug as follows:
|
|
|
|
1. In the packets captured during a normal connection, the host sends a
|
|
`Read Encryption Key Size` type of `HCI_CMD` packet
|
|
(Command Opcode: 0x1408) to the controller to inquire the length of
|
|
encryption key.After receiving this packet, the controller immediately
|
|
replies with a Command Completepacket (Event Code: 0x0e) to return the
|
|
Encryption Key Size.
|
|
|
|
2. In our fuzz test case, the timing of the controller's response to this
|
|
packet was delayed to an unexpected point: after the RFCOMM and L2CAP
|
|
layers had disconnected but before the HCI layer had disconnected.
|
|
|
|
3. After receiving the Encryption Key Size Response at the time described
|
|
in point 2, the host still called the rfcomm_check_security function.
|
|
However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`
|
|
had already been released, and when the function executed
|
|
`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,
|
|
specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.
|
|
|
|
To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling
|
|
rfcomm_recv_frame in rfcomm_process_rx.(CVE-2024-26903)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.(CVE-2024-26923)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: check offset alignment in binder_get_object()
|
|
|
|
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
|
|
txn") introduced changes to how binder objects are copied. In doing so,
|
|
it unintentionally removed an offset alignment check done through calls
|
|
to binder_alloc_copy_from_buffer() -> check_buffer().
|
|
|
|
These calls were replaced in binder_get_object() with copy_from_user(),
|
|
so now an explicit offset alignment check is needed here. This avoids
|
|
later complications when unwinding the objects gets harder.
|
|
|
|
It is worth noting this check existed prior to commit 7a67a39320df
|
|
("binder: add function to copy binder object from buffer"), likely
|
|
removed due to redundancy at the time.(CVE-2024-26926)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
|
|
|
|
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27395)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: gtp: Fix Use-After-Free in gtp_dellink
|
|
|
|
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of gtp_dellink, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27396)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
|
|
|
|
When the sco connection is established and then, the sco socket
|
|
is releasing, timeout_work will be scheduled to judge whether
|
|
the sco disconnection is timeout. The sock will be deallocated
|
|
later, but it is dereferenced again in sco_sock_timeout. As a
|
|
result, the use-after-free bugs will happen. The root cause is
|
|
shown below:
|
|
|
|
Cleanup Thread | Worker Thread
|
|
sco_sock_release |
|
|
sco_sock_close |
|
|
__sco_sock_close |
|
|
sco_sock_set_timer |
|
|
schedule_delayed_work |
|
|
sco_sock_kill | (wait a time)
|
|
sock_put(sk) //FREE | sco_sock_timeout
|
|
| sock_hold(sk) //USE
|
|
|
|
The KASAN report triggered by POC is shown below:
|
|
|
|
[ 95.890016] ==================================================================
|
|
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
|
|
...
|
|
[ 95.890755] Workqueue: events sco_sock_timeout
|
|
[ 95.890755] Call Trace:
|
|
[ 95.890755] <TASK>
|
|
[ 95.890755] dump_stack_lvl+0x45/0x110
|
|
[ 95.890755] print_address_description+0x78/0x390
|
|
[ 95.890755] print_report+0x11b/0x250
|
|
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_report+0x139/0x170
|
|
[ 95.890755] ? update_load_avg+0xe5/0x9f0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_check_range+0x2c3/0x2e0
|
|
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] process_one_work+0x561/0xc50
|
|
[ 95.890755] worker_thread+0xab2/0x13c0
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] kthread+0x279/0x300
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork+0x34/0x60
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork_asm+0x11/0x20
|
|
[ 95.890755] </TASK>
|
|
[ 95.890755]
|
|
[ 95.890755] Allocated by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] __kasan_kmalloc+0x86/0x90
|
|
[ 95.890755] __kmalloc+0x17f/0x360
|
|
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
|
|
[ 95.890755] sk_alloc+0x31/0x4e0
|
|
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
|
|
[ 95.890755] sco_sock_create+0xad/0x320
|
|
[ 95.890755] bt_sock_create+0x145/0x320
|
|
[ 95.890755] __sock_create+0x2e1/0x650
|
|
[ 95.890755] __sys_socket+0xd0/0x280
|
|
[ 95.890755] __x64_sys_socket+0x75/0x80
|
|
[ 95.890755] do_syscall_64+0xc4/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] Freed by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] kasan_save_free_info+0x40/0x50
|
|
[ 95.890755] poison_slab_object+0x118/0x180
|
|
[ 95.890755] __kasan_slab_free+0x12/0x30
|
|
[ 95.890755] kfree+0xb2/0x240
|
|
[ 95.890755] __sk_destruct+0x317/0x410
|
|
[ 95.890755] sco_sock_release+0x232/0x280
|
|
[ 95.890755] sock_close+0xb2/0x210
|
|
[ 95.890755] __fput+0x37f/0x770
|
|
[ 95.890755] task_work_run+0x1ae/0x210
|
|
[ 95.890755] get_signal+0xe17/0xf70
|
|
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
|
|
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
|
|
[ 95.890755] do_syscall_64+0xd1/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
|
|
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 95.890755] The buggy address is located 128 bytes inside of
|
|
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the physical page:
|
|
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
|
|
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
|
|
[ 95.890755] ano
|
|
---truncated---(CVE-2024-27398)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48636</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48664</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52675</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52685</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26825</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26851</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26865</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26901</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26903</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26908</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26921</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26923</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26926</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27395</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27396</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27398</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35849</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48636</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48664</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52675</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26825</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26851</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26865</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26901</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26903</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26908</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26921</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26923</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26926</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27395</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27396</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27398</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35849</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.4.0.0250.oe1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.4.0.0250.oe1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.4.0.0250" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.4.0.0250.oe1.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
|
|
|
|
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
|
|
pointer being NULL.
|
|
|
|
The pavgroup pointer is checked on the entrance of the function but
|
|
without the lcu->lock being held. Therefore there is a race window
|
|
between dasd_alias_get_start_dev() and _lcu_update() which sets
|
|
pavgroup to NULL with the lcu->lock held.
|
|
|
|
Fix by checking the pavgroup pointer with lcu->lock held.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2022-48636</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix hang during unmount when stopping a space reclaim worker
|
|
|
|
Often when running generic/562 from fstests we can hang during unmount,
|
|
resulting in a trace like this:
|
|
|
|
Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00
|
|
Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.
|
|
Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1
|
|
Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000
|
|
Sep 07 11:55:32 debian9 kernel: Call Trace:
|
|
Sep 07 11:55:32 debian9 kernel: <TASK>
|
|
Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0
|
|
Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70
|
|
Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0
|
|
Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130
|
|
Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0
|
|
Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420
|
|
Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0
|
|
Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200
|
|
Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0
|
|
Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530
|
|
Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140
|
|
Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30
|
|
Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0
|
|
Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170
|
|
Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0
|
|
Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120
|
|
Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30
|
|
Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs]
|
|
Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0
|
|
Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160
|
|
Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0
|
|
Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0
|
|
Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40
|
|
Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90
|
|
Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7
|
|
Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
|
|
Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7
|
|
Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0
|
|
Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570
|
|
Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000
|
|
Sep 07 11:55:32 debian9 kernel: </TASK>
|
|
|
|
What happens is the following:
|
|
|
|
1) The cleaner kthread tries to start a transaction to delete an unused
|
|
block group, but the metadata reservation can not be satisfied right
|
|
away, so a reservation ticket is created and it starts the async
|
|
metadata reclaim task (fs_info->async_reclaim_work);
|
|
|
|
2) Writeback for all the filler inodes with an i_size of 2K starts
|
|
(generic/562 creates a lot of 2K files with the goal of filling
|
|
metadata space). We try to create an inline extent for them, but we
|
|
fail when trying to insert the inline extent with -ENOSPC (at
|
|
cow_file_range_inline()) - since this is not critical, we fallback
|
|
to non-inline mode (back to cow_file_range()), reserve extents
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2022-48664</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52675</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52685</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
|
|
|
|
rx_data_reassembly skb is stored during NCI data exchange for processing
|
|
fragmented packets. It is dropped only when the last fragment is processed
|
|
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
|
|
However, the NCI device may be deallocated before that which leads to skb
|
|
leak.
|
|
|
|
As by design the rx_data_reassembly skb is bound to the NCI device and
|
|
nothing prevents the device to be freed before the skb is processed in
|
|
some way and cleaned, free it on the NCI device cleanup.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26825</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
|
|
|
|
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
|
|
that are out of bounds for their data type.
|
|
|
|
vmlinux get_bitmap(b=75) + 712
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:0>
|
|
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:592>
|
|
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:576>
|
|
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux DecodeRasMessage() + 304
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:833>
|
|
vmlinux ras_help() + 684
|
|
<net/netfilter/nf_conntrack_h323_main.c:1728>
|
|
vmlinux nf_confirm() + 188
|
|
<net/netfilter/nf_conntrack_proto.c:137>
|
|
|
|
Due to abnormal data in skb->data, the extension bitmap length
|
|
exceeds 32 when decoding ras message then uses the length to make
|
|
a shift operation. It will change into negative after several loop.
|
|
UBSAN load could detect a negative shift as an undefined behaviour
|
|
and reports exception.
|
|
So we add the protection to avoid the length exceeding 32. Or else
|
|
it will return out of range error and stop decoding.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26851</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
|
|
|
|
syzkaller reported a warning of netns tracker [0] followed by KASAN
|
|
splat [1] and another ref tracker warning [1].
|
|
|
|
syzkaller could not find a repro, but in the log, the only suspicious
|
|
sequence was as follows:
|
|
|
|
18:26:22 executing program 1:
|
|
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
|
|
...
|
|
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
|
|
|
|
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
|
|
|
|
So, the scenario would be:
|
|
|
|
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
|
|
rds_tcp_listen_init().
|
|
2. syz-executor connect()s to it and creates a reqsk.
|
|
3. syz-executor exit()s immediately.
|
|
4. netns is dismantled. [0]
|
|
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
|
|
6. listener is freed after RCU grace period. [2]
|
|
|
|
Basically, reqsk assumes that the listener guarantees netns safety
|
|
until all reqsk timers are expired by holding the listener's refcount.
|
|
However, this was not the case for kernel sockets.
|
|
|
|
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
|
|
inet_twsk_purge()") fixed this issue only for per-netns ehash.
|
|
|
|
Let's apply the same fix for the global ehash.
|
|
|
|
[0]:
|
|
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
|
|
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
|
|
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
|
|
__sock_create (net/socket.c:1572)
|
|
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
|
|
rds_tcp_init_net (net/rds/tcp.c:577)
|
|
ops_init (net/core/net_namespace.c:137)
|
|
setup_net (net/core/net_namespace.c:340)
|
|
copy_net_ns (net/core/net_namespace.c:497)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
|
|
ksys_unshare (kernel/fork.c:3429)
|
|
__x64_sys_unshare (kernel/fork.c:3496)
|
|
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
...
|
|
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
|
|
|
|
[1]:
|
|
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
|
|
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
|
|
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
|
|
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
|
|
run_timer_softirq (kernel/time/timer.c:2053)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
|
|
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
|
|
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
|
|
</IRQ>
|
|
|
|
Allocated by task 258 on cpu 0 at 83.612050s:
|
|
kasan_save_stack (mm/kasan/common.c:48)
|
|
kasan_save_track (mm/kasan/common.c:68)
|
|
__kasan_slab_alloc (mm/kasan/common.c:343)
|
|
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
|
|
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_name
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26865</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Bytes 18-19 of 20 are uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240 Per Chuck Lever s suggestion, use kzalloc() instead of kmalloc() tosolve the problem.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26901</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_securityDuring our fuzz testing of the connection and disconnection process at theRFCOMM layer, we discovered this bug. By comparing the packets from anormal connection and disconnection process with the testcase thattriggered a KASAN report. We analyzed the cause of this bug as follows:1. In the packets captured during a normal connection, the host sends a`Read Encryption Key Size` type of `HCI_CMD` packet(Command Opcode: 0x1408) to the controller to inquire the length ofencryption key.After receiving this packet, the controller immediatelyreplies with a Command Completepacket (Event Code: 0x0e) to return theEncryption Key Size.2. In our fuzz test case, the timing of the controller s response to thispacket was delayed to an unexpected point: after the RFCOMM and L2CAPlayers had disconnected but before the HCI layer had disconnected.3. After receiving the Encryption Key Size Response at the time describedin point 2, the host still called the rfcomm_check_security function.However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`had already been released, and when the function executed`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.To fix this bug, check if `sk->sk_state` is BT_CLOSED before callingrfcomm_recv_frame in rfcomm_process_rx.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26903</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="10" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26908</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="11" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26921</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26923</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: check offset alignment in binder_get_object()
|
|
|
|
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
|
|
txn") introduced changes to how binder objects are copied. In doing so,
|
|
it unintentionally removed an offset alignment check done through calls
|
|
to binder_alloc_copy_from_buffer() -> check_buffer().
|
|
|
|
These calls were replaced in binder_get_object() with copy_from_user(),
|
|
so now an explicit offset alignment check is needed here. This avoids
|
|
later complications when unwinding the objects gets harder.
|
|
|
|
It is worth noting this check existed prior to commit 7a67a39320df
|
|
("binder: add function to copy binder object from buffer"), likely
|
|
removed due to redundancy at the time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26926</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
|
|
|
|
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27395</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: gtp: Fix Use-After-Free in gtp_dellink
|
|
|
|
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of gtp_dellink, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27396</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
|
|
|
|
When the sco connection is established and then, the sco socket
|
|
is releasing, timeout_work will be scheduled to judge whether
|
|
the sco disconnection is timeout. The sock will be deallocated
|
|
later, but it is dereferenced again in sco_sock_timeout. As a
|
|
result, the use-after-free bugs will happen. The root cause is
|
|
shown below:
|
|
|
|
Cleanup Thread | Worker Thread
|
|
sco_sock_release |
|
|
sco_sock_close |
|
|
__sco_sock_close |
|
|
sco_sock_set_timer |
|
|
schedule_delayed_work |
|
|
sco_sock_kill | (wait a time)
|
|
sock_put(sk) //FREE | sco_sock_timeout
|
|
| sock_hold(sk) //USE
|
|
|
|
The KASAN report triggered by POC is shown below:
|
|
|
|
[ 95.890016] ==================================================================
|
|
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
|
|
...
|
|
[ 95.890755] Workqueue: events sco_sock_timeout
|
|
[ 95.890755] Call Trace:
|
|
[ 95.890755] <TASK>
|
|
[ 95.890755] dump_stack_lvl+0x45/0x110
|
|
[ 95.890755] print_address_description+0x78/0x390
|
|
[ 95.890755] print_report+0x11b/0x250
|
|
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_report+0x139/0x170
|
|
[ 95.890755] ? update_load_avg+0xe5/0x9f0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_check_range+0x2c3/0x2e0
|
|
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] process_one_work+0x561/0xc50
|
|
[ 95.890755] worker_thread+0xab2/0x13c0
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] kthread+0x279/0x300
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork+0x34/0x60
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork_asm+0x11/0x20
|
|
[ 95.890755] </TASK>
|
|
[ 95.890755]
|
|
[ 95.890755] Allocated by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] __kasan_kmalloc+0x86/0x90
|
|
[ 95.890755] __kmalloc+0x17f/0x360
|
|
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
|
|
[ 95.890755] sk_alloc+0x31/0x4e0
|
|
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
|
|
[ 95.890755] sco_sock_create+0xad/0x320
|
|
[ 95.890755] bt_sock_create+0x145/0x320
|
|
[ 95.890755] __sock_create+0x2e1/0x650
|
|
[ 95.890755] __sys_socket+0xd0/0x280
|
|
[ 95.890755] __x64_sys_socket+0x75/0x80
|
|
[ 95.890755] do_syscall_64+0xc4/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] Freed by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] kasan_save_free_info+0x40/0x50
|
|
[ 95.890755] poison_slab_object+0x118/0x180
|
|
[ 95.890755] __kasan_slab_free+0x12/0x30
|
|
[ 95.890755] kfree+0xb2/0x240
|
|
[ 95.890755] __sk_destruct+0x317/0x410
|
|
[ 95.890755] sco_sock_release+0x232/0x280
|
|
[ 95.890755] sock_close+0xb2/0x210
|
|
[ 95.890755] __fput+0x37f/0x770
|
|
[ 95.890755] task_work_run+0x1ae/0x210
|
|
[ 95.890755] get_signal+0xe17/0xf70
|
|
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
|
|
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
|
|
[ 95.890755] do_syscall_64+0xd1/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
|
|
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 95.890755] The buggy address is located 128 bytes inside of
|
|
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the physical page:
|
|
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
|
|
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
|
|
[ 95.890755] ano
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27398</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</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="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-35849</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1651</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |