1679 lines
73 KiB
XML
1679 lines
73 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-1346</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-03-29</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-03-29</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-03-29</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-03-29</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:
|
|
|
|
i2c: xiic: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in xiic_xfer and xiic_i2c_remove.
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.(CVE-2020-36778)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in lpi2c_imx_master_enable.
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.(CVE-2020-36782)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: usbhid: fix info leak in hid_submit_ctrl
|
|
|
|
In hid_submit_ctrl(), the way of calculating the report length doesn't
|
|
take into account that report->size can be zero. When running the
|
|
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
|
|
calculate transfer_buffer_length as 16384. When this urb is passed to
|
|
the usb core layer, KMSAN reports an info leak of 16384 bytes.
|
|
|
|
To fix this, first modify hid_report_len() to account for the zero
|
|
report size case by using DIV_ROUND_UP for the division. Then, call it
|
|
from hid_submit_ctrl().(CVE-2021-46906)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ARM: footbridge: fix PCI interrupt mapping
|
|
|
|
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
|
|
pci_device_probe()"), the PCI code will call the IRQ mapping function
|
|
whenever a PCI driver is probed. If these are marked as __init, this
|
|
causes an oops if a PCI driver is loaded or bound after the kernel has
|
|
initialised.(CVE-2021-46909)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: dwc3: core: Do core softreset when switch mode
|
|
|
|
|
|
According to the programming guide, to switch mode for DRD controller,
|
|
the driver needs to do the following.
|
|
|
|
To switch from device to host:
|
|
1. Reset controller with GCTL.CoreSoftReset
|
|
2. Set GCTL.PrtCapDir(host mode)
|
|
3. Reset the host with USBCMD.HCRESET
|
|
4. Then follow up with the initializing host registers sequence
|
|
|
|
To switch from host to device:
|
|
1. Reset controller with GCTL.CoreSoftReset
|
|
2. Set GCTL.PrtCapDir(device mode)
|
|
3. Reset the device with DCTL.CSftRst
|
|
4. Then follow up with the initializing registers sequence
|
|
|
|
Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
|
|
switching from host to device. John Stult reported a lockup issue seen
|
|
with HiKey960 platform without these steps[1]. Similar issue is observed
|
|
with Ferry's testing platform[2].
|
|
|
|
So, apply the required steps along with some fixes to Yu Chen's and John
|
|
Stultz's version. The main fixes to their versions are the missing wait
|
|
for clocks synchronization before clearing GCTL.CoreSoftReset and only
|
|
apply DCTL.CSftRst when switching from host to device.
|
|
|
|
[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
|
|
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/(CVE-2021-46941)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
openvswitch: fix stack OOB read while fragmenting IPv4 packets
|
|
|
|
running openvswitch on kernels built with KASAN, it's possible to see the
|
|
following splat while testing fragmentation of IPv4 packets:
|
|
|
|
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
|
|
Read of size 1 at addr ffff888112fc713c by task handler2/1367
|
|
|
|
CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418
|
|
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
|
|
Call Trace:
|
|
dump_stack+0x92/0xc1
|
|
print_address_description.constprop.7+0x1a/0x150
|
|
kasan_report.cold.13+0x7f/0x111
|
|
ip_do_fragment+0x1b03/0x1f60
|
|
ovs_fragment+0x5bf/0x840 [openvswitch]
|
|
do_execute_actions+0x1bd5/0x2400 [openvswitch]
|
|
ovs_execute_actions+0xc8/0x3d0 [openvswitch]
|
|
ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]
|
|
genl_family_rcv_msg_doit.isra.15+0x227/0x2d0
|
|
genl_rcv_msg+0x287/0x490
|
|
netlink_rcv_skb+0x120/0x380
|
|
genl_rcv+0x24/0x40
|
|
netlink_unicast+0x439/0x630
|
|
netlink_sendmsg+0x719/0xbf0
|
|
sock_sendmsg+0xe2/0x110
|
|
____sys_sendmsg+0x5ba/0x890
|
|
___sys_sendmsg+0xe9/0x160
|
|
__sys_sendmsg+0xd3/0x170
|
|
do_syscall_64+0x33/0x40
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f957079db07
|
|
Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48
|
|
RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07
|
|
RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019
|
|
RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730
|
|
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
|
|
R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0
|
|
|
|
The buggy address belongs to the page:
|
|
page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7
|
|
flags: 0x17ffffc0000000()
|
|
raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
|
|
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:
|
|
ovs_fragment+0x0/0x840 [openvswitch]
|
|
|
|
this frame has 2 objects:
|
|
[32, 144) 'ovs_dst'
|
|
[192, 424) 'ovs_rt'
|
|
|
|
Memory state around the buggy address:
|
|
ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00
|
|
>ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
|
|
^
|
|
ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00
|
|
|
|
for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,
|
|
in the following call graph:
|
|
|
|
ip_do_fragment()
|
|
ip_skb_dst_mtu()
|
|
ip_dst_mtu_maybe_forward()
|
|
ip_mtu_locked()
|
|
|
|
the pointer to struct dst_entry is used as pointer to struct rtable: this
|
|
turns the access to struct members like rt_mtu_locked into an OOB read in
|
|
the stack. Fix this changing the temporary variable used for IPv4 packets
|
|
in ovs_fragment(), similarly to what is done for IPv6 few lines below.(CVE-2021-46955)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ethernet:enic: Fix a use after free bug in enic_hard_start_xmit
|
|
|
|
In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
|
|
enic_queue_wq_skb, if some error happens, the skb will be freed
|
|
by dev_kfree_skb(skb). But the freed skb is still used in
|
|
skb_tx_timestamp(skb).
|
|
|
|
My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
|
|
incase of error. The solution is provided by Govind.
|
|
See https://lkml.org/lkml/2021/4/30/961.(CVE-2021-46998)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook
|
|
|
|
The commit 1879445dfa7b ("perf/core: Set event's default
|
|
::overflow_handler()") set a default event->overflow_handler in
|
|
perf_event_alloc(), and replace the check event->overflow_handler with
|
|
is_default_overflow_handler(), but one is missing.
|
|
|
|
Currently, the bp->overflow_handler can not be NULL. As a result,
|
|
enable_single_step() is always not invoked.
|
|
|
|
Comments from Zhen Lei:
|
|
|
|
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/(CVE-2021-47006)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
|
|
|
|
In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
|
|
If some error happens in emac_tx_fill_tpd(), the skb will be freed via
|
|
dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
|
|
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).
|
|
|
|
As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,
|
|
thus my patch assigns skb->len to 'len' before the possible free and
|
|
use 'len' instead of skb->len later.(CVE-2021-47013)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnxt_en: Fix RX consumer index logic in the error path.
|
|
|
|
In bnxt_rx_pkt(), the RX buffers are expected to complete in order.
|
|
If the RX consumer index indicates an out of order buffer completion,
|
|
it means we are hitting a hardware bug and the driver will abort all
|
|
remaining RX packets and reset the RX ring. The RX consumer index
|
|
that we pass to bnxt_discard_rx() is not correct. We should be
|
|
passing the current index (tmp_raw_cons) instead of the old index
|
|
(raw_cons). This bug can cause us to be at the wrong index when
|
|
trying to abort the next RX packet. It can crash like this:
|
|
|
|
#0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
|
|
#1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
|
|
#2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
|
|
#3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
|
|
#4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0
|
|
#5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e
|
|
#6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
|
|
#7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e
|
|
#8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12
|
|
#9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
|
|
[exception RIP: bnxt_rx_pkt+237]
|
|
RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213
|
|
RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000
|
|
RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000
|
|
RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d
|
|
R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0
|
|
R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000
|
|
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018(CVE-2021-47015)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vsock/virtio: free queued packets when closing socket
|
|
|
|
As reported by syzbot [1], there is a memory leak while closing the
|
|
socket. We partially solved this issue with commit ac03046ece2b
|
|
("vsock/virtio: free packets during the socket release"), but we
|
|
forgot to drain the RX queue when the socket is definitely closed by
|
|
the scheduled work.
|
|
|
|
To avoid future issues, let's use the new virtio_transport_remove_sock()
|
|
to drain the RX queue before removing the socket from the af_vsock lists
|
|
calling vsock_remove_sock().
|
|
|
|
[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9(CVE-2021-47024)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: fix overflows checks in provide buffers
|
|
|
|
Colin reported before possible overflow and sign extension problems in
|
|
io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing
|
|
useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension").
|
|
|
|
Do that with help of check_<op>_overflow helpers. And fix struct
|
|
io_provide_buf::len type, as it doesn't make much sense to keep it
|
|
signed.(CVE-2021-47040)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Drivers: hv: vmbus: Use after free in __vmbus_open()
|
|
|
|
The "open_info" variable is added to the &vmbus_connection.chn_msg_list,
|
|
but the error handling frees "open_info" without removing it from the
|
|
list. This will result in a use after free. First remove it from the
|
|
list, and then free it.(CVE-2021-47049)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phonet/pep: refuse to enable an unbound pipe
|
|
|
|
This ioctl() implicitly assumed that the socket was already bound to
|
|
a valid local socket name, i.e. Phonet object. If the socket was not
|
|
bound, two separate problems would occur:
|
|
|
|
1) We'd send an pipe enablement request with an invalid source object.
|
|
2) Later socket calls could BUG on the socket unexpectedly being
|
|
connected yet not bound to a valid object.(CVE-2021-47086)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: add check that partition length needs to be aligned with block size
|
|
|
|
Before calling add partition or resize partition, there is no check
|
|
on whether the length is aligned with the logical block size.
|
|
If the logical block size of the disk is larger than 512 bytes,
|
|
then the partition size maybe not the multiple of the logical block size,
|
|
and when the last sector is read, bio_truncate() will adjust the bio size,
|
|
resulting in an IO error if the size of the read command is smaller than
|
|
the logical block size.If integrity data is supported, this will also
|
|
result in a null pointer dereference when calling bio_integrity_free.(CVE-2023-52458)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
|
|
|
|
syzbot reported the following uninit-value access issue:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
|
|
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
__dump_stack lib/dump_stack.c:77 [inline]
|
|
dump_stack+0x21c/0x280 lib/dump_stack.c:118
|
|
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
|
|
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
|
|
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
|
|
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
|
|
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
|
|
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
|
|
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
|
|
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
|
|
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
|
|
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
|
|
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
|
|
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
|
|
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
|
|
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
|
|
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
|
|
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
|
|
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
|
|
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
|
|
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
|
|
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
|
|
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
|
|
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
|
|
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
|
|
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
|
|
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
|
|
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
|
|
port_event drivers/usb/core/hub.c:5494 [inline]
|
|
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
|
|
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
|
|
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
|
|
kthread+0x551/0x590 kernel/kthread.c:292
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
|
|
|
|
Local variable ----buf.i87@smsc75xx_bind created at:
|
|
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
|
|
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
|
|
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
|
|
This issue is caused because usbnet_read_cmd() reads less bytes than requested
|
|
(zero byte in the reproducer). In this case, 'buf' is not properly filled.
|
|
|
|
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
|
|
less bytes than requested.(CVE-2023-52528)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix slab-out-of-bounds Read in dtSearch
|
|
|
|
Currently while searching for current page in the sorted entry table
|
|
of the page there is a out of bound access. Added a bound check to fix
|
|
the error.
|
|
|
|
Dave:
|
|
Set return code to -EIO(CVE-2023-52602)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
UBSAN: array-index-out-of-bounds in dtSplitRoot
|
|
|
|
Syzkaller reported the following issue:
|
|
|
|
oop0: detected capacity change from 0 to 32768
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
|
|
index -2 is out of range for type 'struct dtslot [128]'
|
|
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:151 [inline]
|
|
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
|
|
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
|
|
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
|
|
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
|
|
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
|
|
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
|
|
do_mkdirat+0x279/0x550 fs/namei.c:4038
|
|
__do_sys_mkdirat fs/namei.c:4053 [inline]
|
|
__se_sys_mkdirat fs/namei.c:4051 [inline]
|
|
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
RIP: 0033:0x7fcdc0113fd9
|
|
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
|
|
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
|
|
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
|
|
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
|
|
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
|
|
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
The issue is caused when the value of fsi becomes less than -1.
|
|
The check to break the loop when fsi value becomes -1 is present
|
|
but syzbot was able to produce value less than -1 which cause the error.
|
|
This patch simply add the change for the values less than 0.
|
|
|
|
The patch is tested via syzbot.(CVE-2023-52603)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
|
|
|
|
Syzkaller reported the following issue:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
|
|
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
|
|
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:217 [inline]
|
|
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
|
|
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
|
|
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
|
|
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
|
|
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
|
|
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
|
|
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
|
|
txUpdateMap+0x342/0x9e0
|
|
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
|
|
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
|
|
kthread+0x2d3/0x370 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
</TASK>
|
|
================================================================================
|
|
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
|
|
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
panic+0x30f/0x770 kernel/panic.c:340
|
|
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
|
|
ubsan_epilogue lib/ubsan.c:223 [inline]
|
|
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
|
|
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
|
|
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
|
|
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
|
|
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
|
|
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
|
|
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
|
|
txUpdateMap+0x342/0x9e0
|
|
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
|
|
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
|
|
kthread+0x2d3/0x370 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
</TASK>
|
|
Kernel Offset: disabled
|
|
Rebooting in 86400 seconds..
|
|
|
|
The issue is caused when the value of lp becomes greater than
|
|
CTLTREESIZE which is the max size of stree. Adding a simple check
|
|
solves this issue.
|
|
|
|
Dave:
|
|
As the function returns a void, good error handling
|
|
would require a more intrusive code reorganization, so I modified
|
|
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
|
|
|
|
The patch is tested via syzbot.(CVE-2023-52604)
|
|
|
|
A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
(CVE-2024-24855)</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">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-1346</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2020-36778</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2020-36782</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46906</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46909</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46941</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46955</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46998</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47006</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47013</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47015</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47024</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47040</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47049</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47086</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52458</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52528</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52602</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52603</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52604</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24855</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2020-36778</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2020-36782</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46906</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46909</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46941</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46955</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46998</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47006</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47013</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47015</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47024</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47040</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47049</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47086</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52458</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52528</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52602</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52603</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52604</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24855</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="kernel-tools-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2403.4.0.0271.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2403.4.0.0271.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2403.4.0.0271.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2403.4.0.0271" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2403.4.0.0271.oe2003sp4.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:
|
|
|
|
i2c: xiic: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in xiic_xfer and xiic_i2c_remove.
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2020-36778</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in lpi2c_imx_master_enable.
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2020-36782</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.5</BaseScore>
|
|
<Vector>AV:A/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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
HID: usbhid: fix info leak in hid_submit_ctrl
|
|
|
|
In hid_submit_ctrl(), the way of calculating the report length doesn't
|
|
take into account that report->size can be zero. When running the
|
|
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
|
|
calculate transfer_buffer_length as 16384. When this urb is passed to
|
|
the usb core layer, KMSAN reports an info leak of 16384 bytes.
|
|
|
|
To fix this, first modify hid_report_len() to account for the zero
|
|
report size case by using DIV_ROUND_UP for the division. Then, call it
|
|
from hid_submit_ctrl().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-46906</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
ARM: footbridge: fix PCI interrupt mapping
|
|
|
|
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
|
|
pci_device_probe()"), the PCI code will call the IRQ mapping function
|
|
whenever a PCI driver is probed. If these are marked as __init, this
|
|
causes an oops if a PCI driver is loaded or bound after the kernel has
|
|
initialised.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-46909</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
usb: dwc3: core: Do core softreset when switch mode
|
|
|
|
|
|
According to the programming guide, to switch mode for DRD controller,
|
|
the driver needs to do the following.
|
|
|
|
To switch from device to host:
|
|
1. Reset controller with GCTL.CoreSoftReset
|
|
2. Set GCTL.PrtCapDir(host mode)
|
|
3. Reset the host with USBCMD.HCRESET
|
|
4. Then follow up with the initializing host registers sequence
|
|
|
|
To switch from host to device:
|
|
1. Reset controller with GCTL.CoreSoftReset
|
|
2. Set GCTL.PrtCapDir(device mode)
|
|
3. Reset the device with DCTL.CSftRst
|
|
4. Then follow up with the initializing registers sequence
|
|
|
|
Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
|
|
switching from host to device. John Stult reported a lockup issue seen
|
|
with HiKey960 platform without these steps[1]. Similar issue is observed
|
|
with Ferry's testing platform[2].
|
|
|
|
So, apply the required steps along with some fixes to Yu Chen's and John
|
|
Stultz's version. The main fixes to their versions are the missing wait
|
|
for clocks synchronization before clearing GCTL.CoreSoftReset and only
|
|
apply DCTL.CSftRst when switching from host to device.
|
|
|
|
[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
|
|
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-46941</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
openvswitch: fix stack OOB read while fragmenting IPv4 packets
|
|
|
|
running openvswitch on kernels built with KASAN, it's possible to see the
|
|
following splat while testing fragmentation of IPv4 packets:
|
|
|
|
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
|
|
Read of size 1 at addr ffff888112fc713c by task handler2/1367
|
|
|
|
CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418
|
|
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
|
|
Call Trace:
|
|
dump_stack+0x92/0xc1
|
|
print_address_description.constprop.7+0x1a/0x150
|
|
kasan_report.cold.13+0x7f/0x111
|
|
ip_do_fragment+0x1b03/0x1f60
|
|
ovs_fragment+0x5bf/0x840 [openvswitch]
|
|
do_execute_actions+0x1bd5/0x2400 [openvswitch]
|
|
ovs_execute_actions+0xc8/0x3d0 [openvswitch]
|
|
ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]
|
|
genl_family_rcv_msg_doit.isra.15+0x227/0x2d0
|
|
genl_rcv_msg+0x287/0x490
|
|
netlink_rcv_skb+0x120/0x380
|
|
genl_rcv+0x24/0x40
|
|
netlink_unicast+0x439/0x630
|
|
netlink_sendmsg+0x719/0xbf0
|
|
sock_sendmsg+0xe2/0x110
|
|
____sys_sendmsg+0x5ba/0x890
|
|
___sys_sendmsg+0xe9/0x160
|
|
__sys_sendmsg+0xd3/0x170
|
|
do_syscall_64+0x33/0x40
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f957079db07
|
|
Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48
|
|
RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07
|
|
RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019
|
|
RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730
|
|
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
|
|
R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0
|
|
|
|
The buggy address belongs to the page:
|
|
page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7
|
|
flags: 0x17ffffc0000000()
|
|
raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
|
|
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:
|
|
ovs_fragment+0x0/0x840 [openvswitch]
|
|
|
|
this frame has 2 objects:
|
|
[32, 144) 'ovs_dst'
|
|
[192, 424) 'ovs_rt'
|
|
|
|
Memory state around the buggy address:
|
|
ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00
|
|
>ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
|
|
^
|
|
ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00
|
|
|
|
for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,
|
|
in the following call graph:
|
|
|
|
ip_do_fragment()
|
|
ip_skb_dst_mtu()
|
|
ip_dst_mtu_maybe_forward()
|
|
ip_mtu_locked()
|
|
|
|
the pointer to struct dst_entry is used as pointer to struct rtable: this
|
|
turns the access to struct members like rt_mtu_locked into an OOB read in
|
|
the stack. Fix this changing the temporary variable used for IPv4 packets
|
|
in ovs_fragment(), similarly to what is done for IPv6 few lines below.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-46955</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>2.6</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
ethernet:enic: Fix a use after free bug in enic_hard_start_xmit
|
|
|
|
In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
|
|
enic_queue_wq_skb, if some error happens, the skb will be freed
|
|
by dev_kfree_skb(skb). But the freed skb is still used in
|
|
skb_tx_timestamp(skb).
|
|
|
|
My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
|
|
incase of error. The solution is provided by Govind.
|
|
See https://lkml.org/lkml/2021/4/30/961.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-46998</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook
|
|
|
|
The commit 1879445dfa7b ("perf/core: Set event's default
|
|
::overflow_handler()") set a default event->overflow_handler in
|
|
perf_event_alloc(), and replace the check event->overflow_handler with
|
|
is_default_overflow_handler(), but one is missing.
|
|
|
|
Currently, the bp->overflow_handler can not be NULL. As a result,
|
|
enable_single_step() is always not invoked.
|
|
|
|
Comments from Zhen Lei:
|
|
|
|
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47006</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
|
|
|
|
In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
|
|
If some error happens in emac_tx_fill_tpd(), the skb will be freed via
|
|
dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
|
|
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).
|
|
|
|
As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,
|
|
thus my patch assigns skb->len to 'len' before the possible free and
|
|
use 'len' instead of skb->len later.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47013</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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
bnxt_en: Fix RX consumer index logic in the error path.
|
|
|
|
In bnxt_rx_pkt(), the RX buffers are expected to complete in order.
|
|
If the RX consumer index indicates an out of order buffer completion,
|
|
it means we are hitting a hardware bug and the driver will abort all
|
|
remaining RX packets and reset the RX ring. The RX consumer index
|
|
that we pass to bnxt_discard_rx() is not correct. We should be
|
|
passing the current index (tmp_raw_cons) instead of the old index
|
|
(raw_cons). This bug can cause us to be at the wrong index when
|
|
trying to abort the next RX packet. It can crash like this:
|
|
|
|
#0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
|
|
#1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
|
|
#2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
|
|
#3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
|
|
#4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0
|
|
#5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e
|
|
#6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
|
|
#7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e
|
|
#8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12
|
|
#9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
|
|
[exception RIP: bnxt_rx_pkt+237]
|
|
RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213
|
|
RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000
|
|
RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000
|
|
RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d
|
|
R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0
|
|
R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000
|
|
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47015</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.0</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
vsock/virtio: free queued packets when closing socket
|
|
|
|
As reported by syzbot [1], there is a memory leak while closing the
|
|
socket. We partially solved this issue with commit ac03046ece2b
|
|
("vsock/virtio: free packets during the socket release"), but we
|
|
forgot to drain the RX queue when the socket is definitely closed by
|
|
the scheduled work.
|
|
|
|
To avoid future issues, let's use the new virtio_transport_remove_sock()
|
|
to drain the RX queue before removing the socket from the af_vsock lists
|
|
calling vsock_remove_sock().
|
|
|
|
[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47024</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: fix overflows checks in provide buffers
|
|
|
|
Colin reported before possible overflow and sign extension problems in
|
|
io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing
|
|
useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension").
|
|
|
|
Do that with help of check_<op>_overflow helpers. And fix struct
|
|
io_provide_buf::len type, as it doesn't make much sense to keep it
|
|
signed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47040</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:A/AC:L/PR:L/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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
Drivers: hv: vmbus: Use after free in __vmbus_open()
|
|
|
|
The "open_info" variable is added to the &vmbus_connection.chn_msg_list,
|
|
but the error handling frees "open_info" without removing it from the
|
|
list. This will result in a use after free. First remove it from the
|
|
list, and then free it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47049</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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
phonet/pep: refuse to enable an unbound pipe
|
|
|
|
This ioctl() implicitly assumed that the socket was already bound to
|
|
a valid local socket name, i.e. Phonet object. If the socket was not
|
|
bound, two separate problems would occur:
|
|
|
|
1) We'd send an pipe enablement request with an invalid source object.
|
|
2) Later socket calls could BUG on the socket unexpectedly being
|
|
connected yet not bound to a valid object.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2021-47086</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>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
block: add check that partition length needs to be aligned with block size
|
|
|
|
Before calling add partition or resize partition, there is no check
|
|
on whether the length is aligned with the logical block size.
|
|
If the logical block size of the disk is larger than 512 bytes,
|
|
then the partition size maybe not the multiple of the logical block size,
|
|
and when the last sector is read, bio_truncate() will adjust the bio size,
|
|
resulting in an IO error if the size of the read command is smaller than
|
|
the logical block size.If integrity data is supported, this will also
|
|
result in a null pointer dereference when calling bio_integrity_free.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2023-52458</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.2</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
|
|
|
|
syzbot reported the following uninit-value access issue:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
|
|
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
__dump_stack lib/dump_stack.c:77 [inline]
|
|
dump_stack+0x21c/0x280 lib/dump_stack.c:118
|
|
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
|
|
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
|
|
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
|
|
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
|
|
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
|
|
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
|
|
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
|
|
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
|
|
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
|
|
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
|
|
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
|
|
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
|
|
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
|
|
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
|
|
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
|
|
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
|
|
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
|
|
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
|
|
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
|
|
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
|
|
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
|
|
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
|
|
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
|
|
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
|
|
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
|
|
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
|
|
port_event drivers/usb/core/hub.c:5494 [inline]
|
|
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
|
|
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
|
|
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
|
|
kthread+0x551/0x590 kernel/kthread.c:292
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
|
|
|
|
Local variable ----buf.i87@smsc75xx_bind created at:
|
|
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
|
|
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
|
|
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
|
|
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
|
|
|
|
This issue is caused because usbnet_read_cmd() reads less bytes than requested
|
|
(zero byte in the reproducer). In this case, 'buf' is not properly filled.
|
|
|
|
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
|
|
less bytes than requested.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2023-52528</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
jfs: fix slab-out-of-bounds Read in dtSearch
|
|
|
|
Currently while searching for current page in the sorted entry table
|
|
of the page there is a out of bound access. Added a bound check to fix
|
|
the error.
|
|
|
|
Dave:
|
|
Set return code to -EIO</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2023-52602</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
UBSAN: array-index-out-of-bounds in dtSplitRoot
|
|
|
|
Syzkaller reported the following issue:
|
|
|
|
oop0: detected capacity change from 0 to 32768
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
|
|
index -2 is out of range for type 'struct dtslot [128]'
|
|
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:151 [inline]
|
|
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
|
|
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
|
|
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
|
|
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
|
|
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
|
|
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
|
|
do_mkdirat+0x279/0x550 fs/namei.c:4038
|
|
__do_sys_mkdirat fs/namei.c:4053 [inline]
|
|
__se_sys_mkdirat fs/namei.c:4051 [inline]
|
|
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
RIP: 0033:0x7fcdc0113fd9
|
|
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
|
|
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
|
|
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
|
|
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
|
|
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
|
|
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
The issue is caused when the value of fsi becomes less than -1.
|
|
The check to break the loop when fsi value becomes -1 is present
|
|
but syzbot was able to produce value less than -1 which cause the error.
|
|
This patch simply add the change for the values less than 0.
|
|
|
|
The patch is tested via syzbot.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2023-52603</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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:
|
|
|
|
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
|
|
|
|
Syzkaller reported the following issue:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
|
|
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
|
|
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:217 [inline]
|
|
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
|
|
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
|
|
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
|
|
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
|
|
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
|
|
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
|
|
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
|
|
txUpdateMap+0x342/0x9e0
|
|
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
|
|
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
|
|
kthread+0x2d3/0x370 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
</TASK>
|
|
================================================================================
|
|
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
|
|
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
panic+0x30f/0x770 kernel/panic.c:340
|
|
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
|
|
ubsan_epilogue lib/ubsan.c:223 [inline]
|
|
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
|
|
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
|
|
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
|
|
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
|
|
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
|
|
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
|
|
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
|
|
txUpdateMap+0x342/0x9e0
|
|
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
|
|
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
|
|
kthread+0x2d3/0x370 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
</TASK>
|
|
Kernel Offset: disabled
|
|
Rebooting in 86400 seconds..
|
|
|
|
The issue is caused when the value of lp becomes greater than
|
|
CTLTREESIZE which is the max size of stree. Adding a simple check
|
|
solves this issue.
|
|
|
|
Dave:
|
|
As the function returns a void, good error handling
|
|
would require a more intrusive code reorganization, so I modified
|
|
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
|
|
|
|
The patch is tested via syzbot.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2023-52604</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</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">A race condition was found in the Linux kernel s scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-03-29</ReleaseDate>
|
|
<CVE>CVE-2024-24855</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.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-03-29</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1346</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |