1531 lines
69 KiB
XML
1531 lines
69 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-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1536</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-SP1.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<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-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-27437</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<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-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-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-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="perf-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.74.0.154.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.74.0.154" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.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">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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</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-1536</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</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-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</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-1536</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:
|
|
|
|
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-SP1</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-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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: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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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: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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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: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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1536</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |