2106 lines
102 KiB
XML
2106 lines
102 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1766</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-06-28</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-06-28</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-06-28</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-06-28</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer
|
|
|
|
The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the
|
|
maximum transfer length and the size of the transfer buffer. As such, it
|
|
does not account for the 4 bytes of header that prepends the SPI data
|
|
frame. This can result in out-of-bounds accesses and was confirmed with
|
|
KASAN.
|
|
|
|
Introduce SPI_HDRSIZE to account for the header and use to allocate the
|
|
transfer buffer.(CVE-2024-36477)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix out-of-bounds access in ops_init
|
|
|
|
net_alloc_generic is called by net_alloc, which is called without any
|
|
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
|
|
is read twice, first to allocate an array, then to set s.len, which is
|
|
later used to limit the bounds of the array access.
|
|
|
|
It is possible that the array is allocated and another thread is
|
|
registering a new pernet ops, increments max_gen_ptrs, which is then used
|
|
to set s.len with a larger than allocated length for the variable array.
|
|
|
|
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
|
|
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gpiolib: cdev: fix uninitialised kfifo
|
|
|
|
If a line is requested with debounce, and that results in debouncing
|
|
in software, and the line is subsequently reconfigured to enable edge
|
|
detection then the allocation of the kfifo to contain edge events is
|
|
overlooked. This results in events being written to and read from an
|
|
uninitialised kfifo. Read events are returned to userspace.
|
|
|
|
Initialise the kfifo in the case where the software debounce is
|
|
already active.(CVE-2024-36898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
|
|
|
|
syzbot is able to trigger the following crash [1],
|
|
caused by unsafe ip6_dst_idev() use.
|
|
|
|
Indeed ip6_dst_idev() can return NULL, and must always be checked.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
|
|
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
|
|
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
|
|
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
|
|
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
|
|
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
|
|
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
|
|
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
|
|
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
|
|
fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
|
|
ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
|
|
ip6_route_output include/net/ip6_route.h:93 [inline]
|
|
ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
|
|
ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
|
|
sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
|
|
sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
|
|
sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
|
|
sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
|
|
__sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
|
|
sctp_connect net/sctp/socket.c:4819 [inline]
|
|
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
|
|
__sys_connect_file net/socket.c:2048 [inline]
|
|
__sys_connect+0x2df/0x310 net/socket.c:2065
|
|
__do_sys_connect net/socket.c:2075 [inline]
|
|
__se_sys_connect net/socket.c:2072 [inline]
|
|
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: Fix potential uninit-value access in __ip6_make_skb()
|
|
|
|
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
|
|
__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags
|
|
instead of testing HDRINCL on the socket to avoid a race condition which
|
|
causes uninit-value access.(CVE-2024-36903)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
|
|
|
|
TCP_SYN_RECV state is really special, it is only used by
|
|
cross-syn connections, mostly used by fuzzers.
|
|
|
|
In the following crash [1], syzbot managed to trigger a divide
|
|
by zero in tcp_rcv_space_adjust()
|
|
|
|
A socket makes the following state transitions,
|
|
without ever calling tcp_init_transfer(),
|
|
meaning tcp_init_buffer_space() is also not called.
|
|
|
|
TCP_CLOSE
|
|
connect()
|
|
TCP_SYN_SENT
|
|
TCP_SYN_RECV
|
|
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
|
|
TCP_FIN_WAIT1
|
|
|
|
To fix this issue, change tcp_shutdown() to not
|
|
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
|
|
which makes no sense anyway.
|
|
|
|
When tcp_rcv_state_process() later changes socket state
|
|
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
|
|
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
|
|
and send a FIN packet from a sane socket state.
|
|
|
|
This means tcp_send_fin() can now be called from BH
|
|
context, and must use GFP_ATOMIC allocations.
|
|
|
|
[1]
|
|
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
|
|
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
|
|
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
|
|
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
|
|
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
|
|
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
|
|
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
|
|
tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
|
|
inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x109/0x280 net/socket.c:1068
|
|
____sys_recvmsg+0x1db/0x470 net/socket.c:2803
|
|
___sys_recvmsg net/socket.c:2845 [inline]
|
|
do_recvmmsg+0x474/0xae0 net/socket.c:2939
|
|
__sys_recvmmsg net/socket.c:3018 [inline]
|
|
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
|
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
|
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7faeb6363db9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
|
|
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
|
|
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
|
|
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
|
|
|
|
The session resources are used by FW and driver when session is offloaded,
|
|
once session is uploaded these resources are not used. The lock is not
|
|
required as these fields won't be used any longer. The offload and upload
|
|
calls are sequential, hence lock is not required.
|
|
|
|
This will suppress following BUG_ON():
|
|
|
|
[ 449.843143] ------------[ cut here ]------------
|
|
[ 449.848302] kernel BUG at mm/vmalloc.c:2727!
|
|
[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
|
[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
|
|
Rebooting.
|
|
[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
|
|
[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
|
|
[ 449.882910] RIP: 0010:vunmap+0x2e/0x30
|
|
[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
|
|
[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
|
|
[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
|
|
[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
|
|
[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
|
|
[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
|
|
[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
|
|
[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
|
|
[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
|
|
[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 449.993028] Call Trace:
|
|
[ 449.995756] __iommu_dma_free+0x96/0x100
|
|
[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
|
|
[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]
|
|
[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
|
|
[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]
|
|
[ 450.023103] process_one_work+0x1e8/0x3c0
|
|
[ 450.027581] worker_thread+0x50/0x3b0
|
|
[ 450.031669] ? rescuer_thread+0x370/0x370
|
|
[ 450.036143] kthread+0x149/0x170
|
|
[ 450.039744] ? set_kthread_struct+0x40/0x40
|
|
[ 450.044411] ret_from_fork+0x22/0x30
|
|
[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
|
|
[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
|
|
[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/qeth: Fix kernel panic after setting hsuid
|
|
|
|
Symptom:
|
|
When the hsuid attribute is set for the first time on an IQD Layer3
|
|
device while the corresponding network interface is already UP,
|
|
the kernel will try to execute a napi function pointer that is NULL.
|
|
|
|
Example:
|
|
---------------------------------------------------------------------------
|
|
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
|
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
|
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
|
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
|
qdio ccwgroup pkey zcrypt
|
|
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
|
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
|
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
|
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
|
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
|
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
|
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
|
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
|
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
|
>0000000000000002: 0000 illegal
|
|
0000000000000004: 0000 illegal
|
|
0000000000000006: 0000 illegal
|
|
0000000000000008: 0000 illegal
|
|
000000000000000a: 0000 illegal
|
|
000000000000000c: 0000 illegal
|
|
000000000000000e: 0000 illegal
|
|
[ 2057.572800] Call Trace:
|
|
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
|
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
|
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
|
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
|
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
|
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
|
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
|
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
|
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
|
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
|
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
|
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
|
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
|
[ 2057.572843] Last Breaking-Event-Address:
|
|
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
|
[ 2057.572846]
|
|
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
|
-------------------------------------------------------------------------------------------
|
|
|
|
Analysis:
|
|
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
|
The napi.poll functions are set during qeth_open().
|
|
|
|
Since
|
|
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
|
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
|
dev_open(). So if qeth_free_qdio_queues() cleared
|
|
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
|
card was offline, they are not set again.
|
|
|
|
Reproduction:
|
|
chzdev -e $devno layer2=0
|
|
ip link set dev $network_interface up
|
|
echo 0 > /sys/bus/ccw
|
|
---truncated---(CVE-2024-36928)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
|
|
|
|
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
|
|
overflow since hdev->le_mtu may not fall in the valid range.
|
|
|
|
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
|
|
process earlier if MTU is invalid.
|
|
Also, add a missing validation in read_buffer_size() and make it return
|
|
an error value if the validation fails.
|
|
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
|
|
kzalloc failure and invalid MTU value.
|
|
|
|
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Workqueue: hci0 hci_rx_work
|
|
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
|
|
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
|
|
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
|
|
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
|
|
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
|
|
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
|
|
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
|
|
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
|
|
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
|
|
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
|
|
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
|
|
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
|
|
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
|
|
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
|
|
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
|
|
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
|
|
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
|
|
process_one_work kernel/workqueue.c:3254 [inline]
|
|
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
|
|
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
|
|
kthread+0x2e3/0x380 kernel/kthread.c:388
|
|
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
|
|
</TASK>
|
|
Modules linked in:
|
|
---[ end trace 0000000000000000 ]---(CVE-2024-36968)
|
|
|
|
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:
|
|
|
|
KEYS: trusted: Do not use WARN when encode fails
|
|
|
|
When asn1_encode_sequence() fails, WARN is not the correct solution.
|
|
|
|
1. asn1_encode_sequence() is not an internal function (located
|
|
in lib/asn1_encode.c).
|
|
2. Location is known, which makes the stack trace useless.
|
|
3. Results a crash if panic_on_warn is set.
|
|
|
|
It is also noteworthy that the use of WARN is undocumented, and it
|
|
should be avoided unless there is a carefully considered rationale to
|
|
use it.
|
|
|
|
Replace WARN with pr_err, and print the return value instead, which is
|
|
only useful piece of information.(CVE-2024-36975)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: dwc3: Wait unconditionally after issuing EndXfer command
|
|
|
|
Currently all controller IP/revisions except DWC3_usb3 >= 310a
|
|
wait 1ms unconditionally for ENDXFER completion when IOC is not
|
|
set. This is because DWC_usb3 controller revisions >= 3.10a
|
|
supports GUCTL2[14: Rst_actbitlater] bit which allows polling
|
|
CMDACT bit to know whether ENDXFER command is completed.
|
|
|
|
Consider a case where an IN request was queued, and parallelly
|
|
soft_disconnect was called (due to ffs_epfile_release). This
|
|
eventually calls stop_active_transfer with IOC cleared, hence
|
|
send_gadget_ep_cmd() skips waiting for CMDACT cleared during
|
|
EndXfer. For DWC3 controllers with revisions >= 310a, we don't
|
|
forcefully wait for 1ms either, and we proceed by unmapping the
|
|
requests. If ENDXFER didn't complete by this time, it leads to
|
|
SMMU faults since the controller would still be accessing those
|
|
requests.
|
|
|
|
Fix this by ensuring ENDXFER completion by adding 1ms delay in
|
|
__dwc3_stop_active_transfer() unconditionally.(CVE-2024-36977)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
|
|
|
|
q->bands will be assigned to qopt->bands to execute subsequent code logic
|
|
after kmalloc. So the old q->bands should not be used in kmalloc.
|
|
Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ring-buffer: Fix a race between readers and resize checks
|
|
|
|
The reader code in rb_get_reader_page() swaps a new reader page into the
|
|
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->prev might not be equal back to page for some page in the
|
|
ring buffer.
|
|
|
|
The resize operation in ring_buffer_resize() can be invoked in parallel.
|
|
It calls rb_check_pages() which can detect the described inconsistency
|
|
and stop further tracing:
|
|
|
|
[ 190.271762] ------------[ cut here ]------------
|
|
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.271789] Modules linked in: [...]
|
|
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
|
|
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
|
|
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
|
|
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.272023] Code: [...]
|
|
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
|
|
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
|
|
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
|
|
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
|
|
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
|
|
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
|
|
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
|
|
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
|
|
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 190.272077] Call Trace:
|
|
[ 190.272098] <TASK>
|
|
[ 190.272189] ring_buffer_resize+0x2ab/0x460
|
|
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
|
|
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
|
|
[ 190.272216] tracing_entries_write+0x74/0xc0
|
|
[ 190.272225] vfs_write+0xf5/0x420
|
|
[ 190.272248] ksys_write+0x67/0xe0
|
|
[ 190.272256] do_syscall_64+0x82/0x170
|
|
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[ 190.272373] RIP: 0033:0x7f1bd657d263
|
|
[ 190.272381] Code: [...]
|
|
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
|
|
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
|
|
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
|
|
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
|
|
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
|
|
[ 190.272412] </TASK>
|
|
[ 190.272414] ---[ end trace 0000000000000000 ]---
|
|
|
|
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
|
|
trace_buffer has recording disabled. Recent commit d78ab792705c
|
|
("tracing: Stop current tracer when resizing buffer") causes that it is
|
|
now always the case which makes it more likely to experience this issue.
|
|
|
|
The window to hit this race is nonetheless very small. To help
|
|
reproducing it, one can add a delay loop in rb_get_reader_page():
|
|
|
|
ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---(CVE-2024-38601)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: core: Fix NULL module pointer assignment at card init
|
|
|
|
The commit 81033c6b584b ("ALSA: core: Warn on empty module")
|
|
introduced a WARN_ON() for a NULL module pointer passed at snd_card
|
|
object creation, and it also wraps the code around it with '#ifdef
|
|
MODULE'. This works in most cases, but the devils are always in
|
|
details. "MODULE" is defined when the target code (i.e. the sound
|
|
core) is built as a module; but this doesn't mean that the caller is
|
|
also built-in or not. Namely, when only the sound core is built-in
|
|
(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
|
|
the passed module pointer is ignored even if it's non-NULL, and
|
|
card->module remains as NULL. This would result in the missing module
|
|
reference up/down at the device open/close, leading to a race with the
|
|
code execution after the module removal.
|
|
|
|
For addressing the bug, move the assignment of card->module again out
|
|
of ifdef. The WARN_ON() is still wrapped with ifdef because the
|
|
module can be really NULL when all sound drivers are built-in.
|
|
|
|
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
|
|
lead to a false-positive NULL module check. Admittedly it won't catch
|
|
perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no
|
|
real problem as it's only for debugging, and the condition is pretty
|
|
rare.(CVE-2024-38605)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: multidev: fix to recognize valid zero block address
|
|
|
|
As reported by Yi Zhang in mailing list [1], kernel warning was catched
|
|
during zbd/010 test as below:
|
|
|
|
./check zbd/010
|
|
zbd/010 (test gap zone support with F2FS) [failed]
|
|
runtime ... 3.752s
|
|
something found in dmesg:
|
|
[ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13
|
|
[ 4378.192349] null_blk: module loaded
|
|
[ 4378.209860] null_blk: disk nullb0 created
|
|
[ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim
|
|
poll_queues to 0. poll_q/nr_hw = (0/1)
|
|
[ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]
|
|
dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0
|
|
[ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux
|
|
scsi_debug 0191 PQ: 0 ANSI: 7
|
|
[ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred
|
|
[ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20
|
|
[ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device
|
|
...
|
|
(See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'
|
|
|
|
WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51
|
|
CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1
|
|
RIP: 0010:iomap_iter+0x32b/0x350
|
|
Call Trace:
|
|
<TASK>
|
|
__iomap_dio_rw+0x1df/0x830
|
|
f2fs_file_read_iter+0x156/0x3d0 [f2fs]
|
|
aio_read+0x138/0x210
|
|
io_submit_one+0x188/0x8c0
|
|
__x64_sys_io_submit+0x8c/0x1a0
|
|
do_syscall_64+0x86/0x170
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Shinichiro Kawasaki helps to analyse this issue and proposes a potential
|
|
fixing patch in [2].
|
|
|
|
Quoted from reply of Shinichiro Kawasaki:
|
|
|
|
"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
|
|
look in the commit, but it looks fine to me. So I thought the cause is not
|
|
in the commit diff.
|
|
|
|
I found the WARN is printed when the f2fs is set up with multiple devices,
|
|
and read requests are mapped to the very first block of the second device in the
|
|
direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()
|
|
modify map->m_pblk as the physical block address from each block device. It
|
|
becomes zero when it is mapped to the first block of the device. However,
|
|
f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the
|
|
whole f2fs, across the all block devices. It compares map->m_pblk against
|
|
NULL_ADDR == 0, then go into the unexpected branch and sets the invalid
|
|
iomap->length. The WARN catches the invalid iomap->length.
|
|
|
|
This WARN is printed even for non-zoned block devices, by following steps.
|
|
|
|
- Create two (non-zoned) null_blk devices memory backed with 128MB size each:
|
|
nullb0 and nullb1.
|
|
# mkfs.f2fs /dev/nullb0 -c /dev/nullb1
|
|
# mount -t f2fs /dev/nullb0 "${mount_dir}"
|
|
# dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192
|
|
# dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct
|
|
|
|
..."
|
|
|
|
So, the root cause of this issue is: when multi-devices feature is on,
|
|
f2fs_map_blocks() may return zero blkaddr in non-primary device, which is
|
|
a verified valid block address, however, f2fs_iomap_begin() treats it as
|
|
an invalid block address, and then it triggers the warning in iomap
|
|
framework code.
|
|
|
|
Finally, as discussed, we decide to use a more simple and direct way that
|
|
checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of
|
|
(map.m_pblk != NULL_ADDR) to fix this issue.
|
|
|
|
Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this
|
|
issue.
|
|
|
|
[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/
|
|
[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/(CVE-2024-38636)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of 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-1766</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36477</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36883</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36902</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36903</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36905</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36919</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36928</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36968</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36974</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36975</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36977</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36978</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38538</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38541</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38549</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38587</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38596</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38601</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38605</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38636</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36477</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36883</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36902</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36903</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36905</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36919</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36928</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36968</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36974</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36975</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36977</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36978</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-38587</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38596</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38601</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38605</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38636</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.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:
|
|
|
|
tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer
|
|
|
|
The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the
|
|
maximum transfer length and the size of the transfer buffer. As such, it
|
|
does not account for the 4 bytes of header that prepends the SPI data
|
|
frame. This can result in out-of-bounds accesses and was confirmed with
|
|
KASAN.
|
|
|
|
Introduce SPI_HDRSIZE to account for the header and use to allocate the
|
|
transfer buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36477</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
net: fix out-of-bounds access in ops_init
|
|
|
|
net_alloc_generic is called by net_alloc, which is called without any
|
|
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
|
|
is read twice, first to allocate an array, then to set s.len, which is
|
|
later used to limit the bounds of the array access.
|
|
|
|
It is possible that the array is allocated and another thread is
|
|
registering a new pernet ops, increments max_gen_ptrs, which is then used
|
|
to set s.len with a larger than allocated length for the variable array.
|
|
|
|
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
|
|
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36883</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
gpiolib: cdev: fix uninitialised kfifo
|
|
|
|
If a line is requested with debounce, and that results in debouncing
|
|
in software, and the line is subsequently reconfigured to enable edge
|
|
detection then the allocation of the kfifo to contain edge events is
|
|
overlooked. This results in events being written to and read from an
|
|
uninitialised kfifo. Read events are returned to userspace.
|
|
|
|
Initialise the kfifo in the case where the software debounce is
|
|
already active.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()syzbot is able to trigger the following crash [1],caused by unsafe ip6_dst_idev() use.Indeed ip6_dst_idev() can return NULL, and must always be checked.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36902</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
ipv6: Fix potential uninit-value access in __ip6_make_skb()
|
|
|
|
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
|
|
__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags
|
|
instead of testing HDRINCL on the socket to avoid a race condition which
|
|
causes uninit-value access.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36903</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
|
|
|
|
TCP_SYN_RECV state is really special, it is only used by
|
|
cross-syn connections, mostly used by fuzzers.
|
|
|
|
In the following crash [1], syzbot managed to trigger a divide
|
|
by zero in tcp_rcv_space_adjust()
|
|
|
|
A socket makes the following state transitions,
|
|
without ever calling tcp_init_transfer(),
|
|
meaning tcp_init_buffer_space() is also not called.
|
|
|
|
TCP_CLOSE
|
|
connect()
|
|
TCP_SYN_SENT
|
|
TCP_SYN_RECV
|
|
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
|
|
TCP_FIN_WAIT1
|
|
|
|
To fix this issue, change tcp_shutdown() to not
|
|
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
|
|
which makes no sense anyway.
|
|
|
|
When tcp_rcv_state_process() later changes socket state
|
|
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
|
|
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
|
|
and send a FIN packet from a sane socket state.
|
|
|
|
This means tcp_send_fin() can now be called from BH
|
|
context, and must use GFP_ATOMIC allocations.
|
|
|
|
[1]
|
|
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
|
|
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
|
|
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
|
|
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
|
|
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
|
|
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
|
|
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
|
|
tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
|
|
inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x109/0x280 net/socket.c:1068
|
|
____sys_recvmsg+0x1db/0x470 net/socket.c:2803
|
|
___sys_recvmsg net/socket.c:2845 [inline]
|
|
do_recvmmsg+0x474/0xae0 net/socket.c:2939
|
|
__sys_recvmmsg net/socket.c:3018 [inline]
|
|
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
|
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
|
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7faeb6363db9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
|
|
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
|
|
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
|
|
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36905</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
|
|
|
|
The session resources are used by FW and driver when session is offloaded,
|
|
once session is uploaded these resources are not used. The lock is not
|
|
required as these fields won't be used any longer. The offload and upload
|
|
calls are sequential, hence lock is not required.
|
|
|
|
This will suppress following BUG_ON():
|
|
|
|
[ 449.843143] ------------[ cut here ]------------
|
|
[ 449.848302] kernel BUG at mm/vmalloc.c:2727!
|
|
[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
|
[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
|
|
Rebooting.
|
|
[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
|
|
[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
|
|
[ 449.882910] RIP: 0010:vunmap+0x2e/0x30
|
|
[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
|
|
[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
|
|
[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
|
|
[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
|
|
[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
|
|
[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
|
|
[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
|
|
[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
|
|
[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
|
|
[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 449.993028] Call Trace:
|
|
[ 449.995756] __iommu_dma_free+0x96/0x100
|
|
[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
|
|
[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]
|
|
[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
|
|
[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]
|
|
[ 450.023103] process_one_work+0x1e8/0x3c0
|
|
[ 450.027581] worker_thread+0x50/0x3b0
|
|
[ 450.031669] ? rescuer_thread+0x370/0x370
|
|
[ 450.036143] kthread+0x149/0x170
|
|
[ 450.039744] ? set_kthread_struct+0x40/0x40
|
|
[ 450.044411] ret_from_fork+0x22/0x30
|
|
[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
|
|
[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
|
|
[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36919</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
s390/qeth: Fix kernel panic after setting hsuid
|
|
|
|
Symptom:
|
|
When the hsuid attribute is set for the first time on an IQD Layer3
|
|
device while the corresponding network interface is already UP,
|
|
the kernel will try to execute a napi function pointer that is NULL.
|
|
|
|
Example:
|
|
---------------------------------------------------------------------------
|
|
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
|
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
|
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
|
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
|
qdio ccwgroup pkey zcrypt
|
|
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
|
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
|
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
|
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
|
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
|
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
|
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
|
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
|
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
|
>0000000000000002: 0000 illegal
|
|
0000000000000004: 0000 illegal
|
|
0000000000000006: 0000 illegal
|
|
0000000000000008: 0000 illegal
|
|
000000000000000a: 0000 illegal
|
|
000000000000000c: 0000 illegal
|
|
000000000000000e: 0000 illegal
|
|
[ 2057.572800] Call Trace:
|
|
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
|
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
|
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
|
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
|
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
|
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
|
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
|
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
|
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
|
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
|
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
|
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
|
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
|
[ 2057.572843] Last Breaking-Event-Address:
|
|
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
|
[ 2057.572846]
|
|
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
|
-------------------------------------------------------------------------------------------
|
|
|
|
Analysis:
|
|
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
|
The napi.poll functions are set during qeth_open().
|
|
|
|
Since
|
|
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
|
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
|
dev_open(). So if qeth_free_qdio_queues() cleared
|
|
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
|
card was offline, they are not set again.
|
|
|
|
Reproduction:
|
|
chzdev -e $devno layer2=0
|
|
ip link set dev $network_interface up
|
|
echo 0 > /sys/bus/ccw
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36928</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
|
|
|
|
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
|
|
overflow since hdev->le_mtu may not fall in the valid range.
|
|
|
|
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
|
|
process earlier if MTU is invalid.
|
|
Also, add a missing validation in read_buffer_size() and make it return
|
|
an error value if the validation fails.
|
|
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
|
|
kzalloc failure and invalid MTU value.
|
|
|
|
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Workqueue: hci0 hci_rx_work
|
|
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
|
|
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
|
|
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
|
|
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
|
|
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
|
|
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
|
|
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
|
|
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
|
|
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
|
|
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
|
|
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
|
|
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
|
|
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
|
|
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
|
|
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
|
|
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
|
|
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
|
|
process_one_work kernel/workqueue.c:3254 [inline]
|
|
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
|
|
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
|
|
kthread+0x2e3/0x380 kernel/kthread.c:388
|
|
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
|
|
</TASK>
|
|
Modules linked in:
|
|
---[ end trace 0000000000000000 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36968</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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">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-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36974</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
KEYS: trusted: Do not use WARN when encode fails
|
|
|
|
When asn1_encode_sequence() fails, WARN is not the correct solution.
|
|
|
|
1. asn1_encode_sequence() is not an internal function (located
|
|
in lib/asn1_encode.c).
|
|
2. Location is known, which makes the stack trace useless.
|
|
3. Results a crash if panic_on_warn is set.
|
|
|
|
It is also noteworthy that the use of WARN is undocumented, and it
|
|
should be avoided unless there is a carefully considered rationale to
|
|
use it.
|
|
|
|
Replace WARN with pr_err, and print the return value instead, which is
|
|
only useful piece of information.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36975</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
usb: dwc3: Wait unconditionally after issuing EndXfer command
|
|
|
|
Currently all controller IP/revisions except DWC3_usb3 >= 310a
|
|
wait 1ms unconditionally for ENDXFER completion when IOC is not
|
|
set. This is because DWC_usb3 controller revisions >= 3.10a
|
|
supports GUCTL2[14: Rst_actbitlater] bit which allows polling
|
|
CMDACT bit to know whether ENDXFER command is completed.
|
|
|
|
Consider a case where an IN request was queued, and parallelly
|
|
soft_disconnect was called (due to ffs_epfile_release). This
|
|
eventually calls stop_active_transfer with IOC cleared, hence
|
|
send_gadget_ep_cmd() skips waiting for CMDACT cleared during
|
|
EndXfer. For DWC3 controllers with revisions >= 310a, we don't
|
|
forcefully wait for 1ms either, and we proceed by unmapping the
|
|
requests. If ENDXFER didn't complete by this time, it leads to
|
|
SMMU faults since the controller would still be accessing those
|
|
requests.
|
|
|
|
Fix this by ensuring ENDXFER completion by adding 1ms delay in
|
|
__dwc3_stop_active_transfer() unconditionally.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36977</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
|
|
|
|
q->bands will be assigned to qopt->bands to execute subsequent code logic
|
|
after kmalloc. So the old q->bands should not be used in kmalloc.
|
|
Otherwise, an out-of-bounds write will occur.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36978</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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: 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-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38538</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
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-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38541</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
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-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38549</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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:
|
|
|
|
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-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38587</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38596</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>2.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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</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="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ring-buffer: Fix a race between readers and resize checks
|
|
|
|
The reader code in rb_get_reader_page() swaps a new reader page into the
|
|
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->prev might not be equal back to page for some page in the
|
|
ring buffer.
|
|
|
|
The resize operation in ring_buffer_resize() can be invoked in parallel.
|
|
It calls rb_check_pages() which can detect the described inconsistency
|
|
and stop further tracing:
|
|
|
|
[ 190.271762] ------------[ cut here ]------------
|
|
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.271789] Modules linked in: [...]
|
|
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
|
|
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
|
|
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
|
|
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.272023] Code: [...]
|
|
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
|
|
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
|
|
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
|
|
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
|
|
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
|
|
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
|
|
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
|
|
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
|
|
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 190.272077] Call Trace:
|
|
[ 190.272098] <TASK>
|
|
[ 190.272189] ring_buffer_resize+0x2ab/0x460
|
|
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
|
|
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
|
|
[ 190.272216] tracing_entries_write+0x74/0xc0
|
|
[ 190.272225] vfs_write+0xf5/0x420
|
|
[ 190.272248] ksys_write+0x67/0xe0
|
|
[ 190.272256] do_syscall_64+0x82/0x170
|
|
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[ 190.272373] RIP: 0033:0x7f1bd657d263
|
|
[ 190.272381] Code: [...]
|
|
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
|
|
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
|
|
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
|
|
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
|
|
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
|
|
[ 190.272412] </TASK>
|
|
[ 190.272414] ---[ end trace 0000000000000000 ]---
|
|
|
|
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
|
|
trace_buffer has recording disabled. Recent commit d78ab792705c
|
|
("tracing: Stop current tracer when resizing buffer") causes that it is
|
|
now always the case which makes it more likely to experience this issue.
|
|
|
|
The window to hit this race is nonetheless very small. To help
|
|
reproducing it, one can add a delay loop in rb_get_reader_page():
|
|
|
|
ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38601</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: core: Fix NULL module pointer assignment at card init
|
|
|
|
The commit 81033c6b584b ("ALSA: core: Warn on empty module")
|
|
introduced a WARN_ON() for a NULL module pointer passed at snd_card
|
|
object creation, and it also wraps the code around it with '#ifdef
|
|
MODULE'. This works in most cases, but the devils are always in
|
|
details. "MODULE" is defined when the target code (i.e. the sound
|
|
core) is built as a module; but this doesn't mean that the caller is
|
|
also built-in or not. Namely, when only the sound core is built-in
|
|
(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
|
|
the passed module pointer is ignored even if it's non-NULL, and
|
|
card->module remains as NULL. This would result in the missing module
|
|
reference up/down at the device open/close, leading to a race with the
|
|
code execution after the module removal.
|
|
|
|
For addressing the bug, move the assignment of card->module again out
|
|
of ifdef. The WARN_ON() is still wrapped with ifdef because the
|
|
module can be really NULL when all sound drivers are built-in.
|
|
|
|
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
|
|
lead to a false-positive NULL module check. Admittedly it won't catch
|
|
perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no
|
|
real problem as it's only for debugging, and the condition is pretty
|
|
rare.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38605</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: multidev: fix to recognize valid zero block address
|
|
|
|
As reported by Yi Zhang in mailing list [1], kernel warning was catched
|
|
during zbd/010 test as below:
|
|
|
|
./check zbd/010
|
|
zbd/010 (test gap zone support with F2FS) [failed]
|
|
runtime ... 3.752s
|
|
something found in dmesg:
|
|
[ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13
|
|
[ 4378.192349] null_blk: module loaded
|
|
[ 4378.209860] null_blk: disk nullb0 created
|
|
[ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim
|
|
poll_queues to 0. poll_q/nr_hw = (0/1)
|
|
[ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]
|
|
dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0
|
|
[ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux
|
|
scsi_debug 0191 PQ: 0 ANSI: 7
|
|
[ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred
|
|
[ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20
|
|
[ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device
|
|
...
|
|
(See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'
|
|
|
|
WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51
|
|
CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1
|
|
RIP: 0010:iomap_iter+0x32b/0x350
|
|
Call Trace:
|
|
<TASK>
|
|
__iomap_dio_rw+0x1df/0x830
|
|
f2fs_file_read_iter+0x156/0x3d0 [f2fs]
|
|
aio_read+0x138/0x210
|
|
io_submit_one+0x188/0x8c0
|
|
__x64_sys_io_submit+0x8c/0x1a0
|
|
do_syscall_64+0x86/0x170
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Shinichiro Kawasaki helps to analyse this issue and proposes a potential
|
|
fixing patch in [2].
|
|
|
|
Quoted from reply of Shinichiro Kawasaki:
|
|
|
|
"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
|
|
look in the commit, but it looks fine to me. So I thought the cause is not
|
|
in the commit diff.
|
|
|
|
I found the WARN is printed when the f2fs is set up with multiple devices,
|
|
and read requests are mapped to the very first block of the second device in the
|
|
direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()
|
|
modify map->m_pblk as the physical block address from each block device. It
|
|
becomes zero when it is mapped to the first block of the device. However,
|
|
f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the
|
|
whole f2fs, across the all block devices. It compares map->m_pblk against
|
|
NULL_ADDR == 0, then go into the unexpected branch and sets the invalid
|
|
iomap->length. The WARN catches the invalid iomap->length.
|
|
|
|
This WARN is printed even for non-zoned block devices, by following steps.
|
|
|
|
- Create two (non-zoned) null_blk devices memory backed with 128MB size each:
|
|
nullb0 and nullb1.
|
|
# mkfs.f2fs /dev/nullb0 -c /dev/nullb1
|
|
# mount -t f2fs /dev/nullb0 "${mount_dir}"
|
|
# dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192
|
|
# dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct
|
|
|
|
..."
|
|
|
|
So, the root cause of this issue is: when multi-devices feature is on,
|
|
f2fs_map_blocks() may return zero blkaddr in non-primary device, which is
|
|
a verified valid block address, however, f2fs_iomap_begin() treats it as
|
|
an invalid block address, and then it triggers the warning in iomap
|
|
framework code.
|
|
|
|
Finally, as discussed, we decide to use a more simple and direct way that
|
|
checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of
|
|
(map.m_pblk != NULL_ADDR) to fix this issue.
|
|
|
|
Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this
|
|
issue.
|
|
|
|
[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/
|
|
[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38636</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |