7689 lines
323 KiB
XML
7689 lines
323 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-1622</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-17</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-17</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-17</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-17</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:
|
|
|
|
firmware: arm_scmi: Harden accesses to the reset domains
|
|
|
|
Accessing reset domains descriptors by the index upon the SCMI drivers
|
|
requests through the SCMI reset operations interface can potentially
|
|
lead to out-of-bound violations if the SCMI driver misbehave.
|
|
|
|
Add an internal consistency check before any such domains descriptors
|
|
accesses.(CVE-2022-48655)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
erofs: fix pcluster use-after-free on UP platforms
|
|
|
|
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
|
|
Read of size 8 at addr ffff8881094223f8 by task stress/7789
|
|
|
|
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
Call Trace:
|
|
<TASK>
|
|
..
|
|
__mutex_lock+0xe5/0xc30
|
|
..
|
|
z_erofs_do_read_page+0x8ce/0x1560
|
|
..
|
|
z_erofs_readahead+0x31c/0x580
|
|
..
|
|
Freed by task 7787
|
|
kasan_save_stack+0x1e/0x40
|
|
kasan_set_track+0x20/0x30
|
|
kasan_set_free_info+0x20/0x40
|
|
__kasan_slab_free+0x10c/0x190
|
|
kmem_cache_free+0xed/0x380
|
|
rcu_core+0x3d5/0xc90
|
|
__do_softirq+0x12d/0x389
|
|
|
|
Last potentially related work creation:
|
|
kasan_save_stack+0x1e/0x40
|
|
__kasan_record_aux_stack+0x97/0xb0
|
|
call_rcu+0x3d/0x3f0
|
|
erofs_shrink_workstation+0x11f/0x210
|
|
erofs_shrink_scan+0xdc/0x170
|
|
shrink_slab.constprop.0+0x296/0x530
|
|
drop_slab+0x1c/0x70
|
|
drop_caches_sysctl_handler+0x70/0x80
|
|
proc_sys_call_handler+0x20a/0x2f0
|
|
vfs_write+0x555/0x6c0
|
|
ksys_write+0xbe/0x160
|
|
do_syscall_64+0x3b/0x90
|
|
|
|
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
|
|
orig_val thus it causes a race that the pcluster reuses unexpectedly
|
|
before freeing.
|
|
|
|
Since UP platforms are quite rare now, such path becomes unnecessary.
|
|
Let's drop such specific-designed path directly instead.(CVE-2022-48674)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: hub: Guard against accesses to uninitialized BOS descriptors
|
|
|
|
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
|
|
access fields inside udev->bos without checking if it was allocated and
|
|
initialized. If usb_get_bos_descriptor() fails for whatever
|
|
reason, udev->bos will be NULL and those accesses will result in a
|
|
crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000018
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
|
|
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
|
|
Workqueue: usb_hub_wq hub_event
|
|
RIP: 0010:hub_port_reset+0x193/0x788
|
|
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
|
|
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
|
|
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
|
|
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
|
|
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
|
|
Call Trace:
|
|
hub_event+0x73f/0x156e
|
|
? hub_activate+0x5b7/0x68f
|
|
process_one_work+0x1a2/0x487
|
|
worker_thread+0x11a/0x288
|
|
kthread+0x13a/0x152
|
|
? process_one_work+0x487/0x487
|
|
? kthread_associate_blkcg+0x70/0x70
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
Fall back to a default behavior if the BOS descriptor isn't accessible
|
|
and skip all the functionalities that depend on it: LPM support checks,
|
|
Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.(CVE-2023-52620)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nftables: exthdr: fix 4-byte stack OOB write
|
|
|
|
If priv->len is a multiple of 4, then dst[len / 4] can write past
|
|
the destination array which leads to stack corruption.
|
|
|
|
This construct is necessary to clean the remainder of the register
|
|
in case ->len is NOT a multiple of the register size, so make it
|
|
conditional just like nft_payload.c does.
|
|
|
|
The bug was added in 4.1 cycle and then copied/inherited when
|
|
tcp/sctp and ip option support was added.
|
|
|
|
Bug reported by Zero Day Initiative project (ZDI-CAN-21950,
|
|
ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Fix an NULL dereference bug
|
|
|
|
The issue here is when this is called from ntfs_load_attr_list(). The
|
|
"size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
|
|
on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
|
|
the result is zero. This means that the kmalloc will succeed by
|
|
returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
|
|
Oops on the next line.(CVE-2023-52631)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
um: time-travel: fix time corruption
|
|
|
|
In 'basic' time-travel mode (without =inf-cpu or =ext), we
|
|
still get timer interrupts. These can happen at arbitrary
|
|
points in time, i.e. while in timer_read(), which pushes
|
|
time forward just a little bit. Then, if we happen to get
|
|
the interrupt after calculating the new time to push to,
|
|
but before actually finishing that, the interrupt will set
|
|
the time to a value that's incompatible with the forward,
|
|
and we'll crash because time goes backwards when we do the
|
|
forwarding.
|
|
|
|
Fix this by reading the time_travel_time, calculating the
|
|
adjustment, and doing the adjustment all with interrupts
|
|
disabled.(CVE-2023-52633)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
|
|
|
|
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
|
|
modifies jsk->filters while receiving packets.
|
|
|
|
Following trace was seen on affected system:
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
Read of size 4 at addr ffff888012144014 by task j1939/350
|
|
|
|
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
print_report+0xd3/0x620
|
|
? kasan_complete_mode_report_info+0x7d/0x200
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
kasan_report+0xc2/0x100
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
__asan_load4+0x84/0xb0
|
|
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
j1939_sk_recv+0x20b/0x320 [can_j1939]
|
|
? __kasan_check_write+0x18/0x20
|
|
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
|
|
? j1939_simple_recv+0x69/0x280 [can_j1939]
|
|
? j1939_ac_recv+0x5e/0x310 [can_j1939]
|
|
j1939_can_recv+0x43f/0x580 [can_j1939]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
? raw_rcv+0x42/0x3c0 [can_raw]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
can_rcv_filter+0x11f/0x350 [can]
|
|
can_receive+0x12f/0x190 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
can_rcv+0xdd/0x130 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
__netif_receive_skb_one_core+0x13d/0x150
|
|
? __pfx___netif_receive_skb_one_core+0x10/0x10
|
|
? __kasan_check_write+0x18/0x20
|
|
? _raw_spin_lock_irq+0x8c/0xe0
|
|
__netif_receive_skb+0x23/0xb0
|
|
process_backlog+0x107/0x260
|
|
__napi_poll+0x69/0x310
|
|
net_rx_action+0x2a1/0x580
|
|
? __pfx_net_rx_action+0x10/0x10
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? handle_irq_event+0x7d/0xa0
|
|
__do_softirq+0xf3/0x3f8
|
|
do_softirq+0x53/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x6e/0x70
|
|
netif_rx+0x16b/0x180
|
|
can_send+0x32b/0x520 [can]
|
|
? __pfx_can_send+0x10/0x10 [can]
|
|
? __check_object_size+0x299/0x410
|
|
raw_sendmsg+0x572/0x6d0 [can_raw]
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
? apparmor_socket_sendmsg+0x2f/0x40
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
sock_sendmsg+0xef/0x100
|
|
sock_write_iter+0x162/0x220
|
|
? __pfx_sock_write_iter+0x10/0x10
|
|
? __rtnl_unlock+0x47/0x80
|
|
? security_file_permission+0x54/0x320
|
|
vfs_write+0x6ba/0x750
|
|
? __pfx_vfs_write+0x10/0x10
|
|
? __fget_light+0x1ca/0x1f0
|
|
? __rcu_read_unlock+0x5b/0x280
|
|
ksys_write+0x143/0x170
|
|
? __pfx_ksys_write+0x10/0x10
|
|
? __kasan_check_read+0x15/0x20
|
|
? fpregs_assert_state_consistent+0x62/0x70
|
|
__x64_sys_write+0x47/0x60
|
|
do_syscall_64+0x60/0x90
|
|
? do_syscall_64+0x6d/0x90
|
|
? irqentry_exit+0x3f/0x50
|
|
? exc_page_fault+0x79/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Allocated by task 348:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x1f/0x30
|
|
__kasan_kmalloc+0xb5/0xc0
|
|
__kmalloc_node_track_caller+0x67/0x160
|
|
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Freed by task 349:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_free_info+0x2f/0x50
|
|
__kasan_slab_free+0x12e/0x1c0
|
|
__kmem_cache_free+0x1b9/0x380
|
|
kfree+0x7a/0x120
|
|
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: s390: vsie: fix race during shadow creation
|
|
|
|
Right now it is possible to see gmap->private being zero in
|
|
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
|
|
fact that we add gmap->private == kvm after creation:
|
|
|
|
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
|
|
struct vsie_page *vsie_page)
|
|
{
|
|
[...]
|
|
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
|
|
if (IS_ERR(gmap))
|
|
return PTR_ERR(gmap);
|
|
gmap->private = vcpu->kvm;
|
|
|
|
Let children inherit the private field of the parent.(CVE-2023-52639)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
|
|
|
|
When QoS is disabled, the queue priority value will not map to the correct
|
|
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
|
|
is disabled to prevent trying to stop/wake a non-existent queue and failing
|
|
to stop/wake the actual queue instantiated.
|
|
|
|
Log of issue before change (with kernel parameter qos=0):
|
|
[ +5.112651] ------------[ cut here ]------------
|
|
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
|
|
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
|
|
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
|
|
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
|
|
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
|
|
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
|
|
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
|
|
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
|
|
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
|
|
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
|
|
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
|
|
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
|
|
[ +0.000001] CS: 0010 DS: 0
|
|
---truncated---(CVE-2023-52644)
|
|
|
|
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.(CVE-2023-6270)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow anonymous set with timeout flag
|
|
|
|
Anonymous sets are never used with timeout from userspace, reject this.
|
|
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing: Ensure visibility when inserting an element into tracing_map
|
|
|
|
Running the following two commands in parallel on a multi-processor
|
|
AArch64 machine can sporadically produce an unexpected warning about
|
|
duplicate histogram entries:
|
|
|
|
$ while true; do
|
|
echo hist:key=id.syscall:val=hitcount > \
|
|
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
|
|
cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
|
|
sleep 0.001
|
|
done
|
|
$ stress-ng --sysbadaddr $(nproc)
|
|
|
|
The warning looks as follows:
|
|
|
|
[ 2911.172474] ------------[ cut here ]------------
|
|
[ 2911.173111] Duplicates detected: 1
|
|
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
|
|
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
|
|
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
|
|
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
|
|
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.185310] sp : ffff8000a1513900
|
|
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
|
|
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
|
|
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
|
|
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
|
|
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
|
|
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
|
|
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
|
|
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
|
|
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
|
|
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
|
|
[ 2911.194259] Call trace:
|
|
[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.195220] hist_show+0x124/0x800
|
|
[ 2911.195692] seq_read_iter+0x1d4/0x4e8
|
|
[ 2911.196193] seq_read+0xe8/0x138
|
|
[ 2911.196638] vfs_read+0xc8/0x300
|
|
[ 2911.197078] ksys_read+0x70/0x108
|
|
[ 2911.197534] __arm64_sys_read+0x24/0x38
|
|
[ 2911.198046] invoke_syscall+0x78/0x108
|
|
[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8
|
|
[ 2911.199157] do_el0_svc+0x28/0x40
|
|
[ 2911.199613] el0_svc+0x40/0x178
|
|
[ 2911.200048] el0t_64_sync_handler+0x13c/0x158
|
|
[ 2911.200621] el0t_64_sync+0x1a8/0x1b0
|
|
[ 2911.201115] ---[ end trace 0000000000000000 ]---
|
|
|
|
The problem appears to be caused by CPU reordering of writes issued from
|
|
__tracing_map_insert().
|
|
|
|
The check for the presence of an element with a given key in this
|
|
function is:
|
|
|
|
val = READ_ONCE(entry->val);
|
|
if (val && keys_match(key, val->key, map->key_size)) ...
|
|
|
|
The write of a new entry is:
|
|
|
|
elt = get_free_elt(map);
|
|
memcpy(elt->key, key, map->key_size);
|
|
entry->val = elt;
|
|
|
|
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
|
|
stores may become visible in the reversed order on another CPU. This
|
|
second CPU might then incorrectly determine that a new key doesn't match
|
|
an already present val->key and subse
|
|
---truncated---(CVE-2024-26645)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tunnels: fix out of bounds access when building IPv6 PMTU error
|
|
|
|
If the ICMPv6 error is built from a non-linear skb we get the following
|
|
splat,
|
|
|
|
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
|
|
Read of size 4 at addr ffff88811d402c80 by task netperf/820
|
|
CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
|
|
...
|
|
kasan_report+0xd8/0x110
|
|
do_csum+0x220/0x240
|
|
csum_partial+0xc/0x20
|
|
skb_tunnel_check_pmtu+0xeb9/0x3280
|
|
vxlan_xmit_one+0x14c2/0x4080
|
|
vxlan_xmit+0xf61/0x5c00
|
|
dev_hard_start_xmit+0xfb/0x510
|
|
__dev_queue_xmit+0x7cd/0x32a0
|
|
br_dev_queue_push_xmit+0x39d/0x6a0
|
|
|
|
Use skb_checksum instead of csum_partial who cannot deal with non-linear
|
|
SKBs.(CVE-2024-26665)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---(CVE-2024-26669)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.(CVE-2024-26671)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: read sk->sk_family once in inet_recv_error()
|
|
|
|
inet_recv_error() is called without holding the socket lock.
|
|
|
|
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
|
|
socket option and trigger a KCSAN warning.(CVE-2024-26679)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
|
|
|
|
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
|
|
XGMAC core") checks and reports safety errors, but leaves the
|
|
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
|
|
a storm of interrupt.
|
|
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential bug in end_buffer_async_write
|
|
|
|
According to a syzbot report, end_buffer_async_write(), which handles the
|
|
completion of block device writes, may detect abnormal condition of the
|
|
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
|
|
|
|
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
|
|
flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
|
|
with race condition of competition between segments for dirty blocks") as
|
|
a means of resolving double list insertion of dirty blocks in
|
|
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
|
|
resulting crash.
|
|
|
|
This modification is safe as long as it is used for file data and b-tree
|
|
node blocks where the page caches are independent. However, it was
|
|
irrelevant and redundant to also introduce async_write for segment summary
|
|
and super root blocks that share buffers with the backing device. This
|
|
led to the possibility that the BUG_ON check in end_buffer_async_write
|
|
would fail as described above, if independent writebacks of the backing
|
|
device occurred in parallel.
|
|
|
|
The use of async_write for segment summary buffers has already been
|
|
removed in a previous change.
|
|
|
|
Fix this issue by removing the manipulation of the async_write flag for
|
|
the remaining super root block buffer.(CVE-2024-26685)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
|
|
|
|
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
|
|
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
|
|
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
|
|
is non valid.
|
|
|
|
E.g: Taking the following steps:
|
|
|
|
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
|
|
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
|
|
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
|
|
|
|
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
|
|
with NULL, losing its previous value, and we will print an error:
|
|
|
|
...
|
|
...
|
|
case Opt_pagesize:
|
|
ps = memparse(param->string, &rest);
|
|
ctx->hstate = h;
|
|
if (!ctx->hstate) {
|
|
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
|
|
return -EINVAL;
|
|
}
|
|
return 0;
|
|
...
|
|
...
|
|
|
|
This is a problem because later on, we will dereference ctxt->hstate in
|
|
hugetlbfs_fill_super()
|
|
|
|
...
|
|
...
|
|
sb->s_blocksize = huge_page_size(ctx->hstate);
|
|
...
|
|
...
|
|
|
|
Causing below Oops.
|
|
|
|
Fix this by replacing cxt->hstate value only when then pagesize is known
|
|
to be valid.
|
|
|
|
kernel: hugetlbfs: Unsupported page size 0 MB
|
|
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
kernel: #PF: supervisor read access in kernel mode
|
|
kernel: #PF: error_code(0x0000) - not-present page
|
|
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
|
|
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
|
|
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
|
|
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
|
|
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
|
|
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
|
|
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
|
|
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
|
|
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
|
|
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
|
|
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
|
|
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
|
|
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
|
|
kernel: Call Trace:
|
|
kernel: <TASK>
|
|
kernel: ? __die_body+0x1a/0x60
|
|
kernel: ? page_fault_oops+0x16f/0x4a0
|
|
kernel: ? search_bpf_extables+0x65/0x70
|
|
kernel: ? fixup_exception+0x22/0x310
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: ? asm_exc_page_fault+0x22/0x30
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: vfs_get_super+0x40/0xa0
|
|
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
|
|
kernel: vfs_get_tree+0x25/0xd0
|
|
kernel: vfs_cmd_create+0x64/0xe0
|
|
kernel: __x64_sys_fsconfig+0x395/0x410
|
|
kernel: do_syscall_64+0x80/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
kernel: RIP: 0033:0x7ffbc0cb87c9
|
|
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
|
|
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
|
|
kernel: RAX: fffffffffff
|
|
---truncated---(CVE-2024-26688)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix data corruption in dsync block recovery for small block sizes
|
|
|
|
The helper function nilfs_recovery_copy_block() of
|
|
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
|
|
data sync writes during a mount after an unclean shutdown, incorrectly
|
|
calculates the on-page offset when copying repair data to the file's page
|
|
cache. In environments where the block size is smaller than the page
|
|
size, this flaw can cause data corruption and leak uninitialized memory
|
|
bytes during the recovery process.
|
|
|
|
Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
parisc: Fix random data corruption from exception handler
|
|
|
|
The current exception handler implementation, which assists when accessing
|
|
user space memory, may exhibit random data corruption if the compiler decides
|
|
to use a different register than the specified register %r29 (defined in
|
|
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
|
|
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
|
|
trash whatever this register is used for.
|
|
Looking at the assembly I found that this happens sometimes in emulate_ldd().
|
|
|
|
To solve the issue, the easiest solution would be if it somehow is
|
|
possible to tell the fault handler which register is used to hold the error
|
|
code. Using %0 or %1 in the inline assembly is not posssible as it will show
|
|
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
|
|
convert to an integer.
|
|
|
|
This patch takes another, better and more flexible approach:
|
|
We extend the __ex_table (which is out of the execution path) by one 32-word.
|
|
In this word we tell the compiler to insert the assembler instruction
|
|
"or %r0,%r0,%reg", where %reg references the register which the compiler
|
|
choosed for the error return code.
|
|
In case of an access failure, the fault handler finds the __ex_table entry and
|
|
can examine the opcode. The used register is encoded in the lowest 5 bits, and
|
|
the fault handler can then store -EFAULT into this register.
|
|
|
|
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
|
|
config option any longer.(CVE-2024-26706)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
|
|
|
|
Syzkaller reported [1] hitting a warning after failing to allocate
|
|
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
|
|
not help much in this case, it might be prudent to switch to
|
|
netdev_warn_once(). At the very least it will suppress syzkaller
|
|
reports such as [1].
|
|
|
|
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
|
|
for similar reasons.
|
|
|
|
[1]
|
|
HSR: Could not send supervision frame
|
|
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
|
|
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
|
|
expire_timers kernel/time/timer.c:1751 [inline]
|
|
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
|
|
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
invoke_softirq kernel/softirq.c:427 [inline]
|
|
__irq_exit_rcu kernel/softirq.c:632 [inline]
|
|
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
|
|
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
|
|
...
|
|
|
|
This issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
|
|
|
|
(struct dirty_throttle_control *)->thresh is an unsigned long, but is
|
|
passed as the u32 divisor argument to div_u64(). On architectures where
|
|
unsigned long is 64 bytes, the argument will be implicitly truncated.
|
|
|
|
Use div64_u64() instead of div_u64() so that the value used in the "is
|
|
this a safe division" check is the same as the divisor.
|
|
|
|
Also, remove redundant cast of the numerator to u64, as that should happen
|
|
implicitly.
|
|
|
|
This would be difficult to exploit in memcg domain, given the ratio-based
|
|
arithmetic domain_drity_limits() uses, but is much easier in global
|
|
writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
|
|
vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't drop extent_map for free space inode on write error
|
|
|
|
While running the CI for an unrelated change I hit the following panic
|
|
with generic/648 on btrfs_holes_spacecache.
|
|
|
|
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/extent_io.c:1385!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
|
|
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
|
|
Call Trace:
|
|
<TASK>
|
|
extent_write_cache_pages+0x2ac/0x8f0
|
|
extent_writepages+0x87/0x110
|
|
do_writepages+0xd5/0x1f0
|
|
filemap_fdatawrite_wbc+0x63/0x90
|
|
__filemap_fdatawrite_range+0x5c/0x80
|
|
btrfs_fdatawrite_range+0x1f/0x50
|
|
btrfs_write_out_cache+0x507/0x560
|
|
btrfs_write_dirty_block_groups+0x32a/0x420
|
|
commit_cowonly_roots+0x21b/0x290
|
|
btrfs_commit_transaction+0x813/0x1360
|
|
btrfs_sync_file+0x51a/0x640
|
|
__x64_sys_fdatasync+0x52/0x90
|
|
do_syscall_64+0x9c/0x190
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
This happens because we fail to write out the free space cache in one
|
|
instance, come back around and attempt to write it again. However on
|
|
the second pass through we go to call btrfs_get_extent() on the inode to
|
|
get the extent mapping. Because this is a new block group, and with the
|
|
free space inode we always search the commit root to avoid deadlocking
|
|
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
|
|
requested range.
|
|
|
|
This happens because the first time we try to write the space cache out
|
|
we hit an error, and on an error we drop the extent mapping. This is
|
|
normal for normal files, but the free space cache inode is special. We
|
|
always expect the extent map to be correct. Thus the second time
|
|
through we end up with a bogus extent map.
|
|
|
|
Since we're deprecating this feature, the most straightforward way to
|
|
fix this is to simply skip dropping the extent map range for this failed
|
|
range.
|
|
|
|
I shortened the test by using error injection to stress the area to make
|
|
it easier to reproduce. With this patch in place we no longer panic
|
|
with my error injection test.(CVE-2024-26726)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arp: Prevent overflow in arp_req_get().
|
|
|
|
syzkaller reported an overflown write in arp_req_get(). [0]
|
|
|
|
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
|
|
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
|
|
|
|
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
|
|
the sa_data buffer is just 14 bytes.
|
|
|
|
In the splat below, 2 bytes are overflown to the next int field,
|
|
arp_flags. We initialise the field just after the memcpy(), so it's
|
|
not a problem.
|
|
|
|
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
|
|
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
|
|
in arp_ioctl() before calling arp_req_get().
|
|
|
|
To avoid the overflow, let's limit the max length of memcpy().
|
|
|
|
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
|
|
array in struct sockaddr") just silenced syzkaller.
|
|
|
|
[0]:
|
|
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
|
|
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Modules linked in:
|
|
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
|
|
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
|
|
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
|
|
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
|
|
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
|
|
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
|
|
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
|
|
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
|
|
sock_ioctl+0x3ef/0x650 net/socket.c:1321
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:870 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:856 [inline]
|
|
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
|
|
entry_SYSCALL_64_after_hwframe+0x64/0xce
|
|
RIP: 0033:0x7f172b262b8d
|
|
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
|
|
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
|
|
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
|
|
</TASK>(CVE-2024-26733)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
devlink: fix possible use-after-free and memory leaks in devlink_init()
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.
|
|
|
|
Make an unregister in case of unsuccessful registration.(CVE-2024-26734)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix possible use-after-free and null-ptr-deref
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.(CVE-2024-26735)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: don't override retval if we already lost the skb
|
|
|
|
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
|
|
yet, we need to tell the core to drop the skb by setting the retcode
|
|
to SHOT. If we have called tcf_mirred_forward(), however, the skb
|
|
is out of our hands and returning SHOT will lead to UaF.
|
|
|
|
Move the retval override to the error path which actually need it.(CVE-2024-26739)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: use the backlog for mirred ingress
|
|
|
|
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
|
|
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
|
|
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
|
|
lockdep.
|
|
|
|
The problem as previously described by Davide (see Link) is that
|
|
if we reverse flow of traffic with the redirect (egress -> ingress)
|
|
we may reach the same socket which generated the packet. And we may
|
|
still be holding its socket lock. The common solution to such deadlocks
|
|
is to put the packet in the Rx backlog, rather than run the Rx path
|
|
inline. Do that for all egress -> ingress reversals, not just once
|
|
we started to nest mirred calls.
|
|
|
|
In the past there was a concern that the backlog indirection will
|
|
lead to loss of error reporting / less accurate stats. But the current
|
|
workaround does not seem to address the issue.(CVE-2024-26740)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/qedr: Fix qedr_create_user_qp error flow
|
|
|
|
Avoid the following warning by making sure to free the allocated
|
|
resources in case that qedr_init_user_queue() fail.
|
|
|
|
-----------[ cut here ]-----------
|
|
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
|
|
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
|
|
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
|
|
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
|
|
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
|
|
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
|
|
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
|
|
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
|
|
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
|
|
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
|
|
Call Trace:
|
|
<TASK>
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? __warn+0x81/0x110
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? report_bug+0x10a/0x140
|
|
? handle_bug+0x3c/0x70
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
__fput+0x94/0x250
|
|
task_work_run+0x5c/0x90
|
|
do_exit+0x270/0x4a0
|
|
do_group_exit+0x2d/0x90
|
|
get_signal+0x87c/0x8c0
|
|
arch_do_signal_or_restart+0x25/0x100
|
|
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
|
|
exit_to_user_mode_loop+0x9c/0x130
|
|
exit_to_user_mode_prepare+0xb6/0x100
|
|
syscall_exit_to_user_mode+0x12/0x40
|
|
do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? common_interrupt+0x43/0xa0
|
|
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
|
RIP: 0033:0x1470abe3ec6b
|
|
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
|
|
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
|
|
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
|
|
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
|
|
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
|
|
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
|
|
</TASK>
|
|
--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Support specifying the srpt_service_guid parameter
|
|
|
|
Make loading ib_srpt with this parameter set work. The current behavior is
|
|
that setting that parameter while loading the ib_srpt kernel module
|
|
triggers the following kernel crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
Call Trace:
|
|
<TASK>
|
|
parse_one+0x18c/0x1d0
|
|
parse_args+0xe1/0x230
|
|
load_module+0x8de/0xa60
|
|
init_module_from_file+0x8b/0xd0
|
|
idempotent_init_module+0x181/0x240
|
|
__x64_sys_finit_module+0x5a/0xb0
|
|
do_syscall_64+0x5f/0xe0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
|
|
|
|
The gtp_net_ops pernet operations structure for the subsystem must be
|
|
registered before registering the generic netlink family.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
general protection fault, probably for non-canonical address
|
|
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
|
|
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
|
|
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
|
|
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
|
|
RSP: 0018:ffff888014107220 EFLAGS: 00010202
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
|
|
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
|
|
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x90/0xa0
|
|
? die_addr+0x50/0xd0
|
|
? exc_general_protection+0x148/0x220
|
|
? asm_exc_general_protection+0x22/0x30
|
|
? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
? __alloc_skb+0x1dd/0x350
|
|
? __pfx___alloc_skb+0x10/0x10
|
|
genl_dumpit+0x11d/0x230
|
|
netlink_dump+0x5b9/0xce0
|
|
? lockdep_hardirqs_on_prepare+0x253/0x430
|
|
? __pfx_netlink_dump+0x10/0x10
|
|
? kasan_save_track+0x10/0x40
|
|
? __kasan_kmalloc+0x9b/0xa0
|
|
? genl_start+0x675/0x970
|
|
__netlink_dump_start+0x6fc/0x9f0
|
|
genl_family_rcv_msg_dumpit+0x1bb/0x2d0
|
|
? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
|
|
? genl_op_from_small+0x2a/0x440
|
|
? cap_capable+0x1d0/0x240
|
|
? __pfx_genl_start+0x10/0x10
|
|
? __pfx_genl_dumpit+0x10/0x10
|
|
? __pfx_genl_done+0x10/0x10
|
|
? security_capable+0x9d/0xe0(CVE-2024-26754)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm-crypt: don't modify the data when using authenticated encryption
|
|
|
|
It was said that authenticated encryption could produce invalid tag when
|
|
the data that is being encrypted is modified [1]. So, fix this problem by
|
|
copying the data into the clone bio first and then encrypt them inside the
|
|
clone bio.
|
|
|
|
This may reduce performance, but it is needed to prevent the user from
|
|
corrupting the device by writing data with O_DIRECT and modifying them at
|
|
the same time.
|
|
|
|
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
|
|
|
|
Return IRQ_NONE from the interrupt handler when no interrupt was
|
|
detected. Because an empty interrupt will cause a null pointer error:
|
|
|
|
Unable to handle kernel NULL pointer dereference at virtual
|
|
address 0000000000000008
|
|
Call trace:
|
|
complete+0x54/0x100
|
|
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
|
|
__handle_irq_event_percpu+0x64/0x1e0
|
|
handle_irq_event+0x7c/0x1cc(CVE-2024-26776)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: fix double-free on socket dismantle
|
|
|
|
when MPTCP server accepts an incoming connection, it clones its listener
|
|
socket. However, the pointer to 'inet_opt' for the new socket has the same
|
|
value as the original one: as a consequence, on program exit it's possible
|
|
to observe the following splat:
|
|
|
|
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
|
|
Free of addr ffff888485950880 by task swapper/25/0
|
|
|
|
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
|
|
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl+0x32/0x50
|
|
print_report+0xca/0x620
|
|
kasan_report_invalid_free+0x64/0x90
|
|
__kasan_slab_free+0x1aa/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
rcu_do_batch+0x34e/0xd90
|
|
rcu_core+0x559/0xac0
|
|
__do_softirq+0x183/0x5a4
|
|
irq_exit_rcu+0x12d/0x170
|
|
sysvec_apic_timer_interrupt+0x6b/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x16/0x20
|
|
RIP: 0010:cpuidle_enter_state+0x175/0x300
|
|
Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b
|
|
RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
|
|
RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
|
|
RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
|
|
RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
|
|
R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
|
|
R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
|
|
cpuidle_enter+0x4a/0xa0
|
|
do_idle+0x310/0x410
|
|
cpu_startup_entry+0x51/0x60
|
|
start_secondary+0x211/0x270
|
|
secondary_startup_64_no_verify+0x184/0x18b
|
|
</TASK>
|
|
|
|
Allocated by task 6853:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
__kasan_kmalloc+0xa6/0xb0
|
|
__kmalloc+0x1eb/0x450
|
|
cipso_v4_sock_setattr+0x96/0x360
|
|
netlbl_sock_setattr+0x132/0x1f0
|
|
selinux_netlbl_socket_post_create+0x6c/0x110
|
|
selinux_socket_post_create+0x37b/0x7f0
|
|
security_socket_post_create+0x63/0xb0
|
|
__sock_create+0x305/0x450
|
|
__sys_socket_create.part.23+0xbd/0x130
|
|
__sys_socket+0x37/0xb0
|
|
__x64_sys_socket+0x6f/0xb0
|
|
do_syscall_64+0x83/0x160
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Freed by task 6858:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
__kasan_slab_free+0x12c/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
subflow_ulp_release+0x1f0/0x250
|
|
tcp_cleanup_ulp+0x6e/0x110
|
|
tcp_v4_destroy_sock+0x5a/0x3a0
|
|
inet_csk_destroy_sock+0x135/0x390
|
|
tcp_fin+0x416/0x5c0
|
|
tcp_data_queue+0x1bc8/0x4310
|
|
tcp_rcv_state_process+0x15a3/0x47b0
|
|
tcp_v4_do_rcv+0x2c1/0x990
|
|
tcp_v4_rcv+0x41fb/0x5ed0
|
|
ip_protocol_deliver_rcu+0x6d/0x9f0
|
|
ip_local_deliver_finish+0x278/0x360
|
|
ip_local_deliver+0x182/0x2c0
|
|
ip_rcv+0xb5/0x1c0
|
|
__netif_receive_skb_one_core+0x16e/0x1b0
|
|
process_backlog+0x1e3/0x650
|
|
__napi_poll+0xa6/0x500
|
|
net_rx_action+0x740/0xbb0
|
|
__do_softirq+0x183/0x5a4
|
|
|
|
The buggy address belongs to the object at ffff888485950880
|
|
which belongs to the cache kmalloc-64 of size 64
|
|
The buggy address is located 0 bytes inside of
|
|
64-byte region [ffff888485950880, ffff8884859508c0)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
|
|
flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
|
|
page_type: 0xffffffff()
|
|
raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
|
|
raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffff888485950780: fa fb fb
|
|
---truncated---(CVE-2024-26782)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: mmci: stm32: fix DMA API overlapping mappings warning
|
|
|
|
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
|
|
|
|
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
|
|
overlapping mappings aren't supported
|
|
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
|
|
add_dma_entry+0x234/0x2f4
|
|
Modules linked in:
|
|
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
|
|
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
|
|
Workqueue: events_freezable mmc_rescan
|
|
Call trace:
|
|
add_dma_entry+0x234/0x2f4
|
|
debug_dma_map_sg+0x198/0x350
|
|
__dma_map_sg_attrs+0xa0/0x110
|
|
dma_map_sg_attrs+0x10/0x2c
|
|
sdmmc_idma_prep_data+0x80/0xc0
|
|
mmci_prep_data+0x38/0x84
|
|
mmci_start_data+0x108/0x2dc
|
|
mmci_request+0xe4/0x190
|
|
__mmc_start_request+0x68/0x140
|
|
mmc_start_request+0x94/0xc0
|
|
mmc_wait_for_req+0x70/0x100
|
|
mmc_send_tuning+0x108/0x1ac
|
|
sdmmc_execute_tuning+0x14c/0x210
|
|
mmc_execute_tuning+0x48/0xec
|
|
mmc_sd_init_uhs_card.part.0+0x208/0x464
|
|
mmc_sd_init_card+0x318/0x89c
|
|
mmc_attach_sd+0xe4/0x180
|
|
mmc_rescan+0x244/0x320
|
|
|
|
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
|
|
dma_unmap_sg are not correctly balanced.
|
|
|
|
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
|
|
function is called and as this API is not managed on stm32 variant,
|
|
dma_unmap_sg is never called in this error path.(CVE-2024-26787)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).(CVE-2024-26791)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix double free of anonymous device after snapshot creation failure
|
|
|
|
When creating a snapshot we may do a double free of an anonymous device
|
|
in case there's an error committing the transaction. The second free may
|
|
result in freeing an anonymous device number that was allocated by some
|
|
other subsystem in the kernel or another btrfs filesystem.
|
|
|
|
The steps that lead to this:
|
|
|
|
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
|
|
and assign it to pending_snapshot->anon_dev;
|
|
|
|
2) Then we call btrfs_commit_transaction() and end up at
|
|
transaction.c:create_pending_snapshot();
|
|
|
|
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
|
|
number stored in pending_snapshot->anon_dev;
|
|
|
|
4) btrfs_get_new_fs_root() frees that anonymous device number because
|
|
btrfs_lookup_fs_root() returned a root - someone else did a lookup
|
|
of the new root already, which could some task doing backref walking;
|
|
|
|
5) After that some error happens in the transaction commit path, and at
|
|
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
|
|
that we free again the same anonymous device number, which in the
|
|
meanwhile may have been reallocated somewhere else, because
|
|
pending_snapshot->anon_dev still has the same value as in step 1.
|
|
|
|
Recently syzbot ran into this and reported the following trace:
|
|
|
|
------------[ cut here ]------------
|
|
ida_free called for id=51 which is not allocated.
|
|
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
|
|
Modules linked in:
|
|
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
|
|
Code: 10 42 80 3c 28 (...)
|
|
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
|
|
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
|
|
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
|
|
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
|
|
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
|
|
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
|
|
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346
|
|
create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837
|
|
create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931
|
|
btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404
|
|
create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848
|
|
btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998
|
|
btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044
|
|
__btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306
|
|
btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393
|
|
btrfs_ioctl+0xa74/0xd40
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:871 [inline]
|
|
__se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7fca3e67dda9
|
|
Code: 28 00 00 00 (...)
|
|
RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9
|
|
RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658
|
|
</TASK>
|
|
|
|
Where we get an explicit message where we attempt to free an anonymous
|
|
device number that is not currently allocated. It happens in a different
|
|
code path from the example below, at btrfs_get_root_ref(), so this change
|
|
may not fix the case triggered by sy
|
|
---truncated---(CVE-2024-26792)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Avoid potential use-after-free in hci_error_reset
|
|
|
|
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
|
|
BT controller is not responding, the GPIO reset mechanism would
|
|
free the hci_dev and lead to a use-after-free in hci_error_reset.
|
|
|
|
Here's the call trace observed on a ChromeOS device with Intel AX201:
|
|
queue_work_on+0x3e/0x6c
|
|
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
|
|
? init_wait_entry+0x31/0x31
|
|
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
|
|
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
|
|
process_one_work+0x1d8/0x33f
|
|
worker_thread+0x21b/0x373
|
|
kthread+0x13a/0x152
|
|
? pr_cont_work+0x54/0x54
|
|
? kthread_blkcg+0x31/0x31
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This patch holds the reference count on the hci_dev while processing
|
|
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ip_tunnel: prevent perpetual headroom growth
|
|
|
|
syzkaller triggered following kasan splat:
|
|
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
|
|
[..]
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:588
|
|
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
|
|
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
|
|
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
|
|
skb_get_hash include/linux/skbuff.h:1556 [inline]
|
|
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
|
|
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
|
|
__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+0x13d/0x6d0 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
|
|
...
|
|
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
|
|
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
|
|
..
|
|
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
|
|
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
|
|
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
|
|
__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+0x13d/0x6d0 net/core/dev.c:3564
|
|
...
|
|
|
|
The splat occurs because skb->data points past skb->head allocated area.
|
|
This is because neigh layer does:
|
|
__skb_pull(skb, skb_network_offset(skb));
|
|
|
|
... but skb_network_offset() returns a negative offset and __skb_pull()
|
|
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
|
|
|
|
The negative value is returned because skb->head and skb->data distance is
|
|
more than 64k and skb->network_header (u16) has wrapped around.
|
|
|
|
The bug is in the ip_tunnel infrastructure, which can cause
|
|
dev->needed_headroom to increment ad infinitum.
|
|
|
|
The syzkaller reproducer consists of packets getting routed via a gre
|
|
tunnel, and route of gre encapsulated packets pointing at another (ipip)
|
|
tunnel. The ipip encapsulation finds gre0 as next output device.
|
|
|
|
This results in the following pattern:
|
|
|
|
1). First packet is to be sent out via gre0.
|
|
Route lookup found an output device, ipip0.
|
|
|
|
2).
|
|
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
|
|
output device, rt.dev->needed_headroom (ipip0).
|
|
|
|
3).
|
|
ip output / start_xmit moves skb on to ipip0. which runs the same
|
|
code path again (xmit recursion).
|
|
|
|
4).
|
|
Routing step for the post-gre0-encap packet finds gre0 as output device
|
|
to use for ipip0 encapsulated packet.
|
|
|
|
tunl0->needed_headroom is then incremented based on the (already bumped)
|
|
gre0 device headroom.
|
|
|
|
This repeats for every future packet:
|
|
|
|
gre0->needed_headroom gets inflated because previous packets' ipip0 step
|
|
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
|
|
needed_headroom was increased.
|
|
|
|
For each subsequent packet, gre/ipip0->needed_headroom grows until
|
|
post-expand-head reallocations result in a skb->head/data distance of
|
|
more than 64k.
|
|
|
|
Once that happens, skb->network_header (u16) wraps around when
|
|
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
|
|
after the headroom expansion/reallocation.
|
|
|
|
After this skb_network_offset(skb) returns a different (and negative)
|
|
result post headroom expansion.
|
|
|
|
The next trip to neigh layer (or anything else that would __skb_pull the
|
|
network header) makes skb->data point to a memory location outside
|
|
skb->head area.
|
|
|
|
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
|
|
prevent perpetual increase instead of dropping the headroom increment
|
|
completely.(CVE-2024-26804)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
|
|
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
|
|
size is specified as `len` and passed to skb_put_data(). This `len`
|
|
is based on `skb->end` that is not data offset but buffer offset. The
|
|
`skb->end` contains data and tailroom. Since the tailroom is not
|
|
initialized when the new `skb` created, KMSAN detects uninitialized
|
|
memory area when copying the data.
|
|
|
|
This patch resolved this issue by correct the len from `skb->end` to
|
|
`skb->len`, which is the actual data offset.
|
|
|
|
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
copy_to_iter include/linux/uio.h:197 [inline]
|
|
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
|
|
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
|
|
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
|
|
sock_recvmsg_nosec net/socket.c:1044 [inline]
|
|
sock_recvmsg net/socket.c:1066 [inline]
|
|
sock_read_iter+0x467/0x580 net/socket.c:1136
|
|
call_read_iter include/linux/fs.h:2014 [inline]
|
|
new_sync_read fs/read_write.c:389 [inline]
|
|
vfs_read+0x8f6/0xe00 fs/read_write.c:470
|
|
ksys_read+0x20f/0x4c0 fs/read_write.c:613
|
|
__do_sys_read fs/read_write.c:623 [inline]
|
|
__se_sys_read fs/read_write.c:621 [inline]
|
|
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
|
|
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 stored to memory at:
|
|
skb_put_data include/linux/skbuff.h:2622 [inline]
|
|
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
|
|
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
|
|
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
|
|
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
|
|
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
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:
|
|
free_pages_prepare mm/page_alloc.c:1087 [inline]
|
|
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
|
|
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
|
|
release_pages+0x23d3/0x2410 mm/swap.c:1042
|
|
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
|
|
tlb_batch_pages
|
|
---truncated---(CVE-2024-26805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
|
|
|
|
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
|
|
event is reported, otherwise a stale reference to netdevice remains in
|
|
the hook list.(CVE-2024-26808)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_set_pipapo: release elements in clone only from destroy path
|
|
|
|
Clone already always provides a current view of the lookup table, use it
|
|
to destroy the set, otherwise it is possible to destroy elements twice.
|
|
|
|
This fix requires:
|
|
|
|
212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
|
|
|
|
which came after:
|
|
|
|
9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").(CVE-2024-26809)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/fsl-mc: Block calling interrupt handler without trigger
|
|
|
|
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
|
|
initially NULL and may become NULL if the user sets the trigger
|
|
eventfd to -1. The interrupt handler itself is guaranteed that
|
|
trigger is always valid between request_irq() and free_irq(), but
|
|
the loopback testing mechanisms to invoke the handler function
|
|
need to test the trigger. The triggering and setting ioctl paths
|
|
both make use of igate and are therefore mutually exclusive.
|
|
|
|
The vfio-fsl-mc driver does not make use of irqfds, nor does it
|
|
support any sort of masking operations, therefore unlike vfio-pci
|
|
and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.(CVE-2024-26817)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.(CVE-2024-26828)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: ir_toy: fix a memleak in irtoy_tx
|
|
|
|
When irtoy_command fails, buf should be freed since it is allocated by
|
|
irtoy_tx, or there is a memleak.(CVE-2024-26829)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.(CVE-2024-26839)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.(CVE-2024-26840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi: runtime: Fix potential overflow of soft-reserved region size
|
|
|
|
md_size will have been narrowed if we have >= 4GB worth of pages in a
|
|
soft-reserved region.(CVE-2024-26843)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-fc: do not wait in vain when unloading module
|
|
|
|
The module exit path has race between deleting all controllers and
|
|
freeing 'left over IDs'. To prevent double free a synchronization
|
|
between nvme_delete_ctrl and ida_destroy has been added by the initial
|
|
commit.
|
|
|
|
There is some logic around trying to prevent from hanging forever in
|
|
wait_for_completion, though it does not handling all cases. E.g.
|
|
blktests is able to reproduce the situation where the module unload
|
|
hangs forever.
|
|
|
|
If we completely rely on the cleanup code executed from the
|
|
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
|
|
calling ida_destroy unnecessary. We only have to ensure that all
|
|
nvme_delete_ctrl code has been executed before we leave
|
|
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
|
|
workqueue.
|
|
|
|
While at it, remove the unused nvme_fc_wq workqueue too.(CVE-2024-26846)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---(CVE-2024-26852)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
|
|
|
|
The function ice_bridge_setlink() may encounter a NULL pointer dereference
|
|
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
|
|
in nla_for_each_nested(). To address this issue, add a check to ensure that
|
|
br_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/bnx2x: Prevent access to a freed page in page_pool
|
|
|
|
Fix race condition leading to system crash during EEH error handling
|
|
|
|
During EEH error recovery, the bnx2x driver's transmit timeout logic
|
|
could cause a race condition when handling reset tasks. The
|
|
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
|
|
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
|
|
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
|
|
overlap with the EEH driver's attempt to reset the device using
|
|
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
|
|
condition can result in system crashes due to accessing freed memory
|
|
locations in bnx2x_free_rx_sge()
|
|
|
|
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
|
|
800 struct bnx2x_fastpath *fp, u16 index)
|
|
801 {
|
|
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
|
|
803 struct page *page = sw_buf->page;
|
|
....
|
|
where sw_buf was set to NULL after the call to dma_unmap_page()
|
|
by the preceding thread.
|
|
|
|
EEH: Beginning: 'slot_reset'
|
|
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
|
|
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
|
|
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
|
|
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
|
|
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
|
|
BUG: Kernel NULL pointer dereference on read at 0x00000000
|
|
Faulting instruction address: 0xc0080000025065fc
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
.....
|
|
Call Trace:
|
|
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
|
|
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
|
|
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
|
|
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
|
|
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
|
|
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
|
|
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
|
|
|
|
To solve this issue, we need to verify page pool allocations before
|
|
freeing.(CVE-2024-26859)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
packet: annotate data-races around ignore_outgoing
|
|
|
|
ignore_outgoing is read locklessly from dev_queue_xmit_nit()
|
|
and packet_getsockopt()
|
|
|
|
Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
|
|
|
|
syzbot reported:
|
|
|
|
BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
|
|
|
|
write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
|
|
packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
|
|
do_sock_setsockopt net/socket.c:2311 [inline]
|
|
__sys_setsockopt+0x1d8/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
|
|
do_syscall_64+0xd3/0x1d0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
|
|
dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
|
|
xmit_one net/core/dev.c:3527 [inline]
|
|
dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
|
|
__dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
|
|
batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
|
|
batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
|
|
batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
|
|
batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
|
|
process_one_work kernel/workqueue.c:3254 [inline]
|
|
process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
|
|
worker_thread+0x526/0x730 kernel/workqueue.c:3416
|
|
kthread+0x1d1/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
|
|
|
|
value changed: 0x00 -> 0x01
|
|
|
|
Reported by Kernel Concurrency Sanitizer on:
|
|
CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet(CVE-2024-26862)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hsr: Fix uninit-value access in hsr_get_node()
|
|
|
|
KMSAN reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
|
|
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
|
|
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
|
|
__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]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3087 [inline]
|
|
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 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+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
|
|
packet_snd net/packet/af_packet.c:3030 [inline]
|
|
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
=====================================================
|
|
|
|
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
|
|
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
|
|
reads an invalid value as a sequence number. This causes the above issue.
|
|
|
|
This patch fixes the issue by returning NULL if the Ethernet header is not
|
|
followed by an HSR tag.(CVE-2024-26863)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
|
|
|
|
syzkaller reported a warning of netns tracker [0] followed by KASAN
|
|
splat [1] and another ref tracker warning [1].
|
|
|
|
syzkaller could not find a repro, but in the log, the only suspicious
|
|
sequence was as follows:
|
|
|
|
18:26:22 executing program 1:
|
|
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
|
|
...
|
|
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
|
|
|
|
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
|
|
|
|
So, the scenario would be:
|
|
|
|
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
|
|
rds_tcp_listen_init().
|
|
2. syz-executor connect()s to it and creates a reqsk.
|
|
3. syz-executor exit()s immediately.
|
|
4. netns is dismantled. [0]
|
|
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
|
|
6. listener is freed after RCU grace period. [2]
|
|
|
|
Basically, reqsk assumes that the listener guarantees netns safety
|
|
until all reqsk timers are expired by holding the listener's refcount.
|
|
However, this was not the case for kernel sockets.
|
|
|
|
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
|
|
inet_twsk_purge()") fixed this issue only for per-netns ehash.
|
|
|
|
Let's apply the same fix for the global ehash.
|
|
|
|
[0]:
|
|
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
|
|
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
|
|
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
|
|
__sock_create (net/socket.c:1572)
|
|
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
|
|
rds_tcp_init_net (net/rds/tcp.c:577)
|
|
ops_init (net/core/net_namespace.c:137)
|
|
setup_net (net/core/net_namespace.c:340)
|
|
copy_net_ns (net/core/net_namespace.c:497)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
|
|
ksys_unshare (kernel/fork.c:3429)
|
|
__x64_sys_unshare (kernel/fork.c:3496)
|
|
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
...
|
|
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
|
|
|
|
[1]:
|
|
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
|
|
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
|
|
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
|
|
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
|
|
run_timer_softirq (kernel/time/timer.c:2053)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
|
|
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
|
|
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
|
|
</IRQ>
|
|
|
|
Allocated by task 258 on cpu 0 at 83.612050s:
|
|
kasan_save_stack (mm/kasan/common.c:48)
|
|
kasan_save_track (mm/kasan/common.c:68)
|
|
__kasan_slab_alloc (mm/kasan/common.c:343)
|
|
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
|
|
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_name
|
|
---truncated---(CVE-2024-26865)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to truncate meta inode pages forcely
|
|
|
|
Below race case can cause data corruption:
|
|
|
|
Thread A GC thread
|
|
- gc_data_segment
|
|
- ra_data_block
|
|
- locked meta_inode page
|
|
- f2fs_inplace_write_data
|
|
- invalidate_mapping_pages
|
|
: fail to invalidate meta_inode page
|
|
due to lock failure or dirty|writeback
|
|
status
|
|
- f2fs_submit_page_bio
|
|
: write last dirty data to old blkaddr
|
|
- move_data_block
|
|
- load old data from meta_inode page
|
|
- f2fs_submit_page_write
|
|
: write old data to new blkaddr
|
|
|
|
Because invalidate_mapping_pages() will skip invalidating page which
|
|
has unclear status including locked, dirty, writeback and so on, so
|
|
we need to use truncate_inode_pages_range() instead of
|
|
invalidate_mapping_pages() to make sure meta_inode page will be dropped.(CVE-2024-26869)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
|
|
|
|
A call to listxattr() with a buffer size = 0 returns the actual
|
|
size of the buffer needed for a subsequent call. When size > 0,
|
|
nfs4_listxattr() does not return an error because either
|
|
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
|
|
exactly all the bytes then size is 0 when calling
|
|
nfs4_listxattr_nfs4_user() which then triggers the following
|
|
kernel BUG:
|
|
|
|
[ 99.403778] kernel BUG at mm/usercopy.c:102!
|
|
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
|
|
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
|
|
[ 99.415827] Call trace:
|
|
[ 99.415985] usercopy_abort+0x70/0xa0
|
|
[ 99.416227] __check_heap_object+0x134/0x158
|
|
[ 99.416505] check_heap_object+0x150/0x188
|
|
[ 99.416696] __check_object_size.part.0+0x78/0x168
|
|
[ 99.416886] __check_object_size+0x28/0x40
|
|
[ 99.417078] listxattr+0x8c/0x120
|
|
[ 99.417252] path_listxattr+0x78/0xe0
|
|
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
|
|
[ 99.417723] invoke_syscall+0x78/0x100
|
|
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
|
|
[ 99.418186] do_el0_svc+0x24/0x38
|
|
[ 99.418376] el0_svc+0x3c/0x110
|
|
[ 99.418554] el0t_64_sync_handler+0x120/0x130
|
|
[ 99.418788] el0t_64_sync+0x194/0x198
|
|
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
|
|
|
|
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
|
|
thus calling lisxattr() with size = 16 will trigger the bug.
|
|
|
|
Add check on nfs4_listxattr() to return ERANGE error when it is
|
|
called with size > 0 and the return value is greater than size.(CVE-2024-26870)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Do not register event handler until srpt device is fully setup
|
|
|
|
Upon rare occasions, KASAN reports a use-after-free Write
|
|
in srpt_refresh_port().
|
|
|
|
This seems to be because an event handler is registered before the
|
|
srpt device is fully setup and a race condition upon error may leave a
|
|
partially setup event handler in place.
|
|
|
|
Instead, only register the event handler after srpt device initialization
|
|
is complete.(CVE-2024-26872)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.(CVE-2024-26875)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm: call the resume method on internal suspend
|
|
|
|
There is this reported crash when experimenting with the lvm2 testsuite.
|
|
The list corruption is caused by the fact that the postsuspend and resume
|
|
methods were not paired correctly; there were two consecutive calls to the
|
|
origin_postsuspend function. The second call attempts to remove the
|
|
"hash_list" entry from a list, while it was already removed by the first
|
|
call.
|
|
|
|
Fix __dm_internal_resume so that it calls the preresume and resume
|
|
methods of the table's targets.
|
|
|
|
If a preresume method of some target fails, we are in a tricky situation.
|
|
We can't return an error because dm_internal_resume isn't supposed to
|
|
return errors. We can't return success, because then the "resume" and
|
|
"postsuspend" methods would not be paired correctly. So, we set the
|
|
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
|
|
tools, but it won't cause a kernel crash.
|
|
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/list_debug.c:56!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
|
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
|
|
<snip>
|
|
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
|
|
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
|
|
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
|
|
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
|
|
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
|
|
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
|
|
FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
|
|
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x2d/0x80
|
|
? do_trap+0xeb/0xf0
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? do_error_trap+0x60/0x80
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? exc_invalid_op+0x49/0x60
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
origin_postsuspend+0x1a/0x50 [dm_snapshot]
|
|
dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
|
|
dm_suspend+0xd8/0xf0 [dm_mod]
|
|
dev_suspend+0x1f2/0x2f0 [dm_mod]
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
ctl_ioctl+0x300/0x5f0 [dm_mod]
|
|
dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
|
|
__x64_compat_sys_ioctl+0x104/0x170
|
|
do_syscall_64+0x184/0x1b0
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0xf7e6aead
|
|
<snip>
|
|
---[ end trace 0000000000000000 ]---(CVE-2024-26880)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firmware: arm_scmi: Fix double free in SMC transport cleanup path
|
|
|
|
When the generic SCMI code tears down a channel, it calls the chan_free
|
|
callback function, defined by each transport. Since multiple protocols
|
|
might share the same transport_info member, chan_free() might want to
|
|
clean up the same member multiple times within the given SCMI transport
|
|
implementation. In this case, it is SMC transport. This will lead to a NULL
|
|
pointer dereference at the second time:
|
|
|
|
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
|
|
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
|
|
| arm-scmi firmware:scmi: unable to communicate with SCMI
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| Mem abort info:
|
|
| ESR = 0x0000000096000004
|
|
| EC = 0x25: DABT (current EL), IL = 32 bits
|
|
| SET = 0, FnV = 0
|
|
| EA = 0, S1PTW = 0
|
|
| FSC = 0x04: level 0 translation fault
|
|
| Data abort info:
|
|
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|
|
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|
|
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
|
|
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
|
|
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
|
|
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
|
|
| Modules linked in:
|
|
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
|
|
| Hardware name: FVP Base RevC (DT)
|
|
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
| pc : smc_chan_free+0x3c/0x6c
|
|
| lr : smc_chan_free+0x3c/0x6c
|
|
| Call trace:
|
|
| smc_chan_free+0x3c/0x6c
|
|
| idr_for_each+0x68/0xf8
|
|
| scmi_cleanup_channels.isra.0+0x2c/0x58
|
|
| scmi_probe+0x434/0x734
|
|
| platform_probe+0x68/0xd8
|
|
| really_probe+0x110/0x27c
|
|
| __driver_probe_device+0x78/0x12c
|
|
| driver_probe_device+0x3c/0x118
|
|
| __driver_attach+0x74/0x128
|
|
| bus_for_each_dev+0x78/0xe0
|
|
| driver_attach+0x24/0x30
|
|
| bus_add_driver+0xe4/0x1e8
|
|
| driver_register+0x60/0x128
|
|
| __platform_driver_register+0x28/0x34
|
|
| scmi_driver_init+0x84/0xc0
|
|
| do_one_initcall+0x78/0x33c
|
|
| kernel_init_freeable+0x2b8/0x51c
|
|
| kernel_init+0x24/0x130
|
|
| ret_from_fork+0x10/0x20
|
|
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
|
|
| ---[ end trace 0000000000000000 ]---
|
|
|
|
Simply check for the struct pointer being NULL before trying to access
|
|
its members, to avoid this situation.
|
|
|
|
This was found when a transport doesn't really work (for instance no SMC
|
|
service), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
|
|
|
|
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
|
|
observed on interface registration error path, or simply by
|
|
removing the module/unbinding device from driver:
|
|
|
|
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
|
|
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
|
|
Read of size 4 at addr c54d1ce8 by task sh/86
|
|
|
|
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
|
|
Hardware name: Atmel SAMA5
|
|
unwind_backtrace from show_stack+0x18/0x1c
|
|
show_stack from dump_stack_lvl+0x34/0x58
|
|
dump_stack_lvl from print_report+0x154/0x500
|
|
print_report from kasan_report+0xac/0xd8
|
|
kasan_report from wilc_netdev_cleanup+0x508/0x5cc
|
|
wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
|
|
wilc_bus_remove from spi_remove+0x8c/0xac
|
|
spi_remove from device_release_driver_internal+0x434/0x5f8
|
|
device_release_driver_internal from unbind_store+0xbc/0x108
|
|
unbind_store from kernfs_fop_write_iter+0x398/0x584
|
|
kernfs_fop_write_iter from vfs_write+0x728/0xf88
|
|
vfs_write from ksys_write+0x110/0x1e4
|
|
ksys_write from ret_fast_syscall+0x0/0x1c
|
|
|
|
[...]
|
|
|
|
Allocated by task 1:
|
|
kasan_save_track+0x30/0x5c
|
|
__kasan_kmalloc+0x8c/0x94
|
|
__kmalloc_node+0x1cc/0x3e4
|
|
kvmalloc_node+0x48/0x180
|
|
alloc_netdev_mqs+0x68/0x11dc
|
|
alloc_etherdev_mqs+0x28/0x34
|
|
wilc_netdev_ifc_init+0x34/0x8ec
|
|
wilc_cfg80211_init+0x690/0x910
|
|
wilc_bus_probe+0xe0/0x4a0
|
|
spi_probe+0x158/0x1b0
|
|
really_probe+0x270/0xdf4
|
|
__driver_probe_device+0x1dc/0x580
|
|
driver_probe_device+0x60/0x140
|
|
__driver_attach+0x228/0x5d4
|
|
bus_for_each_dev+0x13c/0x1a8
|
|
bus_add_driver+0x2a0/0x608
|
|
driver_register+0x24c/0x578
|
|
do_one_initcall+0x180/0x310
|
|
kernel_init_freeable+0x424/0x484
|
|
kernel_init+0x20/0x148
|
|
ret_from_fork+0x14/0x28
|
|
|
|
Freed by task 86:
|
|
kasan_save_track+0x30/0x5c
|
|
kasan_save_free_info+0x38/0x58
|
|
__kasan_slab_free+0xe4/0x140
|
|
kfree+0xb0/0x238
|
|
device_release+0xc0/0x2a8
|
|
kobject_put+0x1d4/0x46c
|
|
netdev_run_todo+0x8fc/0x11d0
|
|
wilc_netdev_cleanup+0x1e4/0x5cc
|
|
wilc_bus_remove+0xc8/0xec
|
|
spi_remove+0x8c/0xac
|
|
device_release_driver_internal+0x434/0x5f8
|
|
unbind_store+0xbc/0x108
|
|
kernfs_fop_write_iter+0x398/0x584
|
|
vfs_write+0x728/0xf88
|
|
ksys_write+0x110/0x1e4
|
|
ret_fast_syscall+0x0/0x1c
|
|
[...]
|
|
|
|
David Mosberger-Tan initial investigation [1] showed that this
|
|
use-after-free is due to netdevice unregistration during vif list
|
|
traversal. When unregistering a net device, since the needs_free_netdev has
|
|
been set to true during registration, the netdevice object is also freed,
|
|
and as a consequence, the corresponding vif object too, since it is
|
|
attached to it as private netdevice data. The next occurrence of the loop
|
|
then tries to access freed vif pointer to the list to move forward in the
|
|
list.
|
|
|
|
Fix this use-after-free thanks to two mechanisms:
|
|
- navigate in the list with list_for_each_entry_safe, which allows to
|
|
safely modify the list as we go through each element. For each element,
|
|
remove it from the list with list_del_rcu
|
|
- make sure to wait for RCU grace period end after each vif removal to make
|
|
sure it is safe to free the corresponding vif too (through
|
|
unregister_netdev)
|
|
|
|
Since we are in a RCU "modifier" path (not a "reader" path), and because
|
|
such path is expected not to be concurrent to any other modifier (we are
|
|
using the vif_mutex lock), we do not need to use RCU list API, that's why
|
|
we can benefit from list_for_each_entry_safe.
|
|
|
|
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/(CVE-2024-26895)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: wfx: fix memory leak when starting AP
|
|
|
|
Kmemleak reported this error:
|
|
|
|
unreferenced object 0xd73d1180 (size 184):
|
|
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
|
|
[<127bdd74>] __alloc_skb+0x144/0x170
|
|
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
|
|
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
|
|
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
|
|
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
|
|
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
|
|
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
|
|
[<47bd8b68>] genl_rcv_msg+0x198/0x378
|
|
[<453ef796>] netlink_rcv_skb+0xd0/0x130
|
|
[<6b7c977a>] genl_rcv+0x34/0x44
|
|
[<66b2d04d>] netlink_unicast+0x1b4/0x258
|
|
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
|
|
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
|
|
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
|
|
[<69954f45>] __sys_sendmsg+0x64/0xa8
|
|
unreferenced object 0xce087000 (size 1024):
|
|
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
|
|
backtrace:
|
|
[<9a993714>] __kmalloc_track_caller+0x230/0x600
|
|
[<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
|
|
[<a2c61343>] __alloc_skb+0xa0/0x170
|
|
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
|
|
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
|
|
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
|
|
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
|
|
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
|
|
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
|
|
[<47bd8b68>] genl_rcv_msg+0x198/0x378
|
|
[<453ef796>] netlink_rcv_skb+0xd0/0x130
|
|
[<6b7c977a>] genl_rcv+0x34/0x44
|
|
[<66b2d04d>] netlink_unicast+0x1b4/0x258
|
|
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
|
|
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
|
|
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
|
|
|
|
However, since the kernel is build optimized, it seems the stack is not
|
|
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
|
|
is obvious in this function: memory allocated by ieee80211_beacon_get()
|
|
is never released. Fixing this leak makes kmemleak happy.(CVE-2024-26896)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
|
|
|
|
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
|
|
structures have been fully initialised by the time it runs. However, because of
|
|
the order in which things are initialised, this is not guaranteed to be the
|
|
case, because the device is exposed to the USB subsystem before the ath9k driver
|
|
initialisation is completed.
|
|
|
|
We already committed a partial fix for this in commit:
|
|
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
|
|
|
|
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
|
|
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
|
|
seems syzbot managed to trigger the race for one of the other commands as well,
|
|
so let's just move the existing synchronisation bit to cover the whole
|
|
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
|
|
ath9k_tx_init()).(CVE-2024-26897)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
|
|
|
|
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
|
|
|
|
This commit causes interrupts to be lost for FCoE devices, since it changed
|
|
sping locks from "bh" to "irqsave".
|
|
|
|
Instead, a work queue should be used, and will be addressed in a separate
|
|
commit.(CVE-2024-26917)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: validate the parameters of bo mapping operations more clearly
|
|
|
|
Verify the parameters of
|
|
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.(CVE-2024-26922)</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-1622</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48655</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48674</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52477</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52620</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52628</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52631</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52633</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52637</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52639</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52642</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52644</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-6270</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26642</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26645</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26665</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26668</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26669</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26671</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26679</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26680</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26684</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26685</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26688</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26689</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26697</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26706</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26707</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26720</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26726</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26733</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26734</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26735</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26739</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26740</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26743</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26744</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26754</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26763</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26776</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26782</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26787</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26791</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26792</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26801</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26804</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26808</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26809</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26811</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26812</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26814</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26817</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26828</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26829</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26839</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26843</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26846</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26852</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26855</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26859</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26862</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26863</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26865</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26869</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26870</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26872</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26875</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26878</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26880</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26893</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26895</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26896</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26897</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26917</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26921</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26922</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48655</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48674</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52477</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52620</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52628</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52631</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52637</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52639</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52642</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52644</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-6270</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26642</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26645</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26665</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26668</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26669</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26671</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26679</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26680</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26684</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26688</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26689</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26697</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26706</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26707</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26720</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26726</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26733</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26734</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26735</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26739</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26740</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26743</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26744</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26754</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26763</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26776</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26782</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26787</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26792</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26801</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26804</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26808</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26809</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26811</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26812</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26814</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26828</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26829</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26839</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26843</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26846</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26852</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26855</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26859</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26862</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26863</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26865</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26869</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26870</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26872</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26875</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26878</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26880</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26893</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26895</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26896</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26897</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26917</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26921</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26922</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-devel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-199.0.0.112.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-199.0.0.112" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-199.0.0.112.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:firmware: arm_scmi: Harden accesses to the reset domainsAccessing reset domains descriptors by the index upon the SCMI driversrequests through the SCMI reset operations interface can potentiallylead to out-of-bound violations if the SCMI driver misbehave.Add an internal consistency check before any such domains descriptorsaccesses.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2022-48655</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
erofs: fix pcluster use-after-free on UP platforms
|
|
|
|
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
|
|
Read of size 8 at addr ffff8881094223f8 by task stress/7789
|
|
|
|
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
Call Trace:
|
|
<TASK>
|
|
..
|
|
__mutex_lock+0xe5/0xc30
|
|
..
|
|
z_erofs_do_read_page+0x8ce/0x1560
|
|
..
|
|
z_erofs_readahead+0x31c/0x580
|
|
..
|
|
Freed by task 7787
|
|
kasan_save_stack+0x1e/0x40
|
|
kasan_set_track+0x20/0x30
|
|
kasan_set_free_info+0x20/0x40
|
|
__kasan_slab_free+0x10c/0x190
|
|
kmem_cache_free+0xed/0x380
|
|
rcu_core+0x3d5/0xc90
|
|
__do_softirq+0x12d/0x389
|
|
|
|
Last potentially related work creation:
|
|
kasan_save_stack+0x1e/0x40
|
|
__kasan_record_aux_stack+0x97/0xb0
|
|
call_rcu+0x3d/0x3f0
|
|
erofs_shrink_workstation+0x11f/0x210
|
|
erofs_shrink_scan+0xdc/0x170
|
|
shrink_slab.constprop.0+0x296/0x530
|
|
drop_slab+0x1c/0x70
|
|
drop_caches_sysctl_handler+0x70/0x80
|
|
proc_sys_call_handler+0x20a/0x2f0
|
|
vfs_write+0x555/0x6c0
|
|
ksys_write+0xbe/0x160
|
|
do_syscall_64+0x3b/0x90
|
|
|
|
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
|
|
orig_val thus it causes a race that the pcluster reuses unexpectedly
|
|
before freeing.
|
|
|
|
Since UP platforms are quite rare now, such path becomes unnecessary.
|
|
Let's drop such specific-designed path directly instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2022-48674</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
usb: hub: Guard against accesses to uninitialized BOS descriptors
|
|
|
|
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
|
|
access fields inside udev->bos without checking if it was allocated and
|
|
initialized. If usb_get_bos_descriptor() fails for whatever
|
|
reason, udev->bos will be NULL and those accesses will result in a
|
|
crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000018
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
|
|
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
|
|
Workqueue: usb_hub_wq hub_event
|
|
RIP: 0010:hub_port_reset+0x193/0x788
|
|
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
|
|
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
|
|
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
|
|
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
|
|
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
|
|
Call Trace:
|
|
hub_event+0x73f/0x156e
|
|
? hub_activate+0x5b7/0x68f
|
|
process_one_work+0x1a2/0x487
|
|
worker_thread+0x11a/0x288
|
|
kthread+0x13a/0x152
|
|
? process_one_work+0x487/0x487
|
|
? kthread_associate_blkcg+0x70/0x70
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
Fall back to a default behavior if the BOS descriptor isn't accessible
|
|
and skip all the functionalities that depend on it: LPM support checks,
|
|
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52477</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52620</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
netfilter: nftables: exthdr: fix 4-byte stack OOB write
|
|
|
|
If priv->len is a multiple of 4, then dst[len / 4] can write past
|
|
the destination array which leads to stack corruption.
|
|
|
|
This construct is necessary to clean the remainder of the register
|
|
in case ->len is NOT a multiple of the register size, so make it
|
|
conditional just like nft_payload.c does.
|
|
|
|
The bug was added in 4.1 cycle and then copied/inherited when
|
|
tcp/sctp and ip option support was added.
|
|
|
|
Bug reported by Zero Day Initiative project (ZDI-CAN-21950,
|
|
ZDI-CAN-21951, ZDI-CAN-21961).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52628</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
fs/ntfs3: Fix an NULL dereference bug
|
|
|
|
The issue here is when this is called from ntfs_load_attr_list(). The
|
|
"size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
|
|
on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
|
|
the result is zero. This means that the kmalloc will succeed by
|
|
returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
|
|
Oops on the next line.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52631</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
um: time-travel: fix time corruption
|
|
|
|
In 'basic' time-travel mode (without =inf-cpu or =ext), we
|
|
still get timer interrupts. These can happen at arbitrary
|
|
points in time, i.e. while in timer_read(), which pushes
|
|
time forward just a little bit. Then, if we happen to get
|
|
the interrupt after calculating the new time to push to,
|
|
but before actually finishing that, the interrupt will set
|
|
the time to a value that's incompatible with the forward,
|
|
and we'll crash because time goes backwards when we do the
|
|
forwarding.
|
|
|
|
Fix this by reading the time_travel_time, calculating the
|
|
adjustment, and doing the adjustment all with interrupts
|
|
disabled.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52633</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
|
|
|
|
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
|
|
modifies jsk->filters while receiving packets.
|
|
|
|
Following trace was seen on affected system:
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
Read of size 4 at addr ffff888012144014 by task j1939/350
|
|
|
|
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
print_report+0xd3/0x620
|
|
? kasan_complete_mode_report_info+0x7d/0x200
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
kasan_report+0xc2/0x100
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
__asan_load4+0x84/0xb0
|
|
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
j1939_sk_recv+0x20b/0x320 [can_j1939]
|
|
? __kasan_check_write+0x18/0x20
|
|
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
|
|
? j1939_simple_recv+0x69/0x280 [can_j1939]
|
|
? j1939_ac_recv+0x5e/0x310 [can_j1939]
|
|
j1939_can_recv+0x43f/0x580 [can_j1939]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
? raw_rcv+0x42/0x3c0 [can_raw]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
can_rcv_filter+0x11f/0x350 [can]
|
|
can_receive+0x12f/0x190 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
can_rcv+0xdd/0x130 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
__netif_receive_skb_one_core+0x13d/0x150
|
|
? __pfx___netif_receive_skb_one_core+0x10/0x10
|
|
? __kasan_check_write+0x18/0x20
|
|
? _raw_spin_lock_irq+0x8c/0xe0
|
|
__netif_receive_skb+0x23/0xb0
|
|
process_backlog+0x107/0x260
|
|
__napi_poll+0x69/0x310
|
|
net_rx_action+0x2a1/0x580
|
|
? __pfx_net_rx_action+0x10/0x10
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? handle_irq_event+0x7d/0xa0
|
|
__do_softirq+0xf3/0x3f8
|
|
do_softirq+0x53/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x6e/0x70
|
|
netif_rx+0x16b/0x180
|
|
can_send+0x32b/0x520 [can]
|
|
? __pfx_can_send+0x10/0x10 [can]
|
|
? __check_object_size+0x299/0x410
|
|
raw_sendmsg+0x572/0x6d0 [can_raw]
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
? apparmor_socket_sendmsg+0x2f/0x40
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
sock_sendmsg+0xef/0x100
|
|
sock_write_iter+0x162/0x220
|
|
? __pfx_sock_write_iter+0x10/0x10
|
|
? __rtnl_unlock+0x47/0x80
|
|
? security_file_permission+0x54/0x320
|
|
vfs_write+0x6ba/0x750
|
|
? __pfx_vfs_write+0x10/0x10
|
|
? __fget_light+0x1ca/0x1f0
|
|
? __rcu_read_unlock+0x5b/0x280
|
|
ksys_write+0x143/0x170
|
|
? __pfx_ksys_write+0x10/0x10
|
|
? __kasan_check_read+0x15/0x20
|
|
? fpregs_assert_state_consistent+0x62/0x70
|
|
__x64_sys_write+0x47/0x60
|
|
do_syscall_64+0x60/0x90
|
|
? do_syscall_64+0x6d/0x90
|
|
? irqentry_exit+0x3f/0x50
|
|
? exc_page_fault+0x79/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Allocated by task 348:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x1f/0x30
|
|
__kasan_kmalloc+0xb5/0xc0
|
|
__kmalloc_node_track_caller+0x67/0x160
|
|
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Freed by task 349:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_free_info+0x2f/0x50
|
|
__kasan_slab_free+0x12e/0x1c0
|
|
__kmem_cache_free+0x1b9/0x380
|
|
kfree+0x7a/0x120
|
|
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52637</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
KVM: s390: vsie: fix race during shadow creation
|
|
|
|
Right now it is possible to see gmap->private being zero in
|
|
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
|
|
fact that we add gmap->private == kvm after creation:
|
|
|
|
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
|
|
struct vsie_page *vsie_page)
|
|
{
|
|
[...]
|
|
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
|
|
if (IS_ERR(gmap))
|
|
return PTR_ERR(gmap);
|
|
gmap->private = vcpu->kvm;
|
|
|
|
Let children inherit the private field of the parent.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52639</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
media: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52642</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
|
|
|
|
When QoS is disabled, the queue priority value will not map to the correct
|
|
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
|
|
is disabled to prevent trying to stop/wake a non-existent queue and failing
|
|
to stop/wake the actual queue instantiated.
|
|
|
|
Log of issue before change (with kernel parameter qos=0):
|
|
[ +5.112651] ------------[ cut here ]------------
|
|
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
|
|
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
|
|
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
|
|
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
|
|
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
|
|
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
|
|
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
|
|
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
|
|
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
|
|
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
|
|
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
|
|
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
|
|
[ +0.000001] CS: 0010 DS: 0
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52644</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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">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.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-6270</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.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
netfilter: nf_tables: disallow anonymous set with timeout flag
|
|
|
|
Anonymous sets are never used with timeout from userspace, reject this.
|
|
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26642</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
tracing: Ensure visibility when inserting an element into tracing_map
|
|
|
|
Running the following two commands in parallel on a multi-processor
|
|
AArch64 machine can sporadically produce an unexpected warning about
|
|
duplicate histogram entries:
|
|
|
|
$ while true; do
|
|
echo hist:key=id.syscall:val=hitcount > \
|
|
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
|
|
cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
|
|
sleep 0.001
|
|
done
|
|
$ stress-ng --sysbadaddr $(nproc)
|
|
|
|
The warning looks as follows:
|
|
|
|
[ 2911.172474] ------------[ cut here ]------------
|
|
[ 2911.173111] Duplicates detected: 1
|
|
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
|
|
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
|
|
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
|
|
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
|
|
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.185310] sp : ffff8000a1513900
|
|
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
|
|
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
|
|
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
|
|
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
|
|
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
|
|
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
|
|
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
|
|
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
|
|
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
|
|
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
|
|
[ 2911.194259] Call trace:
|
|
[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.195220] hist_show+0x124/0x800
|
|
[ 2911.195692] seq_read_iter+0x1d4/0x4e8
|
|
[ 2911.196193] seq_read+0xe8/0x138
|
|
[ 2911.196638] vfs_read+0xc8/0x300
|
|
[ 2911.197078] ksys_read+0x70/0x108
|
|
[ 2911.197534] __arm64_sys_read+0x24/0x38
|
|
[ 2911.198046] invoke_syscall+0x78/0x108
|
|
[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8
|
|
[ 2911.199157] do_el0_svc+0x28/0x40
|
|
[ 2911.199613] el0_svc+0x40/0x178
|
|
[ 2911.200048] el0t_64_sync_handler+0x13c/0x158
|
|
[ 2911.200621] el0t_64_sync+0x1a8/0x1b0
|
|
[ 2911.201115] ---[ end trace 0000000000000000 ]---
|
|
|
|
The problem appears to be caused by CPU reordering of writes issued from
|
|
__tracing_map_insert().
|
|
|
|
The check for the presence of an element with a given key in this
|
|
function is:
|
|
|
|
val = READ_ONCE(entry->val);
|
|
if (val && keys_match(key, val->key, map->key_size)) ...
|
|
|
|
The write of a new entry is:
|
|
|
|
elt = get_free_elt(map);
|
|
memcpy(elt->key, key, map->key_size);
|
|
entry->val = elt;
|
|
|
|
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
|
|
stores may become visible in the reversed order on another CPU. This
|
|
second CPU might then incorrectly determine that a new key doesn't match
|
|
an already present val->key and subse
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26645</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
tunnels: fix out of bounds access when building IPv6 PMTU error
|
|
|
|
If the ICMPv6 error is built from a non-linear skb we get the following
|
|
splat,
|
|
|
|
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
|
|
Read of size 4 at addr ffff88811d402c80 by task netperf/820
|
|
CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
|
|
...
|
|
kasan_report+0xd8/0x110
|
|
do_csum+0x220/0x240
|
|
csum_partial+0xc/0x20
|
|
skb_tunnel_check_pmtu+0xeb9/0x3280
|
|
vxlan_xmit_one+0x14c2/0x4080
|
|
vxlan_xmit+0xf61/0x5c00
|
|
dev_hard_start_xmit+0xfb/0x510
|
|
__dev_queue_xmit+0x7cd/0x32a0
|
|
br_dev_queue_push_xmit+0x39d/0x6a0
|
|
|
|
Use skb_checksum instead of csum_partial who cannot deal with non-linear
|
|
SKBs.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26665</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26668</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26669</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26671</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
inet: read sk->sk_family once in inet_recv_error()
|
|
|
|
inet_recv_error() is called without holding the socket lock.
|
|
|
|
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
|
|
socket option and trigger a KCSAN warning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26679</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26680</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
|
|
|
|
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
|
|
XGMAC core") checks and reports safety errors, but leaves the
|
|
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
|
|
a storm of interrupt.
|
|
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26684</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
nilfs2: fix potential bug in end_buffer_async_write
|
|
|
|
According to a syzbot report, end_buffer_async_write(), which handles the
|
|
completion of block device writes, may detect abnormal condition of the
|
|
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
|
|
|
|
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
|
|
flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
|
|
with race condition of competition between segments for dirty blocks") as
|
|
a means of resolving double list insertion of dirty blocks in
|
|
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
|
|
resulting crash.
|
|
|
|
This modification is safe as long as it is used for file data and b-tree
|
|
node blocks where the page caches are independent. However, it was
|
|
irrelevant and redundant to also introduce async_write for segment summary
|
|
and super root blocks that share buffers with the backing device. This
|
|
led to the possibility that the BUG_ON check in end_buffer_async_write
|
|
would fail as described above, if independent writebacks of the backing
|
|
device occurred in parallel.
|
|
|
|
The use of async_write for segment summary buffers has already been
|
|
removed in a previous change.
|
|
|
|
Fix this issue by removing the manipulation of the async_write flag for
|
|
the remaining super root block buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26685</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</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:
|
|
|
|
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
|
|
|
|
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
|
|
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
|
|
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
|
|
is non valid.
|
|
|
|
E.g: Taking the following steps:
|
|
|
|
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
|
|
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
|
|
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
|
|
|
|
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
|
|
with NULL, losing its previous value, and we will print an error:
|
|
|
|
...
|
|
...
|
|
case Opt_pagesize:
|
|
ps = memparse(param->string, &rest);
|
|
ctx->hstate = h;
|
|
if (!ctx->hstate) {
|
|
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
|
|
return -EINVAL;
|
|
}
|
|
return 0;
|
|
...
|
|
...
|
|
|
|
This is a problem because later on, we will dereference ctxt->hstate in
|
|
hugetlbfs_fill_super()
|
|
|
|
...
|
|
...
|
|
sb->s_blocksize = huge_page_size(ctx->hstate);
|
|
...
|
|
...
|
|
|
|
Causing below Oops.
|
|
|
|
Fix this by replacing cxt->hstate value only when then pagesize is known
|
|
to be valid.
|
|
|
|
kernel: hugetlbfs: Unsupported page size 0 MB
|
|
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
kernel: #PF: supervisor read access in kernel mode
|
|
kernel: #PF: error_code(0x0000) - not-present page
|
|
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
|
|
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
|
|
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
|
|
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
|
|
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
|
|
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
|
|
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
|
|
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
|
|
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
|
|
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
|
|
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
|
|
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
|
|
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
|
|
kernel: Call Trace:
|
|
kernel: <TASK>
|
|
kernel: ? __die_body+0x1a/0x60
|
|
kernel: ? page_fault_oops+0x16f/0x4a0
|
|
kernel: ? search_bpf_extables+0x65/0x70
|
|
kernel: ? fixup_exception+0x22/0x310
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: ? asm_exc_page_fault+0x22/0x30
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: vfs_get_super+0x40/0xa0
|
|
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
|
|
kernel: vfs_get_tree+0x25/0xd0
|
|
kernel: vfs_cmd_create+0x64/0xe0
|
|
kernel: __x64_sys_fsconfig+0x395/0x410
|
|
kernel: do_syscall_64+0x80/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
kernel: RIP: 0033:0x7ffbc0cb87c9
|
|
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
|
|
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
|
|
kernel: RAX: fffffffffff
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26688</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26689</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix data corruption in dsync block recovery for small block sizes
|
|
|
|
The helper function nilfs_recovery_copy_block() of
|
|
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
|
|
data sync writes during a mount after an unclean shutdown, incorrectly
|
|
calculates the on-page offset when copying repair data to the file's page
|
|
cache. In environments where the block size is smaller than the page
|
|
size, this flaw can cause data corruption and leak uninitialized memory
|
|
bytes during the recovery process.
|
|
|
|
Fix these issues by correcting this byte offset calculation on the page.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26697</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
parisc: Fix random data corruption from exception handler
|
|
|
|
The current exception handler implementation, which assists when accessing
|
|
user space memory, may exhibit random data corruption if the compiler decides
|
|
to use a different register than the specified register %r29 (defined in
|
|
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
|
|
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
|
|
trash whatever this register is used for.
|
|
Looking at the assembly I found that this happens sometimes in emulate_ldd().
|
|
|
|
To solve the issue, the easiest solution would be if it somehow is
|
|
possible to tell the fault handler which register is used to hold the error
|
|
code. Using %0 or %1 in the inline assembly is not posssible as it will show
|
|
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
|
|
convert to an integer.
|
|
|
|
This patch takes another, better and more flexible approach:
|
|
We extend the __ex_table (which is out of the execution path) by one 32-word.
|
|
In this word we tell the compiler to insert the assembler instruction
|
|
"or %r0,%r0,%reg", where %reg references the register which the compiler
|
|
choosed for the error return code.
|
|
In case of an access failure, the fault handler finds the __ex_table entry and
|
|
can examine the opcode. The used register is encoded in the lowest 5 bits, and
|
|
the fault handler can then store -EFAULT into this register.
|
|
|
|
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
|
|
config option any longer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26706</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
|
|
|
|
Syzkaller reported [1] hitting a warning after failing to allocate
|
|
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
|
|
not help much in this case, it might be prudent to switch to
|
|
netdev_warn_once(). At the very least it will suppress syzkaller
|
|
reports such as [1].
|
|
|
|
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
|
|
for similar reasons.
|
|
|
|
[1]
|
|
HSR: Could not send supervision frame
|
|
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
|
|
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
|
|
expire_timers kernel/time/timer.c:1751 [inline]
|
|
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
|
|
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
invoke_softirq kernel/softirq.c:427 [inline]
|
|
__irq_exit_rcu kernel/softirq.c:632 [inline]
|
|
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
|
|
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
|
|
...
|
|
|
|
This issue is also found in older kernels (at least up to 5.10).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26707</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
|
|
|
|
(struct dirty_throttle_control *)->thresh is an unsigned long, but is
|
|
passed as the u32 divisor argument to div_u64(). On architectures where
|
|
unsigned long is 64 bytes, the argument will be implicitly truncated.
|
|
|
|
Use div64_u64() instead of div_u64() so that the value used in the "is
|
|
this a safe division" check is the same as the divisor.
|
|
|
|
Also, remove redundant cast of the numerator to u64, as that should happen
|
|
implicitly.
|
|
|
|
This would be difficult to exploit in memcg domain, given the ratio-based
|
|
arithmetic domain_drity_limits() uses, but is much easier in global
|
|
writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
|
|
vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26720</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't drop extent_map for free space inode on write error
|
|
|
|
While running the CI for an unrelated change I hit the following panic
|
|
with generic/648 on btrfs_holes_spacecache.
|
|
|
|
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/extent_io.c:1385!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
|
|
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
|
|
Call Trace:
|
|
<TASK>
|
|
extent_write_cache_pages+0x2ac/0x8f0
|
|
extent_writepages+0x87/0x110
|
|
do_writepages+0xd5/0x1f0
|
|
filemap_fdatawrite_wbc+0x63/0x90
|
|
__filemap_fdatawrite_range+0x5c/0x80
|
|
btrfs_fdatawrite_range+0x1f/0x50
|
|
btrfs_write_out_cache+0x507/0x560
|
|
btrfs_write_dirty_block_groups+0x32a/0x420
|
|
commit_cowonly_roots+0x21b/0x290
|
|
btrfs_commit_transaction+0x813/0x1360
|
|
btrfs_sync_file+0x51a/0x640
|
|
__x64_sys_fdatasync+0x52/0x90
|
|
do_syscall_64+0x9c/0x190
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
This happens because we fail to write out the free space cache in one
|
|
instance, come back around and attempt to write it again. However on
|
|
the second pass through we go to call btrfs_get_extent() on the inode to
|
|
get the extent mapping. Because this is a new block group, and with the
|
|
free space inode we always search the commit root to avoid deadlocking
|
|
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
|
|
requested range.
|
|
|
|
This happens because the first time we try to write the space cache out
|
|
we hit an error, and on an error we drop the extent mapping. This is
|
|
normal for normal files, but the free space cache inode is special. We
|
|
always expect the extent map to be correct. Thus the second time
|
|
through we end up with a bogus extent map.
|
|
|
|
Since we're deprecating this feature, the most straightforward way to
|
|
fix this is to simply skip dropping the extent map range for this failed
|
|
range.
|
|
|
|
I shortened the test by using error injection to stress the area to make
|
|
it easier to reproduce. With this patch in place we no longer panic
|
|
with my error injection test.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26726</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arp: Prevent overflow in arp_req_get().
|
|
|
|
syzkaller reported an overflown write in arp_req_get(). [0]
|
|
|
|
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
|
|
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
|
|
|
|
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
|
|
the sa_data buffer is just 14 bytes.
|
|
|
|
In the splat below, 2 bytes are overflown to the next int field,
|
|
arp_flags. We initialise the field just after the memcpy(), so it's
|
|
not a problem.
|
|
|
|
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
|
|
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
|
|
in arp_ioctl() before calling arp_req_get().
|
|
|
|
To avoid the overflow, let's limit the max length of memcpy().
|
|
|
|
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
|
|
array in struct sockaddr") just silenced syzkaller.
|
|
|
|
[0]:
|
|
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
|
|
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Modules linked in:
|
|
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
|
|
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
|
|
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
|
|
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
|
|
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
|
|
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
|
|
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
|
|
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
|
|
sock_ioctl+0x3ef/0x650 net/socket.c:1321
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:870 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:856 [inline]
|
|
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
|
|
entry_SYSCALL_64_after_hwframe+0x64/0xce
|
|
RIP: 0033:0x7f172b262b8d
|
|
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
|
|
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
|
|
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26733</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
devlink: fix possible use-after-free and memory leaks in devlink_init()
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.
|
|
|
|
Make an unregister in case of unsuccessful registration.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26734</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix possible use-after-free and null-ptr-deref
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26735</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: don't override retval if we already lost the skb
|
|
|
|
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
|
|
yet, we need to tell the core to drop the skb by setting the retcode
|
|
to SHOT. If we have called tcf_mirred_forward(), however, the skb
|
|
is out of our hands and returning SHOT will lead to UaF.
|
|
|
|
Move the retval override to the error path which actually need it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26739</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: use the backlog for mirred ingress
|
|
|
|
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
|
|
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
|
|
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
|
|
lockdep.
|
|
|
|
The problem as previously described by Davide (see Link) is that
|
|
if we reverse flow of traffic with the redirect (egress -> ingress)
|
|
we may reach the same socket which generated the packet. And we may
|
|
still be holding its socket lock. The common solution to such deadlocks
|
|
is to put the packet in the Rx backlog, rather than run the Rx path
|
|
inline. Do that for all egress -> ingress reversals, not just once
|
|
we started to nest mirred calls.
|
|
|
|
In the past there was a concern that the backlog indirection will
|
|
lead to loss of error reporting / less accurate stats. But the current
|
|
workaround does not seem to address the issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26740</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="35" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/qedr: Fix qedr_create_user_qp error flow
|
|
|
|
Avoid the following warning by making sure to free the allocated
|
|
resources in case that qedr_init_user_queue() fail.
|
|
|
|
-----------[ cut here ]-----------
|
|
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
|
|
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
|
|
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
|
|
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
|
|
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
|
|
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
|
|
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
|
|
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
|
|
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
|
|
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
|
|
Call Trace:
|
|
<TASK>
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? __warn+0x81/0x110
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? report_bug+0x10a/0x140
|
|
? handle_bug+0x3c/0x70
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
__fput+0x94/0x250
|
|
task_work_run+0x5c/0x90
|
|
do_exit+0x270/0x4a0
|
|
do_group_exit+0x2d/0x90
|
|
get_signal+0x87c/0x8c0
|
|
arch_do_signal_or_restart+0x25/0x100
|
|
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
|
|
exit_to_user_mode_loop+0x9c/0x130
|
|
exit_to_user_mode_prepare+0xb6/0x100
|
|
syscall_exit_to_user_mode+0x12/0x40
|
|
do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? common_interrupt+0x43/0xa0
|
|
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
|
RIP: 0033:0x1470abe3ec6b
|
|
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
|
|
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
|
|
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
|
|
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
|
|
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
|
|
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
|
|
</TASK>
|
|
--[ end trace 888a9b92e04c5c97 ]--</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26743</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Support specifying the srpt_service_guid parameter
|
|
|
|
Make loading ib_srpt with this parameter set work. The current behavior is
|
|
that setting that parameter while loading the ib_srpt kernel module
|
|
triggers the following kernel crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
Call Trace:
|
|
<TASK>
|
|
parse_one+0x18c/0x1d0
|
|
parse_args+0xe1/0x230
|
|
load_module+0x8de/0xa60
|
|
init_module_from_file+0x8b/0xd0
|
|
idempotent_init_module+0x181/0x240
|
|
__x64_sys_finit_module+0x5a/0xb0
|
|
do_syscall_64+0x5f/0xe0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26744</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="37" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
|
|
|
|
The gtp_net_ops pernet operations structure for the subsystem must be
|
|
registered before registering the generic netlink family.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
general protection fault, probably for non-canonical address
|
|
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
|
|
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
|
|
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
|
|
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
|
|
RSP: 0018:ffff888014107220 EFLAGS: 00010202
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
|
|
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
|
|
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x90/0xa0
|
|
? die_addr+0x50/0xd0
|
|
? exc_general_protection+0x148/0x220
|
|
? asm_exc_general_protection+0x22/0x30
|
|
? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
? __alloc_skb+0x1dd/0x350
|
|
? __pfx___alloc_skb+0x10/0x10
|
|
genl_dumpit+0x11d/0x230
|
|
netlink_dump+0x5b9/0xce0
|
|
? lockdep_hardirqs_on_prepare+0x253/0x430
|
|
? __pfx_netlink_dump+0x10/0x10
|
|
? kasan_save_track+0x10/0x40
|
|
? __kasan_kmalloc+0x9b/0xa0
|
|
? genl_start+0x675/0x970
|
|
__netlink_dump_start+0x6fc/0x9f0
|
|
genl_family_rcv_msg_dumpit+0x1bb/0x2d0
|
|
? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
|
|
? genl_op_from_small+0x2a/0x440
|
|
? cap_capable+0x1d0/0x240
|
|
? __pfx_genl_start+0x10/0x10
|
|
? __pfx_genl_dumpit+0x10/0x10
|
|
? __pfx_genl_done+0x10/0x10
|
|
? security_capable+0x9d/0xe0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26754</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="38" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm-crypt: don't modify the data when using authenticated encryption
|
|
|
|
It was said that authenticated encryption could produce invalid tag when
|
|
the data that is being encrypted is modified [1]. So, fix this problem by
|
|
copying the data into the clone bio first and then encrypt them inside the
|
|
clone bio.
|
|
|
|
This may reduce performance, but it is needed to prevent the user from
|
|
corrupting the device by writing data with O_DIRECT and modifying them at
|
|
the same time.
|
|
|
|
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26763</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:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
|
|
|
|
Return IRQ_NONE from the interrupt handler when no interrupt was
|
|
detected. Because an empty interrupt will cause a null pointer error:
|
|
|
|
Unable to handle kernel NULL pointer dereference at virtual
|
|
address 0000000000000008
|
|
Call trace:
|
|
complete+0x54/0x100
|
|
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
|
|
__handle_irq_event_percpu+0x64/0x1e0
|
|
handle_irq_event+0x7c/0x1cc</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26776</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="40" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: fix double-free on socket dismantle
|
|
|
|
when MPTCP server accepts an incoming connection, it clones its listener
|
|
socket. However, the pointer to 'inet_opt' for the new socket has the same
|
|
value as the original one: as a consequence, on program exit it's possible
|
|
to observe the following splat:
|
|
|
|
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
|
|
Free of addr ffff888485950880 by task swapper/25/0
|
|
|
|
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
|
|
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl+0x32/0x50
|
|
print_report+0xca/0x620
|
|
kasan_report_invalid_free+0x64/0x90
|
|
__kasan_slab_free+0x1aa/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
rcu_do_batch+0x34e/0xd90
|
|
rcu_core+0x559/0xac0
|
|
__do_softirq+0x183/0x5a4
|
|
irq_exit_rcu+0x12d/0x170
|
|
sysvec_apic_timer_interrupt+0x6b/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x16/0x20
|
|
RIP: 0010:cpuidle_enter_state+0x175/0x300
|
|
Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b
|
|
RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
|
|
RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
|
|
RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
|
|
RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
|
|
R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
|
|
R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
|
|
cpuidle_enter+0x4a/0xa0
|
|
do_idle+0x310/0x410
|
|
cpu_startup_entry+0x51/0x60
|
|
start_secondary+0x211/0x270
|
|
secondary_startup_64_no_verify+0x184/0x18b
|
|
</TASK>
|
|
|
|
Allocated by task 6853:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
__kasan_kmalloc+0xa6/0xb0
|
|
__kmalloc+0x1eb/0x450
|
|
cipso_v4_sock_setattr+0x96/0x360
|
|
netlbl_sock_setattr+0x132/0x1f0
|
|
selinux_netlbl_socket_post_create+0x6c/0x110
|
|
selinux_socket_post_create+0x37b/0x7f0
|
|
security_socket_post_create+0x63/0xb0
|
|
__sock_create+0x305/0x450
|
|
__sys_socket_create.part.23+0xbd/0x130
|
|
__sys_socket+0x37/0xb0
|
|
__x64_sys_socket+0x6f/0xb0
|
|
do_syscall_64+0x83/0x160
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Freed by task 6858:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
__kasan_slab_free+0x12c/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
subflow_ulp_release+0x1f0/0x250
|
|
tcp_cleanup_ulp+0x6e/0x110
|
|
tcp_v4_destroy_sock+0x5a/0x3a0
|
|
inet_csk_destroy_sock+0x135/0x390
|
|
tcp_fin+0x416/0x5c0
|
|
tcp_data_queue+0x1bc8/0x4310
|
|
tcp_rcv_state_process+0x15a3/0x47b0
|
|
tcp_v4_do_rcv+0x2c1/0x990
|
|
tcp_v4_rcv+0x41fb/0x5ed0
|
|
ip_protocol_deliver_rcu+0x6d/0x9f0
|
|
ip_local_deliver_finish+0x278/0x360
|
|
ip_local_deliver+0x182/0x2c0
|
|
ip_rcv+0xb5/0x1c0
|
|
__netif_receive_skb_one_core+0x16e/0x1b0
|
|
process_backlog+0x1e3/0x650
|
|
__napi_poll+0xa6/0x500
|
|
net_rx_action+0x740/0xbb0
|
|
__do_softirq+0x183/0x5a4
|
|
|
|
The buggy address belongs to the object at ffff888485950880
|
|
which belongs to the cache kmalloc-64 of size 64
|
|
The buggy address is located 0 bytes inside of
|
|
64-byte region [ffff888485950880, ffff8884859508c0)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
|
|
flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
|
|
page_type: 0xffffffff()
|
|
raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
|
|
raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffff888485950780: fa fb fb
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26782</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: mmci: stm32: fix DMA API overlapping mappings warning
|
|
|
|
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
|
|
|
|
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
|
|
overlapping mappings aren't supported
|
|
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
|
|
add_dma_entry+0x234/0x2f4
|
|
Modules linked in:
|
|
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
|
|
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
|
|
Workqueue: events_freezable mmc_rescan
|
|
Call trace:
|
|
add_dma_entry+0x234/0x2f4
|
|
debug_dma_map_sg+0x198/0x350
|
|
__dma_map_sg_attrs+0xa0/0x110
|
|
dma_map_sg_attrs+0x10/0x2c
|
|
sdmmc_idma_prep_data+0x80/0xc0
|
|
mmci_prep_data+0x38/0x84
|
|
mmci_start_data+0x108/0x2dc
|
|
mmci_request+0xe4/0x190
|
|
__mmc_start_request+0x68/0x140
|
|
mmc_start_request+0x94/0xc0
|
|
mmc_wait_for_req+0x70/0x100
|
|
mmc_send_tuning+0x108/0x1ac
|
|
sdmmc_execute_tuning+0x14c/0x210
|
|
mmc_execute_tuning+0x48/0xec
|
|
mmc_sd_init_uhs_card.part.0+0x208/0x464
|
|
mmc_sd_init_card+0x318/0x89c
|
|
mmc_attach_sd+0xe4/0x180
|
|
mmc_rescan+0x244/0x320
|
|
|
|
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
|
|
dma_unmap_sg are not correctly balanced.
|
|
|
|
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
|
|
function is called and as this API is not managed on stm32 variant,
|
|
dma_unmap_sg is never called in this error path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26787</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26791</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix double free of anonymous device after snapshot creation failure
|
|
|
|
When creating a snapshot we may do a double free of an anonymous device
|
|
in case there's an error committing the transaction. The second free may
|
|
result in freeing an anonymous device number that was allocated by some
|
|
other subsystem in the kernel or another btrfs filesystem.
|
|
|
|
The steps that lead to this:
|
|
|
|
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
|
|
and assign it to pending_snapshot->anon_dev;
|
|
|
|
2) Then we call btrfs_commit_transaction() and end up at
|
|
transaction.c:create_pending_snapshot();
|
|
|
|
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
|
|
number stored in pending_snapshot->anon_dev;
|
|
|
|
4) btrfs_get_new_fs_root() frees that anonymous device number because
|
|
btrfs_lookup_fs_root() returned a root - someone else did a lookup
|
|
of the new root already, which could some task doing backref walking;
|
|
|
|
5) After that some error happens in the transaction commit path, and at
|
|
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
|
|
that we free again the same anonymous device number, which in the
|
|
meanwhile may have been reallocated somewhere else, because
|
|
pending_snapshot->anon_dev still has the same value as in step 1.
|
|
|
|
Recently syzbot ran into this and reported the following trace:
|
|
|
|
------------[ cut here ]------------
|
|
ida_free called for id=51 which is not allocated.
|
|
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
|
|
Modules linked in:
|
|
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
|
|
Code: 10 42 80 3c 28 (...)
|
|
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
|
|
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
|
|
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
|
|
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
|
|
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
|
|
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
|
|
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346
|
|
create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837
|
|
create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931
|
|
btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404
|
|
create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848
|
|
btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998
|
|
btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044
|
|
__btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306
|
|
btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393
|
|
btrfs_ioctl+0xa74/0xd40
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:871 [inline]
|
|
__se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7fca3e67dda9
|
|
Code: 28 00 00 00 (...)
|
|
RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9
|
|
RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658
|
|
</TASK>
|
|
|
|
Where we get an explicit message where we attempt to free an anonymous
|
|
device number that is not currently allocated. It happens in a different
|
|
code path from the example below, at btrfs_get_root_ref(), so this change
|
|
may not fix the case triggered by sy
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26792</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Avoid potential use-after-free in hci_error_reset
|
|
|
|
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
|
|
BT controller is not responding, the GPIO reset mechanism would
|
|
free the hci_dev and lead to a use-after-free in hci_error_reset.
|
|
|
|
Here's the call trace observed on a ChromeOS device with Intel AX201:
|
|
queue_work_on+0x3e/0x6c
|
|
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
|
|
? init_wait_entry+0x31/0x31
|
|
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
|
|
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
|
|
process_one_work+0x1d8/0x33f
|
|
worker_thread+0x21b/0x373
|
|
kthread+0x13a/0x152
|
|
? pr_cont_work+0x54/0x54
|
|
? kthread_blkcg+0x31/0x31
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This patch holds the reference count on the hci_dev while processing
|
|
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26801</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ip_tunnel: prevent perpetual headroom growth
|
|
|
|
syzkaller triggered following kasan splat:
|
|
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
|
|
[..]
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:588
|
|
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
|
|
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
|
|
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
|
|
skb_get_hash include/linux/skbuff.h:1556 [inline]
|
|
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
|
|
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
|
|
__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+0x13d/0x6d0 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
|
|
...
|
|
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
|
|
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
|
|
..
|
|
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
|
|
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
|
|
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
|
|
__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+0x13d/0x6d0 net/core/dev.c:3564
|
|
...
|
|
|
|
The splat occurs because skb->data points past skb->head allocated area.
|
|
This is because neigh layer does:
|
|
__skb_pull(skb, skb_network_offset(skb));
|
|
|
|
... but skb_network_offset() returns a negative offset and __skb_pull()
|
|
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
|
|
|
|
The negative value is returned because skb->head and skb->data distance is
|
|
more than 64k and skb->network_header (u16) has wrapped around.
|
|
|
|
The bug is in the ip_tunnel infrastructure, which can cause
|
|
dev->needed_headroom to increment ad infinitum.
|
|
|
|
The syzkaller reproducer consists of packets getting routed via a gre
|
|
tunnel, and route of gre encapsulated packets pointing at another (ipip)
|
|
tunnel. The ipip encapsulation finds gre0 as next output device.
|
|
|
|
This results in the following pattern:
|
|
|
|
1). First packet is to be sent out via gre0.
|
|
Route lookup found an output device, ipip0.
|
|
|
|
2).
|
|
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
|
|
output device, rt.dev->needed_headroom (ipip0).
|
|
|
|
3).
|
|
ip output / start_xmit moves skb on to ipip0. which runs the same
|
|
code path again (xmit recursion).
|
|
|
|
4).
|
|
Routing step for the post-gre0-encap packet finds gre0 as output device
|
|
to use for ipip0 encapsulated packet.
|
|
|
|
tunl0->needed_headroom is then incremented based on the (already bumped)
|
|
gre0 device headroom.
|
|
|
|
This repeats for every future packet:
|
|
|
|
gre0->needed_headroom gets inflated because previous packets' ipip0 step
|
|
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
|
|
needed_headroom was increased.
|
|
|
|
For each subsequent packet, gre/ipip0->needed_headroom grows until
|
|
post-expand-head reallocations result in a skb->head/data distance of
|
|
more than 64k.
|
|
|
|
Once that happens, skb->network_header (u16) wraps around when
|
|
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
|
|
after the headroom expansion/reallocation.
|
|
|
|
After this skb_network_offset(skb) returns a different (and negative)
|
|
result post headroom expansion.
|
|
|
|
The next trip to neigh layer (or anything else that would __skb_pull the
|
|
network header) makes skb->data point to a memory location outside
|
|
skb->head area.
|
|
|
|
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
|
|
prevent perpetual increase instead of dropping the headroom increment
|
|
completely.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26804</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
|
|
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
|
|
size is specified as `len` and passed to skb_put_data(). This `len`
|
|
is based on `skb->end` that is not data offset but buffer offset. The
|
|
`skb->end` contains data and tailroom. Since the tailroom is not
|
|
initialized when the new `skb` created, KMSAN detects uninitialized
|
|
memory area when copying the data.
|
|
|
|
This patch resolved this issue by correct the len from `skb->end` to
|
|
`skb->len`, which is the actual data offset.
|
|
|
|
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
copy_to_iter include/linux/uio.h:197 [inline]
|
|
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
|
|
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
|
|
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
|
|
sock_recvmsg_nosec net/socket.c:1044 [inline]
|
|
sock_recvmsg net/socket.c:1066 [inline]
|
|
sock_read_iter+0x467/0x580 net/socket.c:1136
|
|
call_read_iter include/linux/fs.h:2014 [inline]
|
|
new_sync_read fs/read_write.c:389 [inline]
|
|
vfs_read+0x8f6/0xe00 fs/read_write.c:470
|
|
ksys_read+0x20f/0x4c0 fs/read_write.c:613
|
|
__do_sys_read fs/read_write.c:623 [inline]
|
|
__se_sys_read fs/read_write.c:621 [inline]
|
|
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
|
|
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 stored to memory at:
|
|
skb_put_data include/linux/skbuff.h:2622 [inline]
|
|
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
|
|
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
|
|
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
|
|
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
|
|
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
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:
|
|
free_pages_prepare mm/page_alloc.c:1087 [inline]
|
|
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
|
|
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
|
|
release_pages+0x23d3/0x2410 mm/swap.c:1042
|
|
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
|
|
tlb_batch_pages
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26805</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
|
|
|
|
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
|
|
event is reported, otherwise a stale reference to netdevice remains in
|
|
the hook list.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26808</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_set_pipapo: release elements in clone only from destroy path
|
|
|
|
Clone already always provides a current view of the lookup table, use it
|
|
to destroy the set, otherwise it is possible to destroy elements twice.
|
|
|
|
This fix requires:
|
|
|
|
212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
|
|
|
|
which came after:
|
|
|
|
9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26809</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26811</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26812</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/fsl-mc: Block calling interrupt handler without trigger
|
|
|
|
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
|
|
initially NULL and may become NULL if the user sets the trigger
|
|
eventfd to -1. The interrupt handler itself is guaranteed that
|
|
trigger is always valid between request_irq() and free_irq(), but
|
|
the loopback testing mechanisms to invoke the handler function
|
|
need to test the trigger. The triggering and setting ioctl paths
|
|
both make use of igate and are therefore mutually exclusive.
|
|
|
|
The vfio-fsl-mc driver does not make use of irqfds, nor does it
|
|
support any sort of masking operations, therefore unlike vfio-pci
|
|
and vfio-platform, the flow can remain essentially unchanged.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26814</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26817</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26828</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.3</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: ir_toy: fix a memleak in irtoy_tx
|
|
|
|
When irtoy_command fails, buf should be freed since it is allocated by
|
|
irtoy_tx, or there is a memleak.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26829</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26839</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="56" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="56" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26840</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="57" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="57" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi: runtime: Fix potential overflow of soft-reserved region size
|
|
|
|
md_size will have been narrowed if we have >= 4GB worth of pages in a
|
|
soft-reserved region.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26843</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="58" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="58" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-fc: do not wait in vain when unloading module
|
|
|
|
The module exit path has race between deleting all controllers and
|
|
freeing 'left over IDs'. To prevent double free a synchronization
|
|
between nvme_delete_ctrl and ida_destroy has been added by the initial
|
|
commit.
|
|
|
|
There is some logic around trying to prevent from hanging forever in
|
|
wait_for_completion, though it does not handling all cases. E.g.
|
|
blktests is able to reproduce the situation where the module unload
|
|
hangs forever.
|
|
|
|
If we completely rely on the cleanup code executed from the
|
|
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
|
|
calling ida_destroy unnecessary. We only have to ensure that all
|
|
nvme_delete_ctrl code has been executed before we leave
|
|
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
|
|
workqueue.
|
|
|
|
While at it, remove the unused nvme_fc_wq workqueue too.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26846</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="59" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="59" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26852</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="60" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="60" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
|
|
|
|
The function ice_bridge_setlink() may encounter a NULL pointer dereference
|
|
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
|
|
in nla_for_each_nested(). To address this issue, add a check to ensure that
|
|
br_spec is not NULL before proceeding with the nested attribute iteration.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26855</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="61" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="61" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/bnx2x: Prevent access to a freed page in page_pool
|
|
|
|
Fix race condition leading to system crash during EEH error handling
|
|
|
|
During EEH error recovery, the bnx2x driver's transmit timeout logic
|
|
could cause a race condition when handling reset tasks. The
|
|
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
|
|
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
|
|
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
|
|
overlap with the EEH driver's attempt to reset the device using
|
|
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
|
|
condition can result in system crashes due to accessing freed memory
|
|
locations in bnx2x_free_rx_sge()
|
|
|
|
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
|
|
800 struct bnx2x_fastpath *fp, u16 index)
|
|
801 {
|
|
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
|
|
803 struct page *page = sw_buf->page;
|
|
....
|
|
where sw_buf was set to NULL after the call to dma_unmap_page()
|
|
by the preceding thread.
|
|
|
|
EEH: Beginning: 'slot_reset'
|
|
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
|
|
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
|
|
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
|
|
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
|
|
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
|
|
BUG: Kernel NULL pointer dereference on read at 0x00000000
|
|
Faulting instruction address: 0xc0080000025065fc
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
.....
|
|
Call Trace:
|
|
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
|
|
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
|
|
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
|
|
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
|
|
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
|
|
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
|
|
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
|
|
|
|
To solve this issue, we need to verify page pool allocations before
|
|
freeing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26859</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="62" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="62" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
packet: annotate data-races around ignore_outgoing
|
|
|
|
ignore_outgoing is read locklessly from dev_queue_xmit_nit()
|
|
and packet_getsockopt()
|
|
|
|
Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
|
|
|
|
syzbot reported:
|
|
|
|
BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
|
|
|
|
write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
|
|
packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
|
|
do_sock_setsockopt net/socket.c:2311 [inline]
|
|
__sys_setsockopt+0x1d8/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
|
|
do_syscall_64+0xd3/0x1d0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
|
|
dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
|
|
xmit_one net/core/dev.c:3527 [inline]
|
|
dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
|
|
__dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
|
|
batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
|
|
batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
|
|
batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
|
|
batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
|
|
process_one_work kernel/workqueue.c:3254 [inline]
|
|
process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
|
|
worker_thread+0x526/0x730 kernel/workqueue.c:3416
|
|
kthread+0x1d1/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
|
|
|
|
value changed: 0x00 -> 0x01
|
|
|
|
Reported by Kernel Concurrency Sanitizer on:
|
|
CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26862</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="63" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="63" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hsr: Fix uninit-value access in hsr_get_node()
|
|
|
|
KMSAN reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
|
|
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
|
|
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
|
|
__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]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3087 [inline]
|
|
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 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+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
|
|
packet_snd net/packet/af_packet.c:3030 [inline]
|
|
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
=====================================================
|
|
|
|
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
|
|
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
|
|
reads an invalid value as a sequence number. This causes the above issue.
|
|
|
|
This patch fixes the issue by returning NULL if the Ethernet header is not
|
|
followed by an HSR tag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26863</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="64" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="64" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
|
|
|
|
syzkaller reported a warning of netns tracker [0] followed by KASAN
|
|
splat [1] and another ref tracker warning [1].
|
|
|
|
syzkaller could not find a repro, but in the log, the only suspicious
|
|
sequence was as follows:
|
|
|
|
18:26:22 executing program 1:
|
|
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
|
|
...
|
|
connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
|
|
|
|
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
|
|
|
|
So, the scenario would be:
|
|
|
|
1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
|
|
rds_tcp_listen_init().
|
|
2. syz-executor connect()s to it and creates a reqsk.
|
|
3. syz-executor exit()s immediately.
|
|
4. netns is dismantled. [0]
|
|
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
|
|
6. listener is freed after RCU grace period. [2]
|
|
|
|
Basically, reqsk assumes that the listener guarantees netns safety
|
|
until all reqsk timers are expired by holding the listener's refcount.
|
|
However, this was not the case for kernel sockets.
|
|
|
|
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in
|
|
inet_twsk_purge()") fixed this issue only for per-netns ehash.
|
|
|
|
Let's apply the same fix for the global ehash.
|
|
|
|
[0]:
|
|
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
|
|
sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
|
|
inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
|
|
__sock_create (net/socket.c:1572)
|
|
rds_tcp_listen_init (net/rds/tcp_listen.c:279)
|
|
rds_tcp_init_net (net/rds/tcp.c:577)
|
|
ops_init (net/core/net_namespace.c:137)
|
|
setup_net (net/core/net_namespace.c:340)
|
|
copy_net_ns (net/core/net_namespace.c:497)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
|
|
ksys_unshare (kernel/fork.c:3429)
|
|
__x64_sys_unshare (kernel/fork.c:3496)
|
|
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
...
|
|
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
|
|
|
|
[1]:
|
|
BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
|
|
print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)
|
|
reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
|
|
call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
|
|
__run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
|
|
run_timer_softirq (kernel/time/timer.c:2053)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
|
|
irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
|
|
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
|
|
</IRQ>
|
|
|
|
Allocated by task 258 on cpu 0 at 83.612050s:
|
|
kasan_save_stack (mm/kasan/common.c:48)
|
|
kasan_save_track (mm/kasan/common.c:68)
|
|
__kasan_slab_alloc (mm/kasan/common.c:343)
|
|
kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
|
|
copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
|
|
create_new_namespaces (kernel/nsproxy.c:110)
|
|
unshare_nsproxy_name
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26865</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.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="65" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="65" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to truncate meta inode pages forcely
|
|
|
|
Below race case can cause data corruption:
|
|
|
|
Thread A GC thread
|
|
- gc_data_segment
|
|
- ra_data_block
|
|
- locked meta_inode page
|
|
- f2fs_inplace_write_data
|
|
- invalidate_mapping_pages
|
|
: fail to invalidate meta_inode page
|
|
due to lock failure or dirty|writeback
|
|
status
|
|
- f2fs_submit_page_bio
|
|
: write last dirty data to old blkaddr
|
|
- move_data_block
|
|
- load old data from meta_inode page
|
|
- f2fs_submit_page_write
|
|
: write old data to new blkaddr
|
|
|
|
Because invalidate_mapping_pages() will skip invalidating page which
|
|
has unclear status including locked, dirty, writeback and so on, so
|
|
we need to use truncate_inode_pages_range() instead of
|
|
invalidate_mapping_pages() to make sure meta_inode page will be dropped.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26869</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="66" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
|
|
|
|
A call to listxattr() with a buffer size = 0 returns the actual
|
|
size of the buffer needed for a subsequent call. When size > 0,
|
|
nfs4_listxattr() does not return an error because either
|
|
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
|
|
exactly all the bytes then size is 0 when calling
|
|
nfs4_listxattr_nfs4_user() which then triggers the following
|
|
kernel BUG:
|
|
|
|
[ 99.403778] kernel BUG at mm/usercopy.c:102!
|
|
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
|
|
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
|
|
[ 99.415827] Call trace:
|
|
[ 99.415985] usercopy_abort+0x70/0xa0
|
|
[ 99.416227] __check_heap_object+0x134/0x158
|
|
[ 99.416505] check_heap_object+0x150/0x188
|
|
[ 99.416696] __check_object_size.part.0+0x78/0x168
|
|
[ 99.416886] __check_object_size+0x28/0x40
|
|
[ 99.417078] listxattr+0x8c/0x120
|
|
[ 99.417252] path_listxattr+0x78/0xe0
|
|
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
|
|
[ 99.417723] invoke_syscall+0x78/0x100
|
|
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
|
|
[ 99.418186] do_el0_svc+0x24/0x38
|
|
[ 99.418376] el0_svc+0x3c/0x110
|
|
[ 99.418554] el0t_64_sync_handler+0x120/0x130
|
|
[ 99.418788] el0t_64_sync+0x194/0x198
|
|
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
|
|
|
|
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
|
|
thus calling lisxattr() with size = 16 will trigger the bug.
|
|
|
|
Add check on nfs4_listxattr() to return ERANGE error when it is
|
|
called with size > 0 and the return value is greater than size.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26870</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="67" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="67" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Do not register event handler until srpt device is fully setup
|
|
|
|
Upon rare occasions, KASAN reports a use-after-free Write
|
|
in srpt_refresh_port().
|
|
|
|
This seems to be because an event handler is registered before the
|
|
srpt device is fully setup and a race condition upon error may leave a
|
|
partially setup event handler in place.
|
|
|
|
Instead, only register the event handler after srpt device initialization
|
|
is complete.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26872</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="68" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="68" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26875</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="69" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="69" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26878</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="70" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="70" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm: call the resume method on internal suspend
|
|
|
|
There is this reported crash when experimenting with the lvm2 testsuite.
|
|
The list corruption is caused by the fact that the postsuspend and resume
|
|
methods were not paired correctly; there were two consecutive calls to the
|
|
origin_postsuspend function. The second call attempts to remove the
|
|
"hash_list" entry from a list, while it was already removed by the first
|
|
call.
|
|
|
|
Fix __dm_internal_resume so that it calls the preresume and resume
|
|
methods of the table's targets.
|
|
|
|
If a preresume method of some target fails, we are in a tricky situation.
|
|
We can't return an error because dm_internal_resume isn't supposed to
|
|
return errors. We can't return success, because then the "resume" and
|
|
"postsuspend" methods would not be paired correctly. So, we set the
|
|
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
|
|
tools, but it won't cause a kernel crash.
|
|
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/list_debug.c:56!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
|
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
|
|
<snip>
|
|
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
|
|
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
|
|
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
|
|
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
|
|
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
|
|
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
|
|
FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
|
|
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x2d/0x80
|
|
? do_trap+0xeb/0xf0
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? do_error_trap+0x60/0x80
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? exc_invalid_op+0x49/0x60
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
origin_postsuspend+0x1a/0x50 [dm_snapshot]
|
|
dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
|
|
dm_suspend+0xd8/0xf0 [dm_mod]
|
|
dev_suspend+0x1f2/0x2f0 [dm_mod]
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
ctl_ioctl+0x300/0x5f0 [dm_mod]
|
|
dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
|
|
__x64_compat_sys_ioctl+0x104/0x170
|
|
do_syscall_64+0x184/0x1b0
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0xf7e6aead
|
|
<snip>
|
|
---[ end trace 0000000000000000 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26880</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="71" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="71" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firmware: arm_scmi: Fix double free in SMC transport cleanup path
|
|
|
|
When the generic SCMI code tears down a channel, it calls the chan_free
|
|
callback function, defined by each transport. Since multiple protocols
|
|
might share the same transport_info member, chan_free() might want to
|
|
clean up the same member multiple times within the given SCMI transport
|
|
implementation. In this case, it is SMC transport. This will lead to a NULL
|
|
pointer dereference at the second time:
|
|
|
|
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
|
|
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
|
|
| arm-scmi firmware:scmi: unable to communicate with SCMI
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| Mem abort info:
|
|
| ESR = 0x0000000096000004
|
|
| EC = 0x25: DABT (current EL), IL = 32 bits
|
|
| SET = 0, FnV = 0
|
|
| EA = 0, S1PTW = 0
|
|
| FSC = 0x04: level 0 translation fault
|
|
| Data abort info:
|
|
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|
|
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|
|
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
|
|
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
|
|
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
|
|
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
|
|
| Modules linked in:
|
|
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
|
|
| Hardware name: FVP Base RevC (DT)
|
|
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
| pc : smc_chan_free+0x3c/0x6c
|
|
| lr : smc_chan_free+0x3c/0x6c
|
|
| Call trace:
|
|
| smc_chan_free+0x3c/0x6c
|
|
| idr_for_each+0x68/0xf8
|
|
| scmi_cleanup_channels.isra.0+0x2c/0x58
|
|
| scmi_probe+0x434/0x734
|
|
| platform_probe+0x68/0xd8
|
|
| really_probe+0x110/0x27c
|
|
| __driver_probe_device+0x78/0x12c
|
|
| driver_probe_device+0x3c/0x118
|
|
| __driver_attach+0x74/0x128
|
|
| bus_for_each_dev+0x78/0xe0
|
|
| driver_attach+0x24/0x30
|
|
| bus_add_driver+0xe4/0x1e8
|
|
| driver_register+0x60/0x128
|
|
| __platform_driver_register+0x28/0x34
|
|
| scmi_driver_init+0x84/0xc0
|
|
| do_one_initcall+0x78/0x33c
|
|
| kernel_init_freeable+0x2b8/0x51c
|
|
| kernel_init+0x24/0x130
|
|
| ret_from_fork+0x10/0x20
|
|
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
|
|
| ---[ end trace 0000000000000000 ]---
|
|
|
|
Simply check for the struct pointer being NULL before trying to access
|
|
its members, to avoid this situation.
|
|
|
|
This was found when a transport doesn't really work (for instance no SMC
|
|
service), the probe routines then tries to clean up, and triggers a crash.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26893</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="72" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="72" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
|
|
|
|
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
|
|
observed on interface registration error path, or simply by
|
|
removing the module/unbinding device from driver:
|
|
|
|
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
|
|
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
|
|
Read of size 4 at addr c54d1ce8 by task sh/86
|
|
|
|
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
|
|
Hardware name: Atmel SAMA5
|
|
unwind_backtrace from show_stack+0x18/0x1c
|
|
show_stack from dump_stack_lvl+0x34/0x58
|
|
dump_stack_lvl from print_report+0x154/0x500
|
|
print_report from kasan_report+0xac/0xd8
|
|
kasan_report from wilc_netdev_cleanup+0x508/0x5cc
|
|
wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
|
|
wilc_bus_remove from spi_remove+0x8c/0xac
|
|
spi_remove from device_release_driver_internal+0x434/0x5f8
|
|
device_release_driver_internal from unbind_store+0xbc/0x108
|
|
unbind_store from kernfs_fop_write_iter+0x398/0x584
|
|
kernfs_fop_write_iter from vfs_write+0x728/0xf88
|
|
vfs_write from ksys_write+0x110/0x1e4
|
|
ksys_write from ret_fast_syscall+0x0/0x1c
|
|
|
|
[...]
|
|
|
|
Allocated by task 1:
|
|
kasan_save_track+0x30/0x5c
|
|
__kasan_kmalloc+0x8c/0x94
|
|
__kmalloc_node+0x1cc/0x3e4
|
|
kvmalloc_node+0x48/0x180
|
|
alloc_netdev_mqs+0x68/0x11dc
|
|
alloc_etherdev_mqs+0x28/0x34
|
|
wilc_netdev_ifc_init+0x34/0x8ec
|
|
wilc_cfg80211_init+0x690/0x910
|
|
wilc_bus_probe+0xe0/0x4a0
|
|
spi_probe+0x158/0x1b0
|
|
really_probe+0x270/0xdf4
|
|
__driver_probe_device+0x1dc/0x580
|
|
driver_probe_device+0x60/0x140
|
|
__driver_attach+0x228/0x5d4
|
|
bus_for_each_dev+0x13c/0x1a8
|
|
bus_add_driver+0x2a0/0x608
|
|
driver_register+0x24c/0x578
|
|
do_one_initcall+0x180/0x310
|
|
kernel_init_freeable+0x424/0x484
|
|
kernel_init+0x20/0x148
|
|
ret_from_fork+0x14/0x28
|
|
|
|
Freed by task 86:
|
|
kasan_save_track+0x30/0x5c
|
|
kasan_save_free_info+0x38/0x58
|
|
__kasan_slab_free+0xe4/0x140
|
|
kfree+0xb0/0x238
|
|
device_release+0xc0/0x2a8
|
|
kobject_put+0x1d4/0x46c
|
|
netdev_run_todo+0x8fc/0x11d0
|
|
wilc_netdev_cleanup+0x1e4/0x5cc
|
|
wilc_bus_remove+0xc8/0xec
|
|
spi_remove+0x8c/0xac
|
|
device_release_driver_internal+0x434/0x5f8
|
|
unbind_store+0xbc/0x108
|
|
kernfs_fop_write_iter+0x398/0x584
|
|
vfs_write+0x728/0xf88
|
|
ksys_write+0x110/0x1e4
|
|
ret_fast_syscall+0x0/0x1c
|
|
[...]
|
|
|
|
David Mosberger-Tan initial investigation [1] showed that this
|
|
use-after-free is due to netdevice unregistration during vif list
|
|
traversal. When unregistering a net device, since the needs_free_netdev has
|
|
been set to true during registration, the netdevice object is also freed,
|
|
and as a consequence, the corresponding vif object too, since it is
|
|
attached to it as private netdevice data. The next occurrence of the loop
|
|
then tries to access freed vif pointer to the list to move forward in the
|
|
list.
|
|
|
|
Fix this use-after-free thanks to two mechanisms:
|
|
- navigate in the list with list_for_each_entry_safe, which allows to
|
|
safely modify the list as we go through each element. For each element,
|
|
remove it from the list with list_del_rcu
|
|
- make sure to wait for RCU grace period end after each vif removal to make
|
|
sure it is safe to free the corresponding vif too (through
|
|
unregister_netdev)
|
|
|
|
Since we are in a RCU "modifier" path (not a "reader" path), and because
|
|
such path is expected not to be concurrent to any other modifier (we are
|
|
using the vif_mutex lock), we do not need to use RCU list API, that's why
|
|
we can benefit from list_for_each_entry_safe.
|
|
|
|
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26895</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="73" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="73" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: wfx: fix memory leak when starting AP
|
|
|
|
Kmemleak reported this error:
|
|
|
|
unreferenced object 0xd73d1180 (size 184):
|
|
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
|
|
[<127bdd74>] __alloc_skb+0x144/0x170
|
|
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
|
|
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
|
|
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
|
|
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
|
|
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
|
|
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
|
|
[<47bd8b68>] genl_rcv_msg+0x198/0x378
|
|
[<453ef796>] netlink_rcv_skb+0xd0/0x130
|
|
[<6b7c977a>] genl_rcv+0x34/0x44
|
|
[<66b2d04d>] netlink_unicast+0x1b4/0x258
|
|
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
|
|
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
|
|
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
|
|
[<69954f45>] __sys_sendmsg+0x64/0xa8
|
|
unreferenced object 0xce087000 (size 1024):
|
|
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
|
|
backtrace:
|
|
[<9a993714>] __kmalloc_track_caller+0x230/0x600
|
|
[<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
|
|
[<a2c61343>] __alloc_skb+0xa0/0x170
|
|
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
|
|
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
|
|
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
|
|
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
|
|
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
|
|
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
|
|
[<47bd8b68>] genl_rcv_msg+0x198/0x378
|
|
[<453ef796>] netlink_rcv_skb+0xd0/0x130
|
|
[<6b7c977a>] genl_rcv+0x34/0x44
|
|
[<66b2d04d>] netlink_unicast+0x1b4/0x258
|
|
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
|
|
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
|
|
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
|
|
|
|
However, since the kernel is build optimized, it seems the stack is not
|
|
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
|
|
is obvious in this function: memory allocated by ieee80211_beacon_get()
|
|
is never released. Fixing this leak makes kmemleak happy.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26896</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.3</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="74" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="74" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
|
|
|
|
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
|
|
structures have been fully initialised by the time it runs. However, because of
|
|
the order in which things are initialised, this is not guaranteed to be the
|
|
case, because the device is exposed to the USB subsystem before the ath9k driver
|
|
initialisation is completed.
|
|
|
|
We already committed a partial fix for this in commit:
|
|
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
|
|
|
|
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
|
|
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
|
|
seems syzbot managed to trigger the race for one of the other commands as well,
|
|
so let's just move the existing synchronisation bit to cover the whole
|
|
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
|
|
ath9k_tx_init()).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26897</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="75" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="75" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
|
|
|
|
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
|
|
|
|
This commit causes interrupts to be lost for FCoE devices, since it changed
|
|
sping locks from "bh" to "irqsave".
|
|
|
|
Instead, a work queue should be used, and will be addressed in a separate
|
|
commit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26917</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="76" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="76" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26921</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="77" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="77" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: validate the parameters of bo mapping operations more clearly
|
|
|
|
Verify the parameters of
|
|
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26922</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |