1584 lines
72 KiB
XML
1584 lines
72 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-20.03-LTS-SP4</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-1793</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-05</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-05</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-05</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-05</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</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:
|
|
|
|
net: ethernet: fix potential use-after-free in ec_bhf_remove
|
|
|
|
static void ec_bhf_remove(struct pci_dev *dev)
|
|
{
|
|
...
|
|
struct ec_bhf_priv *priv = netdev_priv(net_dev);
|
|
|
|
unregister_netdev(net_dev);
|
|
free_netdev(net_dev);
|
|
|
|
pci_iounmap(dev, priv->dma_io);
|
|
pci_iounmap(dev, priv->io);
|
|
...
|
|
}
|
|
|
|
priv is netdev private data, but it is used
|
|
after free_netdev(). It can cause use-after-free when accessing priv
|
|
pointer. So, fix it by moving free_netdev() after pci_iounmap()
|
|
calls.(CVE-2021-47235)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47285)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac80211: track only QoS data frames for admission control
|
|
|
|
For admission control, obviously all of that only works for
|
|
QoS data frames, otherwise we cannot even access the QoS
|
|
field in the header.
|
|
|
|
Syzbot reported (see below) an uninitialized value here due
|
|
to a status of a non-QoS nullfunc packet, which isn't even
|
|
long enough to contain the QoS header.
|
|
|
|
Fix this to only do anything for QoS data packets.(CVE-2021-47602)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
|
|
|
|
Running tests with a debug kernel shows that bnx2fc_recv_frame() is
|
|
modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot
|
|
a debug kernel and run the bnx2fc driver with the hardware enabled.
|
|
|
|
[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_
|
|
[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
|
|
[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B
|
|
[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
|
|
[ 1391.699183] Call Trace:
|
|
[ 1391.699188] dump_stack_lvl+0x57/0x7d
|
|
[ 1391.699198] check_preemption_disabled+0xc8/0xd0
|
|
[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
|
|
[ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180
|
|
[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]
|
|
[ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]
|
|
[ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]
|
|
[ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]
|
|
[ 1391.699258] kthread+0x364/0x420
|
|
[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50
|
|
[ 1391.699268] ? set_kthread_struct+0x100/0x100
|
|
[ 1391.699273] ret_from_fork+0x22/0x30
|
|
|
|
Restore the old get_cpu/put_cpu code with some modifications to reduce the
|
|
size of the critical section.(CVE-2022-48715)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev
|
|
|
|
struct rpmsg_ctrldev contains a struct cdev. The current code frees
|
|
the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the
|
|
cdev is a managed object, therefore its release is not predictable
|
|
and the rpmsg_ctrldev could be freed before the cdev is entirely
|
|
released, as in the backtrace below.
|
|
|
|
[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
|
|
[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
|
|
[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
|
|
[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26
|
|
[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
|
|
[ 93.730055] Workqueue: events kobject_delayed_cleanup
|
|
[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
|
|
[ 93.740216] pc : debug_print_object+0x13c/0x1b0
|
|
[ 93.744890] lr : debug_print_object+0x13c/0x1b0
|
|
[ 93.749555] sp : ffffffacf5bc7940
|
|
[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
|
|
[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
|
|
[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
|
|
[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
|
|
[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
|
|
[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0
|
|
[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000
|
|
[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
|
|
[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
|
|
[ 93.802244] x11: 0000000000000001 x10: 0000000000000000
|
|
[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
|
|
[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000
|
|
[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000
|
|
[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
|
|
[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
|
|
[ 93.835104] Call trace:
|
|
[ 93.837644] debug_print_object+0x13c/0x1b0
|
|
[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0
|
|
[ 93.846987] debug_check_no_obj_freed+0x18/0x20
|
|
[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4
|
|
[ 93.856346] kfree+0xfc/0x2f4
|
|
[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8
|
|
[ 93.864445] device_release+0x84/0x168
|
|
[ 93.868310] kobject_cleanup+0x12c/0x298
|
|
[ 93.872356] kobject_delayed_cleanup+0x10/0x18
|
|
[ 93.876948] process_one_work+0x578/0x92c
|
|
[ 93.881086] worker_thread+0x804/0xcf8
|
|
[ 93.884963] kthread+0x2a8/0x314
|
|
[ 93.888303] ret_from_fork+0x10/0x18
|
|
|
|
The cdev_device_add/del() API was created to address this issue (see
|
|
commit '233ed09d7fda ("chardev: add helper function to register char
|
|
devs with a struct device")'), use it instead of cdev add/del().(CVE-2022-48759)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phonet: fix rtm_phonet_notify() skb allocation
|
|
|
|
fill_route() stores three components in the skb:
|
|
|
|
- struct rtmsg
|
|
- RTA_DST (u8)
|
|
- RTA_OIF (u32)
|
|
|
|
Therefore, rtm_phonet_notify() should use
|
|
|
|
NLMSG_ALIGN(sizeof(struct rtmsg)) +
|
|
nla_total_size(1) +
|
|
nla_total_size(4)(CVE-2024-36946)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
|
|
|
|
When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
|
|
present in the list, free_irq() is called for the same vector. That
|
|
causes following splat:
|
|
|
|
[ 0.414355] Trying to free already-free IRQ 27
|
|
[ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
|
|
[ 0.414510] Modules linked in:
|
|
[ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
|
|
[ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
[ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
|
|
[ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
|
|
[ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
|
|
[ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
|
|
[ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
|
|
[ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
|
|
[ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
|
|
[ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
|
|
[ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
|
|
[ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
|
|
[ 0.414540] Call Trace:
|
|
[ 0.414540] <TASK>
|
|
[ 0.414540] ? __warn+0x80/0x120
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] ? report_bug+0x164/0x190
|
|
[ 0.414540] ? handle_bug+0x3b/0x70
|
|
[ 0.414540] ? exc_invalid_op+0x17/0x70
|
|
[ 0.414540] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] vp_del_vqs+0xc1/0x220
|
|
[ 0.414540] vp_find_vqs_msix+0x305/0x470
|
|
[ 0.414540] vp_find_vqs+0x3e/0x1a0
|
|
[ 0.414540] vp_modern_find_vqs+0x1b/0x70
|
|
[ 0.414540] init_vqs+0x387/0x600
|
|
[ 0.414540] virtnet_probe+0x50a/0xc80
|
|
[ 0.414540] virtio_dev_probe+0x1e0/0x2b0
|
|
[ 0.414540] really_probe+0xc0/0x2c0
|
|
[ 0.414540] ? __pfx___driver_attach+0x10/0x10
|
|
[ 0.414540] __driver_probe_device+0x73/0x120
|
|
[ 0.414540] driver_probe_device+0x1f/0xe0
|
|
[ 0.414540] __driver_attach+0x88/0x180
|
|
[ 0.414540] bus_for_each_dev+0x85/0xd0
|
|
[ 0.414540] bus_add_driver+0xec/0x1f0
|
|
[ 0.414540] driver_register+0x59/0x100
|
|
[ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10
|
|
[ 0.414540] virtio_net_driver_init+0x90/0xb0
|
|
[ 0.414540] do_one_initcall+0x58/0x230
|
|
[ 0.414540] kernel_init_freeable+0x1a3/0x2d0
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] kernel_init+0x1a/0x1c0
|
|
[ 0.414540] ret_from_fork+0x31/0x50
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] ret_from_fork_asm+0x1a/0x30
|
|
[ 0.414540] </TASK>
|
|
|
|
Fix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.(CVE-2024-38549)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bfa: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
|
|
userspace to that buffer. Later, we use sscanf on this buffer but we don't
|
|
ensure that the string is terminated inside the buffer, this can lead to
|
|
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
|
|
of memdup_user.(CVE-2024-38560)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
speakup: Fix sizeof() vs ARRAY_SIZE() bug
|
|
|
|
The "buf" pointer is an array of u16 values. This code should be
|
|
using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
|
|
otherwise it can the still got out of bounds.(CVE-2024-38587)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ring-buffer: Fix a race between readers and resize checks
|
|
|
|
The reader code in rb_get_reader_page() swaps a new reader page into the
|
|
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->prev might not be equal back to page for some page in the
|
|
ring buffer.
|
|
|
|
The resize operation in ring_buffer_resize() can be invoked in parallel.
|
|
It calls rb_check_pages() which can detect the described inconsistency
|
|
and stop further tracing:
|
|
|
|
[ 190.271762] ------------[ cut here ]------------
|
|
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.271789] Modules linked in: [...]
|
|
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
|
|
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
|
|
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
|
|
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.272023] Code: [...]
|
|
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
|
|
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
|
|
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
|
|
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
|
|
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
|
|
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
|
|
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
|
|
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
|
|
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 190.272077] Call Trace:
|
|
[ 190.272098] <TASK>
|
|
[ 190.272189] ring_buffer_resize+0x2ab/0x460
|
|
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
|
|
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
|
|
[ 190.272216] tracing_entries_write+0x74/0xc0
|
|
[ 190.272225] vfs_write+0xf5/0x420
|
|
[ 190.272248] ksys_write+0x67/0xe0
|
|
[ 190.272256] do_syscall_64+0x82/0x170
|
|
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[ 190.272373] RIP: 0033:0x7f1bd657d263
|
|
[ 190.272381] Code: [...]
|
|
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
|
|
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
|
|
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
|
|
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
|
|
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
|
|
[ 190.272412] </TASK>
|
|
[ 190.272414] ---[ end trace 0000000000000000 ]---
|
|
|
|
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
|
|
trace_buffer has recording disabled. Recent commit d78ab792705c
|
|
("tracing: Stop current tracer when resizing buffer") causes that it is
|
|
now always the case which makes it more likely to experience this issue.
|
|
|
|
The window to hit this race is nonetheless very small. To help
|
|
reproducing it, one can add a delay loop in rb_get_reader_page():
|
|
|
|
ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---(CVE-2024-38601)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
m68k: Fix spinlock race in kernel thread creation
|
|
|
|
Context switching does take care to retain the correct lock owner across
|
|
the switch from 'prev' to 'next' tasks. This does rely on interrupts
|
|
remaining disabled for the entire duration of the switch.
|
|
|
|
This condition is guaranteed for normal process creation and context
|
|
switching between already running processes, because both 'prev' and
|
|
'next' already have interrupts disabled in their saved copies of the
|
|
status register.
|
|
|
|
The situation is different for newly created kernel threads. The status
|
|
register is set to PS_S in copy_thread(), which does leave the IPL at 0.
|
|
Upon restoring the 'next' thread's status register in switch_to() aka
|
|
resume(), interrupts then become enabled prematurely. resume() then
|
|
returns via ret_from_kernel_thread() and schedule_tail() where run queue
|
|
lock is released (see finish_task_switch() and finish_lock_switch()).
|
|
|
|
A timer interrupt calling scheduler_tick() before the lock is released
|
|
in finish_task_switch() will find the lock already taken, with the
|
|
current task as lock owner. This causes a spinlock recursion warning as
|
|
reported by Guenter Roeck.
|
|
|
|
As far as I can ascertain, this race has been opened in commit
|
|
533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
|
|
but I haven't done a detailed study of kernel history so it may well
|
|
predate that commit.
|
|
|
|
Interrupts cannot be disabled in the saved status register copy for
|
|
kernel threads (init will complain about interrupts disabled when
|
|
finally starting user space). Disable interrupts temporarily when
|
|
switching the tasks' register sets in resume().
|
|
|
|
Note that a simple oriw 0x700,%sr after restoring sr is not enough here
|
|
- this leaves enough of a race for the 'spinlock recursion' warning to
|
|
still be observed.
|
|
|
|
Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: stk1160: fix bounds checking in stk1160_copy_video()
|
|
|
|
The subtract in this condition is reversed. The ->length is the length
|
|
of the buffer. The ->bytesused is how many bytes we have copied thus
|
|
far. When the condition is reversed that means the result of the
|
|
subtraction is always negative but since it's unsigned then the result
|
|
is a very high positive value. That means the overflow check is never
|
|
true.
|
|
|
|
Additionally, the ->bytesused doesn't actually work for this purpose
|
|
because we're not writing to "buf->mem + buf->bytesused". Instead, the
|
|
math to calculate the destination where we are writing is a bit
|
|
involved. You calculate the number of full lines already written,
|
|
multiply by two, skip a line if necessary so that we start on an odd
|
|
numbered line, and add the offset into the line.
|
|
|
|
To fix this buffer overflow, just take the actual destination where we
|
|
are writing, if the offset is already out of bounds print an error and
|
|
return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.(CVE-2024-38630)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.(CVE-2024-38661)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
um: Add winch to winch_handlers before registering winch IRQ
|
|
|
|
Registering a winch IRQ is racy, an interrupt may occur before the winch is
|
|
added to the winch_handlers list.
|
|
|
|
If that happens, register_winch_irq() adds to that list a winch that is
|
|
scheduled to be (or has already been) freed, causing a panic later in
|
|
winch_cleanup().
|
|
|
|
Avoid the race by adding the winch to the winch_handlers list before
|
|
registering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
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">Medium</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47235</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47285</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47602</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48715</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48759</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36946</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37353</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38549</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38560</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38587</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38599</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38601</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38613</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38621</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38630</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38661</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39292</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47235</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47285</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47602</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48715</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48759</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36946</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37353</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38549</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38560</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38587</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38599</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38601</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38613</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38621</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38630</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38661</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39292</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2407.1.0.0284" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.1.0.0284.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ethernet: fix potential use-after-free in ec_bhf_remove
|
|
|
|
static void ec_bhf_remove(struct pci_dev *dev)
|
|
{
|
|
...
|
|
struct ec_bhf_priv *priv = netdev_priv(net_dev);
|
|
|
|
unregister_netdev(net_dev);
|
|
free_netdev(net_dev);
|
|
|
|
pci_iounmap(dev, priv->dma_io);
|
|
pci_iounmap(dev, priv->io);
|
|
...
|
|
}
|
|
|
|
priv is netdev private data, but it is used
|
|
after free_netdev(). It can cause use-after-free when accessing priv
|
|
pointer. So, fix it by moving free_netdev() after pci_iounmap()
|
|
calls.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2021-47235</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2021-47285</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac80211: track only QoS data frames for admission control
|
|
|
|
For admission control, obviously all of that only works for
|
|
QoS data frames, otherwise we cannot even access the QoS
|
|
field in the header.
|
|
|
|
Syzbot reported (see below) an uninitialized value here due
|
|
to a status of a non-QoS nullfunc packet, which isn't even
|
|
long enough to contain the QoS header.
|
|
|
|
Fix this to only do anything for QoS data packets.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2021-47602</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
|
|
|
|
Running tests with a debug kernel shows that bnx2fc_recv_frame() is
|
|
modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot
|
|
a debug kernel and run the bnx2fc driver with the hardware enabled.
|
|
|
|
[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_
|
|
[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
|
|
[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B
|
|
[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
|
|
[ 1391.699183] Call Trace:
|
|
[ 1391.699188] dump_stack_lvl+0x57/0x7d
|
|
[ 1391.699198] check_preemption_disabled+0xc8/0xd0
|
|
[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
|
|
[ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180
|
|
[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]
|
|
[ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]
|
|
[ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]
|
|
[ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]
|
|
[ 1391.699258] kthread+0x364/0x420
|
|
[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50
|
|
[ 1391.699268] ? set_kthread_struct+0x100/0x100
|
|
[ 1391.699273] ret_from_fork+0x22/0x30
|
|
|
|
Restore the old get_cpu/put_cpu code with some modifications to reduce the
|
|
size of the critical section.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2022-48715</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.6</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev
|
|
|
|
struct rpmsg_ctrldev contains a struct cdev. The current code frees
|
|
the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the
|
|
cdev is a managed object, therefore its release is not predictable
|
|
and the rpmsg_ctrldev could be freed before the cdev is entirely
|
|
released, as in the backtrace below.
|
|
|
|
[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
|
|
[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
|
|
[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
|
|
[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26
|
|
[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
|
|
[ 93.730055] Workqueue: events kobject_delayed_cleanup
|
|
[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
|
|
[ 93.740216] pc : debug_print_object+0x13c/0x1b0
|
|
[ 93.744890] lr : debug_print_object+0x13c/0x1b0
|
|
[ 93.749555] sp : ffffffacf5bc7940
|
|
[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
|
|
[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
|
|
[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
|
|
[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
|
|
[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
|
|
[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0
|
|
[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000
|
|
[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
|
|
[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
|
|
[ 93.802244] x11: 0000000000000001 x10: 0000000000000000
|
|
[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
|
|
[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000
|
|
[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000
|
|
[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
|
|
[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
|
|
[ 93.835104] Call trace:
|
|
[ 93.837644] debug_print_object+0x13c/0x1b0
|
|
[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0
|
|
[ 93.846987] debug_check_no_obj_freed+0x18/0x20
|
|
[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4
|
|
[ 93.856346] kfree+0xfc/0x2f4
|
|
[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8
|
|
[ 93.864445] device_release+0x84/0x168
|
|
[ 93.868310] kobject_cleanup+0x12c/0x298
|
|
[ 93.872356] kobject_delayed_cleanup+0x10/0x18
|
|
[ 93.876948] process_one_work+0x578/0x92c
|
|
[ 93.881086] worker_thread+0x804/0xcf8
|
|
[ 93.884963] kthread+0x2a8/0x314
|
|
[ 93.888303] ret_from_fork+0x10/0x18
|
|
|
|
The cdev_device_add/del() API was created to address this issue (see
|
|
commit '233ed09d7fda ("chardev: add helper function to register char
|
|
devs with a struct device")'), use it instead of cdev add/del().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2022-48759</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phonet: fix rtm_phonet_notify() skb allocation
|
|
|
|
fill_route() stores three components in the skb:
|
|
|
|
- struct rtmsg
|
|
- RTA_DST (u8)
|
|
- RTA_OIF (u32)
|
|
|
|
Therefore, rtm_phonet_notify() should use
|
|
|
|
NLMSG_ALIGN(sizeof(struct rtmsg)) +
|
|
nla_total_size(1) +
|
|
nla_total_size(4)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-36946</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
|
|
|
|
When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
|
|
present in the list, free_irq() is called for the same vector. That
|
|
causes following splat:
|
|
|
|
[ 0.414355] Trying to free already-free IRQ 27
|
|
[ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
|
|
[ 0.414510] Modules linked in:
|
|
[ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
|
|
[ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
[ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
|
|
[ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
|
|
[ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
|
|
[ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
|
|
[ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
|
|
[ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
|
|
[ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
|
|
[ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
|
|
[ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
|
|
[ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
|
|
[ 0.414540] Call Trace:
|
|
[ 0.414540] <TASK>
|
|
[ 0.414540] ? __warn+0x80/0x120
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] ? report_bug+0x164/0x190
|
|
[ 0.414540] ? handle_bug+0x3b/0x70
|
|
[ 0.414540] ? exc_invalid_op+0x17/0x70
|
|
[ 0.414540] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 0.414540] ? free_irq+0x1a1/0x2d0
|
|
[ 0.414540] vp_del_vqs+0xc1/0x220
|
|
[ 0.414540] vp_find_vqs_msix+0x305/0x470
|
|
[ 0.414540] vp_find_vqs+0x3e/0x1a0
|
|
[ 0.414540] vp_modern_find_vqs+0x1b/0x70
|
|
[ 0.414540] init_vqs+0x387/0x600
|
|
[ 0.414540] virtnet_probe+0x50a/0xc80
|
|
[ 0.414540] virtio_dev_probe+0x1e0/0x2b0
|
|
[ 0.414540] really_probe+0xc0/0x2c0
|
|
[ 0.414540] ? __pfx___driver_attach+0x10/0x10
|
|
[ 0.414540] __driver_probe_device+0x73/0x120
|
|
[ 0.414540] driver_probe_device+0x1f/0xe0
|
|
[ 0.414540] __driver_attach+0x88/0x180
|
|
[ 0.414540] bus_for_each_dev+0x85/0xd0
|
|
[ 0.414540] bus_add_driver+0xec/0x1f0
|
|
[ 0.414540] driver_register+0x59/0x100
|
|
[ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10
|
|
[ 0.414540] virtio_net_driver_init+0x90/0xb0
|
|
[ 0.414540] do_one_initcall+0x58/0x230
|
|
[ 0.414540] kernel_init_freeable+0x1a3/0x2d0
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] kernel_init+0x1a/0x1c0
|
|
[ 0.414540] ret_from_fork+0x31/0x50
|
|
[ 0.414540] ? __pfx_kernel_init+0x10/0x10
|
|
[ 0.414540] ret_from_fork_asm+0x1a/0x30
|
|
[ 0.414540] </TASK>
|
|
|
|
Fix this by calling deleting the current vq when request_irq() fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-37353</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38549</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bfa: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
|
|
userspace to that buffer. Later, we use sscanf on this buffer but we don't
|
|
ensure that the string is terminated inside the buffer, this can lead to
|
|
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
|
|
of memdup_user.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38560</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
speakup: Fix sizeof() vs ARRAY_SIZE() bug
|
|
|
|
The "buf" pointer is an array of u16 values. This code should be
|
|
using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
|
|
otherwise it can the still got out of bounds.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38587</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jffs2: prevent xattr node from overflowing the eraseblock
|
|
|
|
Add a check to make sure that the requested xattr node size is no larger
|
|
than the eraseblock minus the cleanmarker.
|
|
|
|
Unlike the usual inode nodes, the xattr nodes aren't split into parts
|
|
and spread across multiple eraseblocks, which means that a xattr node
|
|
must not occupy more than one eraseblock. If the requested xattr value is
|
|
too large, the xattr node can spill onto the next eraseblock, overwriting
|
|
the nodes and causing errors such as:
|
|
|
|
jffs2: argh. node added in wrong place at 0x0000b050(2)
|
|
jffs2: nextblock 0x0000a000, expected at 0000b00c
|
|
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
|
|
read=0xfc892c93, calc=0x000000
|
|
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
|
|
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
|
|
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
|
|
end of the erase block
|
|
jffs2: Perhaps the file system was created with the wrong erase size?
|
|
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
|
|
at 0x00000010: 0x1044 instead
|
|
|
|
This breaks the filesystem and can lead to KASAN crashes such as:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
|
|
Read of size 4 at addr ffff88802c31e914 by task repro/830
|
|
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS Arch Linux 1.16.3-1-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xc4/0x620
|
|
? __virt_addr_valid+0x308/0x5b0
|
|
kasan_report+0xc1/0xf0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
? jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_sum_add_kvec+0x125e/0x15d0
|
|
jffs2_flash_direct_writev+0xa8/0xd0
|
|
jffs2_flash_writev+0x9c9/0xef0
|
|
? __x64_sys_setxattr+0xc4/0x160
|
|
? do_syscall_64+0x69/0x140
|
|
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[...]
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38599</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ring-buffer: Fix a race between readers and resize checks
|
|
|
|
The reader code in rb_get_reader_page() swaps a new reader page into the
|
|
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->prev might not be equal back to page for some page in the
|
|
ring buffer.
|
|
|
|
The resize operation in ring_buffer_resize() can be invoked in parallel.
|
|
It calls rb_check_pages() which can detect the described inconsistency
|
|
and stop further tracing:
|
|
|
|
[ 190.271762] ------------[ cut here ]------------
|
|
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.271789] Modules linked in: [...]
|
|
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
|
|
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
|
|
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
|
|
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
|
|
[ 190.272023] Code: [...]
|
|
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
|
|
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
|
|
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
|
|
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
|
|
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
|
|
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
|
|
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
|
|
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
|
|
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 190.272077] Call Trace:
|
|
[ 190.272098] <TASK>
|
|
[ 190.272189] ring_buffer_resize+0x2ab/0x460
|
|
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
|
|
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
|
|
[ 190.272216] tracing_entries_write+0x74/0xc0
|
|
[ 190.272225] vfs_write+0xf5/0x420
|
|
[ 190.272248] ksys_write+0x67/0xe0
|
|
[ 190.272256] do_syscall_64+0x82/0x170
|
|
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
[ 190.272373] RIP: 0033:0x7f1bd657d263
|
|
[ 190.272381] Code: [...]
|
|
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
|
|
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
|
|
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
|
|
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
|
|
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
|
|
[ 190.272412] </TASK>
|
|
[ 190.272414] ---[ end trace 0000000000000000 ]---
|
|
|
|
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
|
|
trace_buffer has recording disabled. Recent commit d78ab792705c
|
|
("tracing: Stop current tracer when resizing buffer") causes that it is
|
|
now always the case which makes it more likely to experience this issue.
|
|
|
|
The window to hit this race is nonetheless very small. To help
|
|
reproducing it, one can add a delay loop in rb_get_reader_page():
|
|
|
|
ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38601</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
m68k: Fix spinlock race in kernel thread creation
|
|
|
|
Context switching does take care to retain the correct lock owner across
|
|
the switch from 'prev' to 'next' tasks. This does rely on interrupts
|
|
remaining disabled for the entire duration of the switch.
|
|
|
|
This condition is guaranteed for normal process creation and context
|
|
switching between already running processes, because both 'prev' and
|
|
'next' already have interrupts disabled in their saved copies of the
|
|
status register.
|
|
|
|
The situation is different for newly created kernel threads. The status
|
|
register is set to PS_S in copy_thread(), which does leave the IPL at 0.
|
|
Upon restoring the 'next' thread's status register in switch_to() aka
|
|
resume(), interrupts then become enabled prematurely. resume() then
|
|
returns via ret_from_kernel_thread() and schedule_tail() where run queue
|
|
lock is released (see finish_task_switch() and finish_lock_switch()).
|
|
|
|
A timer interrupt calling scheduler_tick() before the lock is released
|
|
in finish_task_switch() will find the lock already taken, with the
|
|
current task as lock owner. This causes a spinlock recursion warning as
|
|
reported by Guenter Roeck.
|
|
|
|
As far as I can ascertain, this race has been opened in commit
|
|
533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
|
|
but I haven't done a detailed study of kernel history so it may well
|
|
predate that commit.
|
|
|
|
Interrupts cannot be disabled in the saved status register copy for
|
|
kernel threads (init will complain about interrupts disabled when
|
|
finally starting user space). Disable interrupts temporarily when
|
|
switching the tasks' register sets in resume().
|
|
|
|
Note that a simple oriw 0x700,%sr after restoring sr is not enough here
|
|
- this leaves enough of a race for the 'spinlock recursion' warning to
|
|
still be observed.
|
|
|
|
Tested on ARAnyM and qemu (Quadra 800 emulation).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38613</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: stk1160: fix bounds checking in stk1160_copy_video()
|
|
|
|
The subtract in this condition is reversed. The ->length is the length
|
|
of the buffer. The ->bytesused is how many bytes we have copied thus
|
|
far. When the condition is reversed that means the result of the
|
|
subtraction is always negative but since it's unsigned then the result
|
|
is a very high positive value. That means the overflow check is never
|
|
true.
|
|
|
|
Additionally, the ->bytesused doesn't actually work for this purpose
|
|
because we're not writing to "buf->mem + buf->bytesused". Instead, the
|
|
math to calculate the destination where we are writing is a bit
|
|
involved. You calculate the number of full lines already written,
|
|
multiply by two, skip a line if necessary so that we start on an odd
|
|
numbered line, and add the offset into the line.
|
|
|
|
To fix this buffer overflow, just take the actual destination where we
|
|
are writing, if the offset is already out of bounds print an error and
|
|
return. Otherwise, write up to buf->length bytes.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38621</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
|
|
|
|
When the cpu5wdt module is removing, the origin code uses del_timer() to
|
|
de-activate the timer. If the timer handler is running, del_timer() could
|
|
not stop it and will return directly. If the port region is released by
|
|
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
|
|
to write into the region that is released, the use-after-free bug will
|
|
happen.
|
|
|
|
Change del_timer() to timer_shutdown_sync() in order that the timer handler
|
|
could be finished before the port region is released.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38630</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-38661</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
um: Add winch to winch_handlers before registering winch IRQ
|
|
|
|
Registering a winch IRQ is racy, an interrupt may occur before the winch is
|
|
added to the winch_handlers list.
|
|
|
|
If that happens, register_winch_irq() adds to that list a winch that is
|
|
scheduled to be (or has already been) freed, causing a panic later in
|
|
winch_cleanup().
|
|
|
|
Avoid the race by adding the winch to the winch_handlers list before
|
|
registering the IRQ, and rolling back if um_request_irq() fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-39292</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |