1738 lines
74 KiB
XML
1738 lines
74 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-1792</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-05</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-05</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-05</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-05</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:
|
|
|
|
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
|
|
|
|
It is observed sometimes when tethering is used over NCM with Windows 11
|
|
as host, at some instances, the gadget_giveback has one byte appended at
|
|
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
|
|
any leftover bytes in SKB provided by u_ether and if there are any pending
|
|
bytes, it treats them as a separate NTB and parses it. But in case the
|
|
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
|
|
were parsed properly in the first NTB and saved in rx_list are dropped.
|
|
|
|
Adding a few custom traces showed the following:
|
|
[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:
|
|
req 000000003868811a length 1025/16384 zsI ==> 0
|
|
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
|
|
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
|
|
[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
|
|
|
|
In this case, the giveback is of 1025 bytes and block length is 1024.
|
|
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
|
|
all datagrams in rx_list.
|
|
|
|
Same is case with packets of size 2048:
|
|
[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:
|
|
req 0000000011dfd96e length 2049/16384 zsI ==> 0
|
|
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
|
|
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
|
|
|
|
Lecroy shows one byte coming in extra confirming that the byte is coming
|
|
in from PC:
|
|
|
|
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)
|
|
- Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
|
|
--- Packet 4063861
|
|
Data(1024 bytes)
|
|
Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
|
|
--- Packet 4063863
|
|
Data(1 byte)
|
|
Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
|
|
|
|
According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
|
|
because the non-zero wBlockLength has already told the function side the
|
|
size of transfer to be expected. However, there are in-market NCM devices
|
|
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
|
|
To deal with such devices, it pads an extra 0 at end so the transfer is no
|
|
longer multiple of wMaxPacketSize.(CVE-2024-27405)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
|
|
|
|
It seems that if userspace provides a correct IFA_TARGET_NETNSID value
|
|
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
|
|
returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: flush pending destroy work before exit_net release
|
|
|
|
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
|
|
work before netlink notifier") to address a race between exit_net and
|
|
the destroy workqueue.
|
|
|
|
The trace below shows an element to be released via destroy workqueue
|
|
while exit_net path (triggered via module removal) has already released
|
|
the set that is used in such transaction.
|
|
|
|
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
|
|
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
|
|
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
|
|
[ 1360.547984] Call Trace:
|
|
[ 1360.547991] <TASK>
|
|
[ 1360.547998] dump_stack_lvl+0x53/0x70
|
|
[ 1360.548014] print_report+0xc4/0x610
|
|
[ 1360.548026] ? __virt_addr_valid+0xba/0x160
|
|
[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
|
|
[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548176] kasan_report+0xae/0xe0
|
|
[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]
|
|
[ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30
|
|
[ 1360.548591] process_one_work+0x2f1/0x670
|
|
[ 1360.548610] worker_thread+0x4d3/0x760
|
|
[ 1360.548627] ? __pfx_worker_thread+0x10/0x10
|
|
[ 1360.548640] kthread+0x16b/0x1b0
|
|
[ 1360.548653] ? __pfx_kthread+0x10/0x10
|
|
[ 1360.548665] ret_from_fork+0x2f/0x50
|
|
[ 1360.548679] ? __pfx_kthread+0x10/0x10
|
|
[ 1360.548690] ret_from_fork_asm+0x1a/0x30
|
|
[ 1360.548707] </TASK>
|
|
|
|
[ 1360.548719] Allocated by task 192061:
|
|
[ 1360.548726] kasan_save_stack+0x20/0x40
|
|
[ 1360.548739] kasan_save_track+0x14/0x30
|
|
[ 1360.548750] __kasan_kmalloc+0x8f/0xa0
|
|
[ 1360.548760] __kmalloc_node+0x1f1/0x450
|
|
[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]
|
|
[ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]
|
|
[ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
|
|
[ 1360.548927] netlink_unicast+0x367/0x4f0
|
|
[ 1360.548935] netlink_sendmsg+0x34b/0x610
|
|
[ 1360.548944] ____sys_sendmsg+0x4d4/0x510
|
|
[ 1360.548953] ___sys_sendmsg+0xc9/0x120
|
|
[ 1360.548961] __sys_sendmsg+0xbe/0x140
|
|
[ 1360.548971] do_syscall_64+0x55/0x120
|
|
[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
|
|
|
|
[ 1360.548994] Freed by task 192222:
|
|
[ 1360.548999] kasan_save_stack+0x20/0x40
|
|
[ 1360.549009] kasan_save_track+0x14/0x30
|
|
[ 1360.549019] kasan_save_free_info+0x3b/0x60
|
|
[ 1360.549028] poison_slab_object+0x100/0x180
|
|
[ 1360.549036] __kasan_slab_free+0x14/0x30
|
|
[ 1360.549042] kfree+0xb6/0x260
|
|
[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]
|
|
[ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]
|
|
[ 1360.549221] ops_exit_list+0x50/0xa0
|
|
[ 1360.549229] free_exit_list+0x101/0x140
|
|
[ 1360.549236] unregister_pernet_operations+0x107/0x160
|
|
[ 1360.549245] unregister_pernet_subsys+0x1c/0x30
|
|
[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]
|
|
[ 1360.549345] __do_sys_delete_module+0x253/0x370
|
|
[ 1360.549352] do_syscall_64+0x55/0x120
|
|
[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
|
|
|
|
(gdb) list *__nft_release_table+0x473
|
|
0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
|
|
11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
|
|
11350 list_del(&flowtable->list);
|
|
11351 nft_use_dec(&table->use);
|
|
11352 nf_tables_flowtable_destroy(flowtable);
|
|
11353 }
|
|
11354 list_for_each_entry_safe(set, ns, &table->sets, list) {
|
|
11355 list_del(&set->list);
|
|
11356 nft_use_dec(&table->use);
|
|
11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))
|
|
11358 nft_map_deactivat
|
|
---truncated---(CVE-2024-35899)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dyndbg: fix old BUG_ON in >control parser
|
|
|
|
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
|
|
really look), lets make sure by removing it, doing pr_err and return
|
|
-EINVAL instead.(CVE-2024-35947)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
|
|
|
|
If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,
|
|
taprio_parse_mqprio_opt() must validate it, or userspace
|
|
can inject arbitrary data to the kernel, the second time
|
|
taprio_change() is called.
|
|
|
|
First call (with valid attributes) sets dev->num_tc
|
|
to a non zero value.
|
|
|
|
Second call (with arbitrary mqprio attributes)
|
|
returns early from taprio_parse_mqprio_opt()
|
|
and bad things can happen.(CVE-2024-36974)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK>(CVE-2024-37356)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
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(CVE-2024-38538)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
of: module: add buffer overflow check in of_modalias()
|
|
|
|
In of_modalias(), if the buffer happens to be too small even for the 1st
|
|
snprintf() call, the len parameter will become negative and str parameter
|
|
(if not NULL initially) will point beyond the buffer's end. Add the buffer
|
|
overflow check after the 1st snprintf() call and fix such check after the
|
|
strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.(CVE-2024-38549)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.(CVE-2024-38553)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40(CVE-2024-38555)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Add a timeout to acquire the command queue semaphore
|
|
|
|
Prevent forced completion handling on an entry that has not yet been
|
|
assigned an index, causing an out of bounds access on idx = -22.
|
|
Instead of waiting indefinitely for the sem, blocking flow now waits for
|
|
index to be allocated or a sem acquisition timeout before beginning the
|
|
timer for FW completion.
|
|
|
|
Kernel log example:
|
|
mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion(CVE-2024-38556)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
|
|
|
|
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
|
|
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
|
|
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
|
|
to properly verify prog_type <> attach_type association.
|
|
|
|
Add missing attach_type enforcement for the link_create case.
|
|
Otherwise, it's currently possible to attach cgroup_skb prog
|
|
types to other cgroup hooks.(CVE-2024-38564)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
speakup: Fix sizeof() vs ARRAY_SIZE() bug
|
|
|
|
The "buf" pointer is an array of u16 values. This code should be
|
|
using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
|
|
otherwise it can the still got out of bounds.(CVE-2024-38587)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
|
|
|
|
For example, in the expression:
|
|
vbo = 2 * vbo + skip(CVE-2024-38624)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.(CVE-2024-38630)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.(CVE-2024-38661)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
um: Add winch to winch_handlers before registering winch IRQ
|
|
|
|
Registering a winch IRQ is racy, an interrupt may occur before the winch is
|
|
added to the winch_handlers list.
|
|
|
|
If that happens, register_winch_irq() adds to that list a winch that is
|
|
scheduled to be (or has already been) freed, causing a panic later in
|
|
winch_cleanup().
|
|
|
|
Avoid the race by adding the winch to the winch_handlers list before
|
|
registering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)</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 high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27405</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27417</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35899</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35947</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36974</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37356</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38538</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38541</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38549</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38553</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38555</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38556</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38564</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38587</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38599</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38624</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38630</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38661</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39292</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27405</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27417</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35899</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35947</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36974</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37356</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38538</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38541</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38549</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38553</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38555</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38556</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38564</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38587</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38599</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38624</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38630</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38661</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39292</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-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-217.0.0.120" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-217.0.0.120.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:
|
|
|
|
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
|
|
|
|
It is observed sometimes when tethering is used over NCM with Windows 11
|
|
as host, at some instances, the gadget_giveback has one byte appended at
|
|
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
|
|
any leftover bytes in SKB provided by u_ether and if there are any pending
|
|
bytes, it treats them as a separate NTB and parses it. But in case the
|
|
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
|
|
were parsed properly in the first NTB and saved in rx_list are dropped.
|
|
|
|
Adding a few custom traces showed the following:
|
|
[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:
|
|
req 000000003868811a length 1025/16384 zsI ==> 0
|
|
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
|
|
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
|
|
[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
|
|
[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
|
|
|
|
In this case, the giveback is of 1025 bytes and block length is 1024.
|
|
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
|
|
all datagrams in rx_list.
|
|
|
|
Same is case with packets of size 2048:
|
|
[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:
|
|
req 0000000011dfd96e length 2049/16384 zsI ==> 0
|
|
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
|
|
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
|
|
|
|
Lecroy shows one byte coming in extra confirming that the byte is coming
|
|
in from PC:
|
|
|
|
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)
|
|
- Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
|
|
--- Packet 4063861
|
|
Data(1024 bytes)
|
|
Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
|
|
--- Packet 4063863
|
|
Data(1 byte)
|
|
Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
|
|
|
|
According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
|
|
because the non-zero wBlockLength has already told the function side the
|
|
size of transfer to be expected. However, there are in-market NCM devices
|
|
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
|
|
To deal with such devices, it pads an extra 0 at end so the transfer is no
|
|
longer multiple of wMaxPacketSize.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-27405</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>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
|
|
|
|
It seems that if userspace provides a correct IFA_TARGET_NETNSID value
|
|
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
|
|
returns -EINVAL with an elevated "struct net" refcount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-27417</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
netfilter: nf_tables: flush pending destroy work before exit_net release
|
|
|
|
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
|
|
work before netlink notifier") to address a race between exit_net and
|
|
the destroy workqueue.
|
|
|
|
The trace below shows an element to be released via destroy workqueue
|
|
while exit_net path (triggered via module removal) has already released
|
|
the set that is used in such transaction.
|
|
|
|
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
|
|
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
|
|
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
|
|
[ 1360.547984] Call Trace:
|
|
[ 1360.547991] <TASK>
|
|
[ 1360.547998] dump_stack_lvl+0x53/0x70
|
|
[ 1360.548014] print_report+0xc4/0x610
|
|
[ 1360.548026] ? __virt_addr_valid+0xba/0x160
|
|
[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
|
|
[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548176] kasan_report+0xae/0xe0
|
|
[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
|
|
[ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]
|
|
[ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30
|
|
[ 1360.548591] process_one_work+0x2f1/0x670
|
|
[ 1360.548610] worker_thread+0x4d3/0x760
|
|
[ 1360.548627] ? __pfx_worker_thread+0x10/0x10
|
|
[ 1360.548640] kthread+0x16b/0x1b0
|
|
[ 1360.548653] ? __pfx_kthread+0x10/0x10
|
|
[ 1360.548665] ret_from_fork+0x2f/0x50
|
|
[ 1360.548679] ? __pfx_kthread+0x10/0x10
|
|
[ 1360.548690] ret_from_fork_asm+0x1a/0x30
|
|
[ 1360.548707] </TASK>
|
|
|
|
[ 1360.548719] Allocated by task 192061:
|
|
[ 1360.548726] kasan_save_stack+0x20/0x40
|
|
[ 1360.548739] kasan_save_track+0x14/0x30
|
|
[ 1360.548750] __kasan_kmalloc+0x8f/0xa0
|
|
[ 1360.548760] __kmalloc_node+0x1f1/0x450
|
|
[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]
|
|
[ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]
|
|
[ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
|
|
[ 1360.548927] netlink_unicast+0x367/0x4f0
|
|
[ 1360.548935] netlink_sendmsg+0x34b/0x610
|
|
[ 1360.548944] ____sys_sendmsg+0x4d4/0x510
|
|
[ 1360.548953] ___sys_sendmsg+0xc9/0x120
|
|
[ 1360.548961] __sys_sendmsg+0xbe/0x140
|
|
[ 1360.548971] do_syscall_64+0x55/0x120
|
|
[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
|
|
|
|
[ 1360.548994] Freed by task 192222:
|
|
[ 1360.548999] kasan_save_stack+0x20/0x40
|
|
[ 1360.549009] kasan_save_track+0x14/0x30
|
|
[ 1360.549019] kasan_save_free_info+0x3b/0x60
|
|
[ 1360.549028] poison_slab_object+0x100/0x180
|
|
[ 1360.549036] __kasan_slab_free+0x14/0x30
|
|
[ 1360.549042] kfree+0xb6/0x260
|
|
[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]
|
|
[ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]
|
|
[ 1360.549221] ops_exit_list+0x50/0xa0
|
|
[ 1360.549229] free_exit_list+0x101/0x140
|
|
[ 1360.549236] unregister_pernet_operations+0x107/0x160
|
|
[ 1360.549245] unregister_pernet_subsys+0x1c/0x30
|
|
[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]
|
|
[ 1360.549345] __do_sys_delete_module+0x253/0x370
|
|
[ 1360.549352] do_syscall_64+0x55/0x120
|
|
[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
|
|
|
|
(gdb) list *__nft_release_table+0x473
|
|
0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
|
|
11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
|
|
11350 list_del(&flowtable->list);
|
|
11351 nft_use_dec(&table->use);
|
|
11352 nf_tables_flowtable_destroy(flowtable);
|
|
11353 }
|
|
11354 list_for_each_entry_safe(set, ns, &table->sets, list) {
|
|
11355 list_del(&set->list);
|
|
11356 nft_use_dec(&table->use);
|
|
11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))
|
|
11358 nft_map_deactivat
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-35899</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
dyndbg: fix old BUG_ON in >control parser
|
|
|
|
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
|
|
really look), lets make sure by removing it, doing pr_err and return
|
|
-EINVAL instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-35947</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
|
|
|
|
If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,
|
|
taprio_parse_mqprio_opt() must validate it, or userspace
|
|
can inject arbitrary data to the kernel, the second time
|
|
taprio_change() is called.
|
|
|
|
First call (with valid attributes) sets dev->num_tc
|
|
to a non zero value.
|
|
|
|
Second call (with arbitrary mqprio attributes)
|
|
returns early from taprio_parse_mqprio_opt()
|
|
and bad things can happen.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-36974</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-37356</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
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</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38538</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
of: module: add buffer overflow check in of_modalias()
|
|
|
|
In of_modalias(), if the buffer happens to be too small even for the 1st
|
|
snprintf() call, the len parameter will become negative and str parameter
|
|
(if not NULL initially) will point beyond the buffer's end. Add the buffer
|
|
overflow check after the 1st snprintf() call and fix such check after the
|
|
strlen() call (accounting for the terminating NUL char).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38541</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38549</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38553</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></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38555</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
net/mlx5: Add a timeout to acquire the command queue semaphore
|
|
|
|
Prevent forced completion handling on an entry that has not yet been
|
|
assigned an index, causing an out of bounds access on idx = -22.
|
|
Instead of waiting indefinitely for the sem, blocking flow now waits for
|
|
index to be allocated or a sem acquisition timeout before beginning the
|
|
timer for FW completion.
|
|
|
|
Kernel log example:
|
|
mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38556</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
|
|
|
|
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
|
|
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
|
|
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
|
|
to properly verify prog_type <> attach_type association.
|
|
|
|
Add missing attach_type enforcement for the link_create case.
|
|
Otherwise, it's currently possible to attach cgroup_skb prog
|
|
types to other cgroup hooks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38564</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.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
speakup: Fix sizeof() vs ARRAY_SIZE() bug
|
|
|
|
The "buf" pointer is an array of u16 values. This code should be
|
|
using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
|
|
otherwise it can the still got out of bounds.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38587</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:H/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38599</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>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
|
|
|
|
For example, in the expression:
|
|
vbo = 2 * vbo + skip</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38624</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.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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38630</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38661</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.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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</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:
|
|
|
|
um: Add winch to winch_handlers before registering winch IRQ
|
|
|
|
Registering a winch IRQ is racy, an interrupt may occur before the winch is
|
|
added to the winch_handlers list.
|
|
|
|
If that happens, register_winch_irq() adds to that list a winch that is
|
|
scheduled to be (or has already been) freed, causing a panic later in
|
|
winch_cleanup().
|
|
|
|
Avoid the race by adding the winch to the winch_handlers list before
|
|
registering the IRQ, and rolling back if um_request_irq() fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-39292</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-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |