2089 lines
94 KiB
XML
2089 lines
94 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1541</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-10</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-10</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-10</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-10</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore/ram: Fix crash when setting number of cpus to an odd number
|
|
|
|
When the number of cpu cores is adjusted to 7 or other odd numbers,
|
|
the zone size will become an odd number.
|
|
The address of the zone will become:
|
|
addr of zone0 = BASE
|
|
addr of zone1 = BASE + zone_size
|
|
addr of zone2 = BASE + zone_size*2
|
|
...
|
|
The address of zone1/3/5/7 will be mapped to non-alignment va.
|
|
Eventually crashes will occur when accessing these va.
|
|
|
|
So, use ALIGN_DOWN() to make sure the zone size is even
|
|
to avoid this bug.(CVE-2023-52619)
|
|
|
|
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
(CVE-2024-24860)
|
|
|
|
create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.(CVE-2024-25739)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: sii902x: Fix probing race issue
|
|
|
|
A null pointer dereference crash has been observed rarely on TI
|
|
platforms using sii9022 bridge:
|
|
|
|
[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x]
|
|
[ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x]
|
|
[ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm]
|
|
[ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
|
|
[ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
|
|
[ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm]
|
|
[ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
|
|
[ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
|
|
[ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
|
|
[ 53.326401] drm_client_register+0x5c/0xa0 [drm]
|
|
[ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
|
|
[ 53.336881] tidss_probe+0x128/0x264 [tidss]
|
|
[ 53.341174] platform_probe+0x68/0xc4
|
|
[ 53.344841] really_probe+0x188/0x3c4
|
|
[ 53.348501] __driver_probe_device+0x7c/0x16c
|
|
[ 53.352854] driver_probe_device+0x3c/0x10c
|
|
[ 53.357033] __device_attach_driver+0xbc/0x158
|
|
[ 53.361472] bus_for_each_drv+0x88/0xe8
|
|
[ 53.365303] __device_attach+0xa0/0x1b4
|
|
[ 53.369135] device_initial_probe+0x14/0x20
|
|
[ 53.373314] bus_probe_device+0xb0/0xb4
|
|
[ 53.377145] deferred_probe_work_func+0xcc/0x124
|
|
[ 53.381757] process_one_work+0x1f0/0x518
|
|
[ 53.385770] worker_thread+0x1e8/0x3dc
|
|
[ 53.389519] kthread+0x11c/0x120
|
|
[ 53.392750] ret_from_fork+0x10/0x20
|
|
|
|
The issue here is as follows:
|
|
|
|
- tidss probes, but is deferred as sii902x is still missing.
|
|
- sii902x starts probing and enters sii902x_init().
|
|
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
|
|
DRM's perspective.
|
|
- sii902x calls sii902x_audio_codec_init() and
|
|
platform_device_register_data()
|
|
- The registration of the audio platform device causes probing of the
|
|
deferred devices.
|
|
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
|
|
called.
|
|
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
|
|
However, the sii902x driver has not set up the i2c part yet, leading
|
|
to the crash.
|
|
|
|
Fix this by moving the drm_bridge_add() to the end of the
|
|
sii902x_init(), which is also at the very end of sii902x_probe().(CVE-2024-26607)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: make sure init the accept_queue's spinlocks once
|
|
|
|
When I run syz's reproduction C program locally, it causes the following
|
|
issue:
|
|
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
|
|
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
|
|
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
|
|
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
|
|
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
|
|
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
|
|
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
|
|
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
|
|
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<IRQ>
|
|
_raw_spin_unlock (kernel/locking/spinlock.c:186)
|
|
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
|
|
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
|
|
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
|
|
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
|
|
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
|
|
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
|
|
__netif_receive_skb_one_core (net/core/dev.c:5529)
|
|
process_backlog (./include/linux/rcupdate.h:779)
|
|
__napi_poll (net/core/dev.c:6533)
|
|
net_rx_action (net/core/dev.c:6604)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
|
|
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip (kernel/softirq.c:381)
|
|
__dev_queue_xmit (net/core/dev.c:4374)
|
|
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
|
|
__ip_queue_xmit (net/ipv4/ip_output.c:535)
|
|
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
|
|
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
|
|
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
|
|
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
|
|
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
|
|
release_sock (net/core/sock.c:3536)
|
|
inet_wait_for_connect (net/ipv4/af_inet.c:609)
|
|
__inet_stream_connect (net/ipv4/af_inet.c:702)
|
|
inet_stream_connect (net/ipv4/af_inet.c:748)
|
|
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
|
|
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
|
|
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
RIP: 0033:0x7fa10ff05a3d
|
|
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
|
|
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
|
|
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
|
|
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
|
|
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
|
|
</TASK>
|
|
|
|
The issue triggering process is analyzed as follows:
|
|
Thread A Thread B
|
|
tcp_v4_rcv //receive ack TCP packet inet_shutdown
|
|
tcp_check_req tcp_disconnect //disconnect sock
|
|
... tcp_set_state(sk, TCP_CLOSE)
|
|
inet_csk_complete_hashdance ...
|
|
inet_csk_reqsk_queue_add
|
|
---truncated---(CVE-2024-26614)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendms
|
|
---truncated---(CVE-2024-26633)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
|
|
|
|
If the source file descriptor to the snapshot ioctl refers to a deleted
|
|
subvolume, we get the following abort:
|
|
|
|
BTRFS: Transaction aborted (error -2)
|
|
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
|
|
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
|
|
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
|
|
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
|
|
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
|
|
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
|
|
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<TASK>
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? __warn+0x81/0x130
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? report_bug+0x171/0x1a0
|
|
? handle_bug+0x3a/0x70
|
|
? exc_invalid_op+0x17/0x70
|
|
? asm_exc_invalid_op+0x1a/0x20
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
create_pending_snapshots+0x92/0xc0 [btrfs]
|
|
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
|
|
btrfs_mksubvol+0x301/0x4d0 [btrfs]
|
|
btrfs_mksnapshot+0x80/0xb0 [btrfs]
|
|
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
|
|
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
|
|
btrfs_ioctl+0x8a6/0x2650 [btrfs]
|
|
? kmem_cache_free+0x22/0x340
|
|
? do_sys_openat2+0x97/0xe0
|
|
__x64_sys_ioctl+0x97/0xd0
|
|
do_syscall_64+0x46/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
RIP: 0033:0x7fe20abe83af
|
|
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
|
|
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
|
|
BTRFS info (device vdc: state EA): forced readonly
|
|
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
|
|
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
|
|
|
|
This happens because create_pending_snapshot() initializes the new root
|
|
item as a copy of the source root item. This includes the refs field,
|
|
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
|
|
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
|
|
finds the root and returns -ENOENT if refs == 0, which causes
|
|
create_pending_snapshot() to abort.
|
|
|
|
Fix it by checking the source root's refs before attempting the
|
|
snapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
|
|
|
|
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
|
|
VMBus channel"), napi_disable was getting called for all channels,
|
|
including all subchannels without confirming if they are enabled or not.
|
|
|
|
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
|
|
has finished running but nvdev->subchan_work has not started yet.
|
|
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
|
|
sub-channels and because of that netvsc_sc_open() is not running.
|
|
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
|
|
netvsc_subchan_work did not run.
|
|
|
|
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
|
|
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
|
|
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
|
|
opposite.
|
|
|
|
Now during netvsc_device_remove(), when napi_disable is called for those
|
|
subchannels, napi_disable gets stuck on infinite msleep.
|
|
|
|
This fix addresses this problem by ensuring that napi_disable() is not
|
|
getting called for non-enabled NAPI struct.
|
|
But netif_napi_del() is still necessary for these non-enabled NAPI struct
|
|
for cleanup purpose.
|
|
|
|
Call trace:
|
|
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
|
|
[ 654.568030] Call Trace:
|
|
[ 654.571221] <TASK>
|
|
[ 654.573790] __schedule+0x2d6/0x960
|
|
[ 654.577733] schedule+0x69/0xf0
|
|
[ 654.581214] schedule_timeout+0x87/0x140
|
|
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
|
|
[ 654.590291] msleep+0x2d/0x40
|
|
[ 654.593625] napi_disable+0x2b/0x80
|
|
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
|
|
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
|
|
[ 654.611101] ? do_wait_intr+0xb0/0xb0
|
|
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
|
|
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus](CVE-2024-26698)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
afs: Increase buffer size in afs_update_volume_status()
|
|
|
|
The max length of volume->vid value is 20 characters.
|
|
So increase idbuf[] size up to 24 to avoid overflow.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()](CVE-2024-26736)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ARM: ep93xx: Add terminator to gpiod_lookup_table
|
|
|
|
Without the terminator, if a con_id is passed to gpio_find() that
|
|
does not exist in the lookup table the function will not stop looping
|
|
correctly, and eventually cause an oops.(CVE-2024-26751)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
|
|
|
|
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
|
|
following kernel warning appears:
|
|
|
|
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
|
|
Call trace:
|
|
kiocb_set_cancel_fn+0x9c/0xa8
|
|
ffs_epfile_read_iter+0x144/0x1d0
|
|
io_read+0x19c/0x498
|
|
io_issue_sqe+0x118/0x27c
|
|
io_submit_sqes+0x25c/0x5fc
|
|
__arm64_sys_io_uring_enter+0x104/0xab0
|
|
invoke_syscall+0x58/0x11c
|
|
el0_svc_common+0xb4/0xf4
|
|
do_el0_svc+0x2c/0xb0
|
|
el0_svc+0x2c/0xa4
|
|
el0t_64_sync_handler+0x68/0xb4
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
|
|
submitted by libaio.(CVE-2024-26764)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
|
|
|
|
Places the logic for checking if the group's block bitmap is corrupt under
|
|
the protection of the group lock to avoid allocating blocks from the group
|
|
with a corrupted block bitmap.(CVE-2024-26772)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
|
|
|
|
Determine if the group block bitmap is corrupted before using ac_b_ex in
|
|
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
|
|
corrupted block bitmap in the following concurrency and making the
|
|
situation worse.
|
|
|
|
ext4_mb_regular_allocator
|
|
ext4_lock_group(sb, group)
|
|
ext4_mb_good_group
|
|
// check if the group bbitmap is corrupted
|
|
ext4_mb_complex_scan_group
|
|
// Scan group gets ac_b_ex but doesn't use it
|
|
ext4_unlock_group(sb, group)
|
|
ext4_mark_group_bitmap_corrupted(group)
|
|
// The block bitmap was corrupted during
|
|
// the group unlock gap.
|
|
ext4_mb_try_best_found
|
|
ext4_lock_group(ac->ac_sb, group)
|
|
ext4_mb_use_best_found
|
|
mb_mark_used
|
|
// Allocating blocks in block bitmap corrupted group(CVE-2024-26773)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: sis: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
|
|
drate before it is checked against zero. Fix this by checking it
|
|
at the beginning.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.(CVE-2024-26777)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: savage: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
Although pixclock is checked in savagefb_decode_var(), but it is not
|
|
checked properly in savagefb_probe(). Fix this by checking whether
|
|
pixclock is zero in the function savagefb_check_var() before
|
|
info->var.pixclock is used as the divisor.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.(CVE-2024-26778)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: fsl-qdma: init irq after reg initialization
|
|
|
|
Initialize the qDMA irqs after the registers are configured so that
|
|
interrupts that may have been pending from a primary kernel don't get
|
|
processed by the irq handler before it is ready to and cause panic with
|
|
the following trace:
|
|
|
|
Call trace:
|
|
fsl_qdma_queue_handler+0xf8/0x3e8
|
|
__handle_irq_event_percpu+0x78/0x2b0
|
|
handle_irq_event_percpu+0x1c/0x68
|
|
handle_irq_event+0x44/0x78
|
|
handle_fasteoi_irq+0xc8/0x178
|
|
generic_handle_irq+0x24/0x38
|
|
__handle_domain_irq+0x90/0x100
|
|
gic_handle_irq+0x5c/0xb8
|
|
el1_irq+0xb8/0x180
|
|
_raw_spin_unlock_irqrestore+0x14/0x40
|
|
__setup_irq+0x4bc/0x798
|
|
request_threaded_irq+0xd8/0x190
|
|
devm_request_threaded_irq+0x74/0xe8
|
|
fsl_qdma_probe+0x4d4/0xca8
|
|
platform_drv_probe+0x50/0xa0
|
|
really_probe+0xe0/0x3f8
|
|
driver_probe_device+0x64/0x130
|
|
device_driver_attach+0x6c/0x78
|
|
__driver_attach+0xbc/0x158
|
|
bus_for_each_dev+0x5c/0x98
|
|
driver_attach+0x20/0x28
|
|
bus_add_driver+0x158/0x220
|
|
driver_register+0x60/0x110
|
|
__platform_driver_register+0x44/0x50
|
|
fsl_qdma_driver_init+0x18/0x20
|
|
do_one_initcall+0x48/0x258
|
|
kernel_init_freeable+0x1a4/0x23c
|
|
kernel_init+0x10/0xf8
|
|
ret_from_fork+0x10/0x18(CVE-2024-26788)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Lock external INTx masking ops
|
|
|
|
Mask operations through config space changes to DisINTx may race INTx
|
|
configuration changes via ioctl. Create wrappers that add locking for
|
|
paths outside of the core interrupt code.
|
|
|
|
In particular, irq_type is updated holding igate, therefore testing
|
|
is_intx() requires holding igate. For example clearing DisINTx from
|
|
config space can otherwise race changes of the interrupt configuration.
|
|
|
|
This aligns interfaces which may trigger the INTx eventfd into two
|
|
camps, one side serialized by igate and the other only enabled while
|
|
INTx is configured. A subsequent patch introduces synchronization for
|
|
the latter flows.(CVE-2024-26810)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Fix stackmap overflow check on 32-bit arches
|
|
|
|
The stackmap code relies on roundup_pow_of_two() to compute the number
|
|
of hash buckets, and contains an overflow check by checking if the
|
|
resulting value is 0. However, on 32-bit arches, the roundup code itself
|
|
can overflow by doing a 32-bit left-shift of an unsigned long value,
|
|
which is undefined behaviour, so it is not guaranteed to truncate
|
|
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
|
|
contains the same check, copied from the hashtab code.
|
|
|
|
The commit in the fixes tag actually attempted to fix this, but the fix
|
|
did not account for the UB, so the fix only works on CPUs where an
|
|
overflow does result in a neat truncation to zero, which is not
|
|
guaranteed. Checking the value before rounding does not have this
|
|
problem.(CVE-2024-26883)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Fix hashtab overflow check on 32-bit arches
|
|
|
|
The hashtab code relies on roundup_pow_of_two() to compute the number of
|
|
hash buckets, and contains an overflow check by checking if the
|
|
resulting value is 0. However, on 32-bit arches, the roundup code itself
|
|
can overflow by doing a 32-bit left-shift of an unsigned long value,
|
|
which is undefined behaviour, so it is not guaranteed to truncate
|
|
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
|
|
contains the same check, copied from the hashtab code. So apply the same
|
|
fix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
|
|
|
|
The devmap code allocates a number hash buckets equal to the next power
|
|
of two of the max_entries value provided when creating the map. When
|
|
rounding up to the next power of two, the 32-bit variable storing the
|
|
number of buckets can overflow, and the code checks for overflow by
|
|
checking if the truncated 32-bit value is equal to 0. However, on 32-bit
|
|
arches the rounding up itself can overflow mid-way through, because it
|
|
ends up doing a left-shift of 32 bits on an unsigned long value. If the
|
|
size of an unsigned long is four bytes, this is undefined behaviour, so
|
|
there is no guarantee that we'll end up with a nice and tidy 0-value at
|
|
the end.
|
|
|
|
Syzbot managed to turn this into a crash on arm32 by creating a
|
|
DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
|
|
Fix this by moving the overflow check to before the rounding up
|
|
operation.(CVE-2024-26885)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
|
|
|
|
This patch is against CVE-2023-6270. The description of cve is:
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
|
|
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
|
|
`struct net_device`, and a use-after-free can be triggered by racing
|
|
between the free on the struct and the access through the `skbtxq`
|
|
global queue. This could lead to a denial of service condition or
|
|
potential code execution.
|
|
|
|
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
|
|
code is finished. But the net_device ifp will still be used in
|
|
later tx()->dev_queue_xmit() in kthread. Which means that the
|
|
dev_put(ifp) should NOT be called in the success path of skb
|
|
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
|
|
use-after-free because the net_device is freed.
|
|
|
|
This patch removed the dev_put(ifp) in the success path in
|
|
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().(CVE-2024-26898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
|
|
|
|
------------[ cut here ]------------
|
|
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
|
|
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
|
|
[last unloaded: mlx_compat(OE)]
|
|
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
|
|
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
|
|
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
|
|
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
|
|
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x72/0x90
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? __warn+0x8d/0x160
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? report_bug+0x1bb/0x1d0
|
|
? handle_bug+0x46/0x90
|
|
? exc_invalid_op+0x19/0x80
|
|
? asm_exc_invalid_op+0x1b/0x20
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
|
|
ipoib_send+0x2ec/0x770 [ib_ipoib]
|
|
ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
|
|
dev_hard_start_xmit+0x8e/0x1e0
|
|
? validate_xmit_skb_list+0x4d/0x80
|
|
sch_direct_xmit+0x116/0x3a0
|
|
__dev_xmit_skb+0x1fd/0x580
|
|
__dev_queue_xmit+0x284/0x6b0
|
|
? _raw_spin_unlock_irq+0xe/0x50
|
|
? __flush_work.isra.0+0x20d/0x370
|
|
? push_pseudo_header+0x17/0x40 [ib_ipoib]
|
|
neigh_connected_output+0xcd/0x110
|
|
ip_finish_output2+0x179/0x480
|
|
? __smp_call_single_queue+0x61/0xa0
|
|
__ip_finish_output+0xc3/0x190
|
|
ip_finish_output+0x2e/0xf0
|
|
ip_output+0x78/0x110
|
|
? __pfx_ip_finish_output+0x10/0x10
|
|
ip_local_out+0x64/0x70
|
|
__ip_queue_xmit+0x18a/0x460
|
|
ip_queue_xmit+0x15/0x30
|
|
__tcp_transmit_skb+0x914/0x9c0
|
|
tcp_write_xmit+0x334/0x8d0
|
|
tcp_push_one+0x3c/0x60
|
|
tcp_sendmsg_locked+0x2e1/0xac0
|
|
tcp_sendmsg+0x2d/0x50
|
|
inet_sendmsg+0x43/0x90
|
|
sock_sendmsg+0x68/0x80
|
|
sock_write_iter+0x93/0x100
|
|
vfs_write+0x326/0x3c0
|
|
ksys_write+0xbd/0xf0
|
|
? do_syscall_64+0x69/0x90
|
|
__x64_sys_write+0x19/0x30
|
|
do_syscall_
|
|
---truncated---(CVE-2024-26907)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Disable auto-enable of exclusive INTx IRQ
|
|
|
|
Currently for devices requiring masking at the irqchip for INTx, ie.
|
|
devices without DisINTx support, the IRQ is enabled in request_irq()
|
|
and subsequently disabled as necessary to align with the masked status
|
|
flag. This presents a window where the interrupt could fire between
|
|
these events, resulting in the IRQ incrementing the disable depth twice.
|
|
This would be unrecoverable for a user since the masked flag prevents
|
|
nested enables through vfio.
|
|
|
|
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
|
|
is never auto-enabled, then unmask as required.(CVE-2024-27437)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52619</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24860</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-25739</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26607</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26614</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26633</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26644</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26698</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26736</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26751</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26764</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26772</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26773</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26777</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26778</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26788</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26810</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26883</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26884</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26885</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26907</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27437</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52619</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24860</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-25739</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26607</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26614</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26644</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26698</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26736</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26751</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26764</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26772</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26773</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26777</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26778</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26788</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26810</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26883</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26884</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26885</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26907</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27437</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-source-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.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:
|
|
|
|
pstore/ram: Fix crash when setting number of cpus to an odd number
|
|
|
|
When the number of cpu cores is adjusted to 7 or other odd numbers,
|
|
the zone size will become an odd number.
|
|
The address of the zone will become:
|
|
addr of zone0 = BASE
|
|
addr of zone1 = BASE + zone_size
|
|
addr of zone2 = BASE + zone_size*2
|
|
...
|
|
The address of zone1/3/5/7 will be mapped to non-alignment va.
|
|
Eventually crashes will occur when accessing these va.
|
|
|
|
So, use ALIGN_DOWN() to make sure the zone size is even
|
|
to avoid this bug.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2023-52619</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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">A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-24860</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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">create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-25739</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
drm/bridge: sii902x: Fix probing race issue
|
|
|
|
A null pointer dereference crash has been observed rarely on TI
|
|
platforms using sii9022 bridge:
|
|
|
|
[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x]
|
|
[ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x]
|
|
[ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm]
|
|
[ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
|
|
[ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
|
|
[ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm]
|
|
[ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
|
|
[ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
|
|
[ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
|
|
[ 53.326401] drm_client_register+0x5c/0xa0 [drm]
|
|
[ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
|
|
[ 53.336881] tidss_probe+0x128/0x264 [tidss]
|
|
[ 53.341174] platform_probe+0x68/0xc4
|
|
[ 53.344841] really_probe+0x188/0x3c4
|
|
[ 53.348501] __driver_probe_device+0x7c/0x16c
|
|
[ 53.352854] driver_probe_device+0x3c/0x10c
|
|
[ 53.357033] __device_attach_driver+0xbc/0x158
|
|
[ 53.361472] bus_for_each_drv+0x88/0xe8
|
|
[ 53.365303] __device_attach+0xa0/0x1b4
|
|
[ 53.369135] device_initial_probe+0x14/0x20
|
|
[ 53.373314] bus_probe_device+0xb0/0xb4
|
|
[ 53.377145] deferred_probe_work_func+0xcc/0x124
|
|
[ 53.381757] process_one_work+0x1f0/0x518
|
|
[ 53.385770] worker_thread+0x1e8/0x3dc
|
|
[ 53.389519] kthread+0x11c/0x120
|
|
[ 53.392750] ret_from_fork+0x10/0x20
|
|
|
|
The issue here is as follows:
|
|
|
|
- tidss probes, but is deferred as sii902x is still missing.
|
|
- sii902x starts probing and enters sii902x_init().
|
|
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
|
|
DRM's perspective.
|
|
- sii902x calls sii902x_audio_codec_init() and
|
|
platform_device_register_data()
|
|
- The registration of the audio platform device causes probing of the
|
|
deferred devices.
|
|
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
|
|
called.
|
|
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
|
|
However, the sii902x driver has not set up the i2c part yet, leading
|
|
to the crash.
|
|
|
|
Fix this by moving the drm_bridge_add() to the end of the
|
|
sii902x_init(), which is also at the very end of sii902x_probe().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26607</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
tcp: make sure init the accept_queue's spinlocks once
|
|
|
|
When I run syz's reproduction C program locally, it causes the following
|
|
issue:
|
|
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
|
|
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
|
|
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
|
|
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
|
|
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
|
|
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
|
|
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
|
|
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
|
|
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<IRQ>
|
|
_raw_spin_unlock (kernel/locking/spinlock.c:186)
|
|
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
|
|
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
|
|
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
|
|
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
|
|
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
|
|
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
|
|
__netif_receive_skb_one_core (net/core/dev.c:5529)
|
|
process_backlog (./include/linux/rcupdate.h:779)
|
|
__napi_poll (net/core/dev.c:6533)
|
|
net_rx_action (net/core/dev.c:6604)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
|
|
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip (kernel/softirq.c:381)
|
|
__dev_queue_xmit (net/core/dev.c:4374)
|
|
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
|
|
__ip_queue_xmit (net/ipv4/ip_output.c:535)
|
|
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
|
|
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
|
|
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
|
|
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
|
|
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
|
|
release_sock (net/core/sock.c:3536)
|
|
inet_wait_for_connect (net/ipv4/af_inet.c:609)
|
|
__inet_stream_connect (net/ipv4/af_inet.c:702)
|
|
inet_stream_connect (net/ipv4/af_inet.c:748)
|
|
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
|
|
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
|
|
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
RIP: 0033:0x7fa10ff05a3d
|
|
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
|
|
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
|
|
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
|
|
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
|
|
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
|
|
</TASK>
|
|
|
|
The issue triggering process is analyzed as follows:
|
|
Thread A Thread B
|
|
tcp_v4_rcv //receive ack TCP packet inet_shutdown
|
|
tcp_check_req tcp_disconnect //disconnect sock
|
|
... tcp_set_state(sk, TCP_CLOSE)
|
|
inet_csk_complete_hashdance ...
|
|
inet_csk_reqsk_queue_add
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26614</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.9</BaseScore>
|
|
<Vector>AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendms
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26633</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
|
|
|
|
If the source file descriptor to the snapshot ioctl refers to a deleted
|
|
subvolume, we get the following abort:
|
|
|
|
BTRFS: Transaction aborted (error -2)
|
|
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
|
|
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
|
|
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
|
|
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
|
|
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
|
|
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
|
|
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<TASK>
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? __warn+0x81/0x130
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? report_bug+0x171/0x1a0
|
|
? handle_bug+0x3a/0x70
|
|
? exc_invalid_op+0x17/0x70
|
|
? asm_exc_invalid_op+0x1a/0x20
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
create_pending_snapshots+0x92/0xc0 [btrfs]
|
|
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
|
|
btrfs_mksubvol+0x301/0x4d0 [btrfs]
|
|
btrfs_mksnapshot+0x80/0xb0 [btrfs]
|
|
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
|
|
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
|
|
btrfs_ioctl+0x8a6/0x2650 [btrfs]
|
|
? kmem_cache_free+0x22/0x340
|
|
? do_sys_openat2+0x97/0xe0
|
|
__x64_sys_ioctl+0x97/0xd0
|
|
do_syscall_64+0x46/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
RIP: 0033:0x7fe20abe83af
|
|
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
|
|
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
|
|
BTRFS info (device vdc: state EA): forced readonly
|
|
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
|
|
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
|
|
|
|
This happens because create_pending_snapshot() initializes the new root
|
|
item as a copy of the source root item. This includes the refs field,
|
|
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
|
|
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
|
|
finds the root and returns -ENOENT if refs == 0, which causes
|
|
create_pending_snapshot() to abort.
|
|
|
|
Fix it by checking the source root's refs before attempting the
|
|
snapshot, but after locking subvol_sem to avoid racing with deletion.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26644</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
|
|
|
|
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
|
|
VMBus channel"), napi_disable was getting called for all channels,
|
|
including all subchannels without confirming if they are enabled or not.
|
|
|
|
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
|
|
has finished running but nvdev->subchan_work has not started yet.
|
|
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
|
|
sub-channels and because of that netvsc_sc_open() is not running.
|
|
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
|
|
netvsc_subchan_work did not run.
|
|
|
|
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
|
|
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
|
|
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
|
|
opposite.
|
|
|
|
Now during netvsc_device_remove(), when napi_disable is called for those
|
|
subchannels, napi_disable gets stuck on infinite msleep.
|
|
|
|
This fix addresses this problem by ensuring that napi_disable() is not
|
|
getting called for non-enabled NAPI struct.
|
|
But netif_napi_del() is still necessary for these non-enabled NAPI struct
|
|
for cleanup purpose.
|
|
|
|
Call trace:
|
|
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
|
|
[ 654.568030] Call Trace:
|
|
[ 654.571221] <TASK>
|
|
[ 654.573790] __schedule+0x2d6/0x960
|
|
[ 654.577733] schedule+0x69/0xf0
|
|
[ 654.581214] schedule_timeout+0x87/0x140
|
|
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
|
|
[ 654.590291] msleep+0x2d/0x40
|
|
[ 654.593625] napi_disable+0x2b/0x80
|
|
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
|
|
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
|
|
[ 654.611101] ? do_wait_intr+0xb0/0xb0
|
|
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
|
|
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26698</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
afs: Increase buffer size in afs_update_volume_status()
|
|
|
|
The max length of volume->vid value is 20 characters.
|
|
So increase idbuf[] size up to 24 to avoid overflow.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26736</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
ARM: ep93xx: Add terminator to gpiod_lookup_table
|
|
|
|
Without the terminator, if a con_id is passed to gpio_find() that
|
|
does not exist in the lookup table the function will not stop looping
|
|
correctly, and eventually cause an oops.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26751</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
|
|
|
|
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
|
|
following kernel warning appears:
|
|
|
|
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
|
|
Call trace:
|
|
kiocb_set_cancel_fn+0x9c/0xa8
|
|
ffs_epfile_read_iter+0x144/0x1d0
|
|
io_read+0x19c/0x498
|
|
io_issue_sqe+0x118/0x27c
|
|
io_submit_sqes+0x25c/0x5fc
|
|
__arm64_sys_io_uring_enter+0x104/0xab0
|
|
invoke_syscall+0x58/0x11c
|
|
el0_svc_common+0xb4/0xf4
|
|
do_el0_svc+0x2c/0xb0
|
|
el0_svc+0x2c/0xa4
|
|
el0t_64_sync_handler+0x68/0xb4
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
|
|
submitted by libaio.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26764</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
|
|
|
|
Places the logic for checking if the group's block bitmap is corrupt under
|
|
the protection of the group lock to avoid allocating blocks from the group
|
|
with a corrupted block bitmap.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26772</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
|
|
|
|
Determine if the group block bitmap is corrupted before using ac_b_ex in
|
|
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
|
|
corrupted block bitmap in the following concurrency and making the
|
|
situation worse.
|
|
|
|
ext4_mb_regular_allocator
|
|
ext4_lock_group(sb, group)
|
|
ext4_mb_good_group
|
|
// check if the group bbitmap is corrupted
|
|
ext4_mb_complex_scan_group
|
|
// Scan group gets ac_b_ex but doesn't use it
|
|
ext4_unlock_group(sb, group)
|
|
ext4_mark_group_bitmap_corrupted(group)
|
|
// The block bitmap was corrupted during
|
|
// the group unlock gap.
|
|
ext4_mb_try_best_found
|
|
ext4_lock_group(ac->ac_sb, group)
|
|
ext4_mb_use_best_found
|
|
mb_mark_used
|
|
// Allocating blocks in block bitmap corrupted group</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26773</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
fbdev: sis: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
|
|
drate before it is checked against zero. Fix this by checking it
|
|
at the beginning.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26777</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
fbdev: savage: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
Although pixclock is checked in savagefb_decode_var(), but it is not
|
|
checked properly in savagefb_probe(). Fix this by checking whether
|
|
pixclock is zero in the function savagefb_check_var() before
|
|
info->var.pixclock is used as the divisor.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26778</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
dmaengine: fsl-qdma: init irq after reg initialization
|
|
|
|
Initialize the qDMA irqs after the registers are configured so that
|
|
interrupts that may have been pending from a primary kernel don't get
|
|
processed by the irq handler before it is ready to and cause panic with
|
|
the following trace:
|
|
|
|
Call trace:
|
|
fsl_qdma_queue_handler+0xf8/0x3e8
|
|
__handle_irq_event_percpu+0x78/0x2b0
|
|
handle_irq_event_percpu+0x1c/0x68
|
|
handle_irq_event+0x44/0x78
|
|
handle_fasteoi_irq+0xc8/0x178
|
|
generic_handle_irq+0x24/0x38
|
|
__handle_domain_irq+0x90/0x100
|
|
gic_handle_irq+0x5c/0xb8
|
|
el1_irq+0xb8/0x180
|
|
_raw_spin_unlock_irqrestore+0x14/0x40
|
|
__setup_irq+0x4bc/0x798
|
|
request_threaded_irq+0xd8/0x190
|
|
devm_request_threaded_irq+0x74/0xe8
|
|
fsl_qdma_probe+0x4d4/0xca8
|
|
platform_drv_probe+0x50/0xa0
|
|
really_probe+0xe0/0x3f8
|
|
driver_probe_device+0x64/0x130
|
|
device_driver_attach+0x6c/0x78
|
|
__driver_attach+0xbc/0x158
|
|
bus_for_each_dev+0x5c/0x98
|
|
driver_attach+0x20/0x28
|
|
bus_add_driver+0x158/0x220
|
|
driver_register+0x60/0x110
|
|
__platform_driver_register+0x44/0x50
|
|
fsl_qdma_driver_init+0x18/0x20
|
|
do_one_initcall+0x48/0x258
|
|
kernel_init_freeable+0x1a4/0x23c
|
|
kernel_init+0x10/0xf8
|
|
ret_from_fork+0x10/0x18</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26788</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
vfio/pci: Lock external INTx masking ops
|
|
|
|
Mask operations through config space changes to DisINTx may race INTx
|
|
configuration changes via ioctl. Create wrappers that add locking for
|
|
paths outside of the core interrupt code.
|
|
|
|
In particular, irq_type is updated holding igate, therefore testing
|
|
is_intx() requires holding igate. For example clearing DisINTx from
|
|
config space can otherwise race changes of the interrupt configuration.
|
|
|
|
This aligns interfaces which may trigger the INTx eventfd into two
|
|
camps, one side serialized by igate and the other only enabled while
|
|
INTx is configured. A subsequent patch introduces synchronization for
|
|
the latter flows.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26810</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26883</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26884</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:bpf: Fix DEVMAP_HASH overflow check on 32-bit archesThe devmap code allocates a number hash buckets equal to the next powerof two of the max_entries value provided when creating the map. Whenrounding up to the next power of two, the 32-bit variable storing thenumber of buckets can overflow, and the code checks for overflow bychecking if the truncated 32-bit value is equal to 0. However, on 32-bitarches the rounding up itself can overflow mid-way through, because itends up doing a left-shift of 32 bits on an unsigned long value. If thesize of an unsigned long is four bytes, this is undefined behaviour, sothere is no guarantee that we ll end up with a nice and tidy 0-value atthe end.Syzbot managed to turn this into a crash on arm32 by creating aDEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.Fix this by moving the overflow check to before the rounding upoperation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26885</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</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:
|
|
|
|
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
|
|
|
|
This patch is against CVE-2023-6270. The description of cve is:
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
|
|
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
|
|
`struct net_device`, and a use-after-free can be triggered by racing
|
|
between the free on the struct and the access through the `skbtxq`
|
|
global queue. This could lead to a denial of service condition or
|
|
potential code execution.
|
|
|
|
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
|
|
code is finished. But the net_device ifp will still be used in
|
|
later tx()->dev_queue_xmit() in kthread. Which means that the
|
|
dev_put(ifp) should NOT be called in the success path of skb
|
|
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
|
|
use-after-free because the net_device is freed.
|
|
|
|
This patch removed the dev_put(ifp) in the success path in
|
|
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
|
|
|
|
------------[ cut here ]------------
|
|
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
|
|
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
|
|
[last unloaded: mlx_compat(OE)]
|
|
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
|
|
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
|
|
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
|
|
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
|
|
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x72/0x90
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? __warn+0x8d/0x160
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? report_bug+0x1bb/0x1d0
|
|
? handle_bug+0x46/0x90
|
|
? exc_invalid_op+0x19/0x80
|
|
? asm_exc_invalid_op+0x1b/0x20
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
|
|
ipoib_send+0x2ec/0x770 [ib_ipoib]
|
|
ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
|
|
dev_hard_start_xmit+0x8e/0x1e0
|
|
? validate_xmit_skb_list+0x4d/0x80
|
|
sch_direct_xmit+0x116/0x3a0
|
|
__dev_xmit_skb+0x1fd/0x580
|
|
__dev_queue_xmit+0x284/0x6b0
|
|
? _raw_spin_unlock_irq+0xe/0x50
|
|
? __flush_work.isra.0+0x20d/0x370
|
|
? push_pseudo_header+0x17/0x40 [ib_ipoib]
|
|
neigh_connected_output+0xcd/0x110
|
|
ip_finish_output2+0x179/0x480
|
|
? __smp_call_single_queue+0x61/0xa0
|
|
__ip_finish_output+0xc3/0x190
|
|
ip_finish_output+0x2e/0xf0
|
|
ip_output+0x78/0x110
|
|
? __pfx_ip_finish_output+0x10/0x10
|
|
ip_local_out+0x64/0x70
|
|
__ip_queue_xmit+0x18a/0x460
|
|
ip_queue_xmit+0x15/0x30
|
|
__tcp_transmit_skb+0x914/0x9c0
|
|
tcp_write_xmit+0x334/0x8d0
|
|
tcp_push_one+0x3c/0x60
|
|
tcp_sendmsg_locked+0x2e1/0xac0
|
|
tcp_sendmsg+0x2d/0x50
|
|
inet_sendmsg+0x43/0x90
|
|
sock_sendmsg+0x68/0x80
|
|
sock_write_iter+0x93/0x100
|
|
vfs_write+0x326/0x3c0
|
|
ksys_write+0xbd/0xf0
|
|
? do_syscall_64+0x69/0x90
|
|
__x64_sys_write+0x19/0x30
|
|
do_syscall_
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26907</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Disable auto-enable of exclusive INTx IRQ
|
|
|
|
Currently for devices requiring masking at the irqchip for INTx, ie.
|
|
devices without DisINTx support, the IRQ is enabled in request_irq()
|
|
and subsequently disabled as necessary to align with the masked status
|
|
flag. This presents a window where the interrupt could fire between
|
|
these events, resulting in the IRQ incrementing the disable depth twice.
|
|
This would be unrecoverable for a user since the masked flag prevents
|
|
nested enables through vfio.
|
|
|
|
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
|
|
is never auto-enabled, then unmask as required.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-27437</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1541</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |