3077 lines
128 KiB
XML
3077 lines
128 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-1835</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-12</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-12</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-12</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-12</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:
|
|
|
|
usb: fix various gadgets null ptr deref on 10gbps cabling.
|
|
|
|
This avoids a null pointer dereference in
|
|
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
|
|
by simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
seg6: fix the iif in the IPv6 socket control block
|
|
|
|
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving
|
|
interface index into the IPv4 socket control block (v5.16-rc4,
|
|
net/ipv4/ip_input.c line 510):
|
|
|
|
IPCB(skb)->iif = skb->skb_iif;
|
|
|
|
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH
|
|
header, the seg6_do_srh_encap(...) performs the required encapsulation.
|
|
In this case, the seg6_do_srh_encap function clears the IPv6 socket control
|
|
block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):
|
|
|
|
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
|
|
|
|
The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear
|
|
IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).
|
|
|
|
Since the IPv6 socket control block and the IPv4 socket control block share
|
|
the same memory area (skb->cb), the receiving interface index info is lost
|
|
(IP6CB(skb)->iif is set to zero).
|
|
|
|
As a side effect, that condition triggers a NULL pointer dereference if
|
|
commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig
|
|
netdev") is applied.
|
|
|
|
To fix that issue, we set the IP6CB(skb)->iif with the index of the
|
|
receiving interface once again.(CVE-2021-47515)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: mxl111sf: change mutex_init() location
|
|
|
|
Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized
|
|
mutex. The problem was in wrong mutex_init() location.
|
|
|
|
Previous mutex_init(&state->msg_lock) call was in ->init() function, but
|
|
dvb_usbv2_init() has this order of calls:
|
|
|
|
dvb_usbv2_init()
|
|
dvb_usbv2_adapter_init()
|
|
dvb_usbv2_adapter_frontend_init()
|
|
props->frontend_attach()
|
|
|
|
props->init()
|
|
|
|
Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()
|
|
internally we need to initialize state->msg_lock before
|
|
frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*
|
|
devices, which will simply initiaize mutex.(CVE-2021-47583)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac80211: validate extended element ID is present
|
|
|
|
Before attempting to parse an extended element, verify that
|
|
the extended element ID is present.(CVE-2021-47611)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Fix queues reservation for XDP
|
|
|
|
When XDP was configured on a system with large number of CPUs
|
|
and X722 NIC there was a call trace with NULL pointer dereference.
|
|
|
|
i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12
|
|
i40e 0000:87:00.0: setup of MAIN VSI failed
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
|
|
Call Trace:
|
|
? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
|
|
dev_xdp_install+0x61/0xe0
|
|
dev_xdp_attach+0x18a/0x4c0
|
|
dev_change_xdp_fd+0x1e6/0x220
|
|
do_setlink+0x616/0x1030
|
|
? ahci_port_stop+0x80/0x80
|
|
? ata_qc_issue+0x107/0x1e0
|
|
? lock_timer_base+0x61/0x80
|
|
? __mod_timer+0x202/0x380
|
|
rtnl_setlink+0xe5/0x170
|
|
? bpf_lsm_binder_transaction+0x10/0x10
|
|
? security_capable+0x36/0x50
|
|
rtnetlink_rcv_msg+0x121/0x350
|
|
? rtnl_calcit.isra.0+0x100/0x100
|
|
netlink_rcv_skb+0x50/0xf0
|
|
netlink_unicast+0x1d3/0x2a0
|
|
netlink_sendmsg+0x22a/0x440
|
|
sock_sendmsg+0x5e/0x60
|
|
__sys_sendto+0xf0/0x160
|
|
? __sys_getsockname+0x7e/0xc0
|
|
? _copy_from_user+0x3c/0x80
|
|
? __sys_setsockopt+0xc8/0x1a0
|
|
__x64_sys_sendto+0x20/0x30
|
|
do_syscall_64+0x33/0x40
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f83fa7a39e0
|
|
|
|
This was caused by PF queue pile fragmentation due to
|
|
flow director VSI queue being placed right after main VSI.
|
|
Because of this main VSI was not able to resize its
|
|
queue allocation for XDP resulting in no queues allocated
|
|
for main VSI when XDP was turned on.
|
|
|
|
Fix this by always allocating last queue in PF queue pile
|
|
for a flow director VSI.(CVE-2021-47619)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: max9759: fix underflow in speaker_gain_control_put()
|
|
|
|
Check for negative values of "priv->gain" to prevent an out of bounds
|
|
access. The concern is that these might come from the user via:
|
|
-> snd_ctl_elem_write_user()
|
|
-> snd_ctl_elem_write()
|
|
-> kctl->put()(CVE-2022-48717)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ieee802154: ca8210: Stop leaking skb's
|
|
|
|
Upon error the ieee802154_xmit_complete() helper is not called. Only
|
|
ieee802154_wake_queue() is called manually. We then leak the skb
|
|
structure.
|
|
|
|
Free the skb structure upon error before returning.(CVE-2022-48722)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-48736)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
|
|
|
|
We don't currently validate that the values being set are within the range
|
|
we advertised to userspace as being valid, do so and reject any values
|
|
that are out of range.(CVE-2022-48738)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: amd-xgbe: Fix skb data length underflow
|
|
|
|
There will be BUG_ON() triggered in include/linux/skbuff.h leading to
|
|
intermittent kernel panic, when the skb length underflow is detected.
|
|
|
|
Fix this by dropping the packet if such length underflows are seen
|
|
because of inconsistencies in the hardware descriptors.(CVE-2022-48743)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: Avoid field-overflowing memcpy()
|
|
|
|
In preparation for FORTIFY_SOURCE performing compile-time and run-time
|
|
field bounds checking for memcpy(), memmove(), and memset(), avoid
|
|
intentionally writing across neighboring fields.
|
|
|
|
Use flexible arrays instead of zero-element arrays (which look like they
|
|
are always overflowing) and split the cross-field memcpy() into two halves
|
|
that can be appropriately bounds-checked by the compiler.
|
|
|
|
We were doing:
|
|
|
|
#define ETH_HLEN 14
|
|
#define VLAN_HLEN 4
|
|
...
|
|
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
|
|
...
|
|
struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);
|
|
...
|
|
struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
|
|
struct mlx5_wqe_data_seg *dseg = wqe->data;
|
|
...
|
|
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
|
|
|
|
target is wqe->eth.inline_hdr.start (which the compiler sees as being
|
|
2 bytes in size), but copying 18, intending to write across start
|
|
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
|
|
wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
|
|
(8 bytes).
|
|
|
|
struct mlx5e_tx_wqe {
|
|
struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */
|
|
struct mlx5_wqe_eth_seg eth; /* 16 16 */
|
|
struct mlx5_wqe_data_seg data[]; /* 32 0 */
|
|
|
|
/* size: 32, cachelines: 1, members: 3 */
|
|
/* last cacheline: 32 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_eth_seg {
|
|
u8 swp_outer_l4_offset; /* 0 1 */
|
|
u8 swp_outer_l3_offset; /* 1 1 */
|
|
u8 swp_inner_l4_offset; /* 2 1 */
|
|
u8 swp_inner_l3_offset; /* 3 1 */
|
|
u8 cs_flags; /* 4 1 */
|
|
u8 swp_flags; /* 5 1 */
|
|
__be16 mss; /* 6 2 */
|
|
__be32 flow_table_metadata; /* 8 4 */
|
|
union {
|
|
struct {
|
|
__be16 sz; /* 12 2 */
|
|
u8 start[2]; /* 14 2 */
|
|
} inline_hdr; /* 12 4 */
|
|
struct {
|
|
__be16 type; /* 12 2 */
|
|
__be16 vlan_tci; /* 14 2 */
|
|
} insert; /* 12 4 */
|
|
__be32 trailer; /* 12 4 */
|
|
}; /* 12 4 */
|
|
|
|
/* size: 16, cachelines: 1, members: 9 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_data_seg {
|
|
__be32 byte_count; /* 0 4 */
|
|
__be32 lkey; /* 4 4 */
|
|
__be64 addr; /* 8 8 */
|
|
|
|
/* size: 16, cachelines: 1, members: 3 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
So, split the memcpy() so the compiler can reason about the buffer
|
|
sizes.
|
|
|
|
"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
|
|
nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
|
|
code changes (i.e. only source line number induced differences and
|
|
optimizations).(CVE-2022-48744)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
|
|
|
|
The bnx2fc_destroy() functions are removing the interface before calling
|
|
destroy_work. This results multiple WARNings from sysfs_remove_group() as
|
|
the controller rport device attributes are removed too early.
|
|
|
|
Replace the fcoe_port's destroy_work queue. It's not needed.
|
|
|
|
The problem is easily reproducible with the following steps.
|
|
|
|
Example:
|
|
|
|
$ dmesg -w &
|
|
$ systemctl enable --now fcoe
|
|
$ fipvlan -s -c ens2f1
|
|
$ fcoeadm -d ens2f1.802
|
|
[ 583.464488] host2: libfc: Link down on port (7500a1)
|
|
[ 583.472651] bnx2fc: 7500a1 - rport not created Yet!!
|
|
[ 583.490468] ------------[ cut here ]------------
|
|
[ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
|
|
[ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
|
|
[ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
|
|
[ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
|
|
[ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
|
|
[ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
|
|
[ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
|
|
[ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
|
|
[ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
|
|
[ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
|
|
[ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
|
|
[ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
|
|
[ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
|
|
[ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
|
|
[ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
|
|
[ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
|
|
[ 584.454888] Call Trace:
|
|
[ 584.466108] device_del+0xb2/0x3e0
|
|
[ 584.481701] device_unregister+0x13/0x60
|
|
[ 584.501306] bsg_unregister_queue+0x5b/0x80
|
|
[ 584.522029] bsg_remove_queue+0x1c/0x40
|
|
[ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
|
|
[ 584.573823] process_one_work+0x1e3/0x3b0
|
|
[ 584.592396] worker_thread+0x50/0x3b0
|
|
[ 584.609256] ? rescuer_thread+0x370/0x370
|
|
[ 584.628877] kthread+0x149/0x170
|
|
[ 584.643673] ? set_kthread_struct+0x40/0x40
|
|
[ 584.662909] ret_from_fork+0x22/0x30
|
|
[ 584.680002] ---[ end trace 53575ecefa942ece ]---(CVE-2022-48758)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: lgdt3306a: Add a check against null-pointer-def
|
|
|
|
The driver should check whether the client provides the platform_data.
|
|
|
|
The following log reveals it:
|
|
|
|
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
|
|
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
|
|
[ 29.612820] Call Trace:
|
|
[ 29.613030] <TASK>
|
|
[ 29.613201] dump_stack_lvl+0x56/0x6f
|
|
[ 29.613496] ? kmemdup+0x30/0x40
|
|
[ 29.613754] print_report.cold+0x494/0x6b7
|
|
[ 29.614082] ? kmemdup+0x30/0x40
|
|
[ 29.614340] kasan_report+0x8a/0x190
|
|
[ 29.614628] ? kmemdup+0x30/0x40
|
|
[ 29.614888] kasan_check_range+0x14d/0x1d0
|
|
[ 29.615213] memcpy+0x20/0x60
|
|
[ 29.615454] kmemdup+0x30/0x40
|
|
[ 29.615700] lgdt3306a_probe+0x52/0x310
|
|
[ 29.616339] i2c_device_probe+0x951/0xa90(CVE-2022-48772)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: sdio: fix possible resource leaks in some error paths
|
|
|
|
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
|
|
not release the resources, because the sdio function is not presented
|
|
in these two cases, it won't call of_node_put() or put_device().
|
|
|
|
To fix these leaks, make sdio_func_present() only control whether
|
|
device_del() needs to be called or not, then always call of_node_put()
|
|
and put_device().
|
|
|
|
In error case in sdio_init_func(), the reference of 'card->dev' is
|
|
not get, to avoid redundant put in sdio_free_func_cis(), move the
|
|
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
|
|
it can keep the get/put function be balanced.
|
|
|
|
Without this patch, while doing fault inject test, it can get the
|
|
following leak reports, after this fix, the leak is gone.
|
|
|
|
unreferenced object 0xffff888112514000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
|
|
hex dump (first 32 bytes):
|
|
00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......
|
|
10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
|
|
[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
|
|
[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
|
|
|
|
unreferenced object 0xffff888112511000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
|
|
hex dump (first 32 bytes):
|
|
00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......
|
|
10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
|
|
[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core](CVE-2023-52730)
|
|
|
|
In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.(CVE-2024-23848)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_skbmod: prevent kernel-infoleak
|
|
|
|
syzbot found that tcf_skbmod_dump() was copying four bytes
|
|
from kernel stack to user space [1].
|
|
|
|
The issue here is that 'struct tc_skbmod' has a four bytes hole.
|
|
|
|
We need to clear the structure before filling fields.
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
copy_to_iter include/linux/uio.h:196 [inline]
|
|
simple_copy_to_iter net/core/datagram.c:532 [inline]
|
|
__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
|
|
netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
|
__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
|
|
__do_sys_recvfrom net/socket.c:2260 [inline]
|
|
__se_sys_recvfrom net/socket.c:2256 [inline]
|
|
__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
|
|
netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
|
|
netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
|
|
nlmsg_unicast include/net/netlink.h:1144 [inline]
|
|
nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
|
|
rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
|
|
rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2048 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
|
|
rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
|
netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
|
|
netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
__nla_put lib/nlattr.c:1041 [inline]
|
|
nla_put+0x1c6/0x230 lib/nlattr.c:1099
|
|
tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
|
|
tcf_action_dump_old net/sched/act_api.c:1191 [inline]
|
|
tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
|
|
tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
|
|
tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
|
|
tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2042 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
|
|
---truncated---(CVE-2024-35893)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
|
|
|
|
syzbot reported the following uninit-value access issue [1][2]:
|
|
|
|
nci_rx_work() parses and processes received packet. When the payload
|
|
length is zero, each message type handler reads uninitialized payload
|
|
and KMSAN detects this issue. The receipt of a packet with a zero-size
|
|
payload is considered unexpected, and therefore, such packets should be
|
|
silently discarded.
|
|
|
|
This patch resolved this issue by checking payload size before calling
|
|
each message type handler codes.(CVE-2024-35915)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/arm/malidp: fix a possible null pointer dereference
|
|
|
|
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
|
|
no check is performed. In order to prevent null pointer dereferencing,
|
|
ensure that mw_state is checked before calling
|
|
__drm_atomic_helper_connector_reset.(CVE-2024-36014)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.(CVE-2024-36949)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK>(CVE-2024-37356)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: vc4: Fix possible null pointer dereference
|
|
|
|
In vc4_hdmi_audio_init() of_get_address() may return
|
|
NULL which is later dereferenced. Fix this bug by adding NULL check.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.(CVE-2024-38553)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issue of net_device
|
|
|
|
There is a reference count leak issue of the object "net_device" in
|
|
ax25_dev_device_down(). When the ax25 device is shutting down, the
|
|
ax25_dev_device_down() drops the reference count of net_device one
|
|
or zero times depending on if we goto unlock_put or not, which will
|
|
cause memory leak.
|
|
|
|
In order to solve the above issue, decrease the reference count of
|
|
net_device after dev->ax25_ptr is set to null.(CVE-2024-38554)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: qedf: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a count-sized kernel buffer and copy count from
|
|
userspace to that buffer. Later, we use kstrtouint on this buffer but we
|
|
don't ensure that the string is terminated inside the buffer, this can
|
|
lead to OOB read when using kstrtouint. Fix this issue by using
|
|
memdup_user_nul instead of memdup_user.(CVE-2024-38559)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ecryptfs: Fix buffer size for tag 66 packet
|
|
|
|
The 'TAG 66 Packet Format' description is missing the cipher code and
|
|
checksum fields that are packed into the message packet. As a result,
|
|
the buffer allocated for the packet is 3 bytes too small and
|
|
write_tag_66_packet() will write up to 3 bytes past the end of the
|
|
buffer.
|
|
|
|
Fix this by increasing the size of the allocation so the whole packet
|
|
will always fit in the buffer.
|
|
|
|
This fixes the below kasan slab-out-of-bounds bug:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
|
|
|
|
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x4c/0x70
|
|
print_report+0xc5/0x610
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? kasan_complete_mode_report_info+0x44/0x210
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
kasan_report+0xc2/0x110
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
__asan_store1+0x62/0x80
|
|
ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
|
|
? __alloc_pages+0x2e2/0x540
|
|
? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
|
|
? dentry_open+0x8f/0xd0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
? __pfx_ecryptfs_write_metadata+0x10/0x10
|
|
? ecryptfs_get_lower_file+0x6b/0x190
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
? __pfx_path_openat+0x10/0x10
|
|
do_filp_open+0x15e/0x290
|
|
? __pfx_do_filp_open+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? _raw_spin_lock+0x86/0xf0
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? alloc_fd+0xf4/0x330
|
|
do_sys_openat2+0x122/0x160
|
|
? __pfx_do_sys_openat2+0x10/0x10
|
|
__x64_sys_openat+0xef/0x170
|
|
? __pfx___x64_sys_openat+0x10/0x10
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
RIP: 0033:0x7f00a703fd67
|
|
Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
|
|
RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
|
|
RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
|
|
RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
|
|
RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
|
|
R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
|
|
</TASK>
|
|
|
|
Allocated by task 181:
|
|
kasan_save_stack+0x2f/0x60
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x25/0x40
|
|
__kasan_kmalloc+0xc5/0xd0
|
|
__kmalloc+0x66/0x160
|
|
ecryptfs_generate_key_packet_set+0x6d2/0xde0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
do_filp_open+0x15e/0x290
|
|
do_sys_openat2+0x122/0x160
|
|
__x64_sys_openat+0xef/0x170
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2024-38578)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: bcm - Fix pointer arithmetic
|
|
|
|
In spu2_dump_omd() value of ptr is increased by ciph_key_len
|
|
instead of hash_iv_len which could lead to going beyond the
|
|
buffer boundaries.
|
|
Fix this bug by changing ciph_key_len to hash_iv_len.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential hang in nilfs_detach_log_writer()
|
|
|
|
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
|
|
during nilfs2 unmount.
|
|
|
|
Analysis revealed that this is because nilfs_segctor_sync(), which
|
|
synchronizes with the log writer thread, can be called after
|
|
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
|
|
below:
|
|
|
|
nilfs_detach_log_writer
|
|
nilfs_segctor_destroy
|
|
nilfs_segctor_kill_thread --> Shut down log writer thread
|
|
flush_work
|
|
nilfs_iput_work_func
|
|
nilfs_dispose_list
|
|
iput
|
|
nilfs_evict_inode
|
|
nilfs_transaction_commit
|
|
nilfs_construct_segment (if inode needs sync)
|
|
nilfs_segctor_sync --> Attempt to synchronize with
|
|
log writer thread
|
|
*** DEADLOCK ***
|
|
|
|
Fix this issue by changing nilfs_segctor_sync() so that the log writer
|
|
thread returns normally without synchronizing after it terminates, and by
|
|
forcing tasks that are already waiting to complete once after the thread
|
|
terminates.
|
|
|
|
The skipped inode metadata flushout will then be processed together in the
|
|
subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix use-after-free of timer for log writer thread
|
|
|
|
Patch series "nilfs2: fix log writer related issues".
|
|
|
|
This bug fix series covers three nilfs2 log writer-related issues,
|
|
including a timer use-after-free issue and potential deadlock issue on
|
|
unmount, and a potential freeze issue in event synchronization found
|
|
during their analysis. Details are described in each commit log.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
A use-after-free issue has been reported regarding the timer sc_timer on
|
|
the nilfs_sc_info structure.
|
|
|
|
The problem is that even though it is used to wake up a sleeping log
|
|
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
|
|
is about to be freed, and is used regardless of the thread's lifetime.
|
|
|
|
Fix this issue by limiting the use of sc_timer only while the log writer
|
|
thread is alive.(CVE-2024-38583)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: timer: Set lower bound of start tick time
|
|
|
|
Currently ALSA timer doesn't have the lower limit of the start tick
|
|
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
|
|
for hrtimer. Such a situation may lead to an unexpected RCU stall,
|
|
where the callback repeatedly queuing the expire update, as reported
|
|
by fuzzer.
|
|
|
|
This patch introduces a sanity check of the timer start tick time, so
|
|
that the system returns an error when a too small start size is set.
|
|
As of this patch, the lower limit is hard-coded to 100us, which is
|
|
small enough but can still work somehow.(CVE-2024-38618)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Update uart_driver_registered on driver removal
|
|
|
|
The removal of the last MAX3100 device triggers the removal of
|
|
the driver. However, code doesn't update the respective global
|
|
variable and after insmod — rmmod — insmod cycle the kernel
|
|
oopses:
|
|
|
|
max3100 spi-PRP0001:01: max3100_probe: adding port 0
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000408
|
|
...
|
|
RIP: 0010:serial_core_register_port+0xa0/0x840
|
|
...
|
|
max3100_probe+0x1b6/0x280 [max3100]
|
|
spi_probe+0x8d/0xb0
|
|
|
|
Update the actual state so next time UART driver will be registered
|
|
again.
|
|
|
|
Hugo also noticed, that the error path in the probe also affected
|
|
by having the variable set, and not cleared. Instead of clearing it
|
|
move the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
greybus: lights: check return of get_channel_from_mode
|
|
|
|
If channel for the given node is not found we return null from
|
|
get_channel_from_mode. Make sure we validate the return pointer
|
|
before using it in two of the missing places.
|
|
|
|
This was originally reported in [0]:
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
enic: Validate length of nl attributes in enic_set_vf_port
|
|
|
|
enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE
|
|
is of length PORT_PROFILE_MAX and that the nl attributes
|
|
IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.
|
|
These attributes are validated (in the function do_setlink in rtnetlink.c)
|
|
using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE
|
|
as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and
|
|
IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation
|
|
using the policy is for the max size of the attributes and not on exact
|
|
size so the length of these attributes might be less than the sizes that
|
|
enic_set_vf_port expects. This might cause an out of bands
|
|
read access in the memcpys of the data of these
|
|
attributes in enic_set_vf_port.(CVE-2024-38659)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
|
|
|
|
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
|
|
known context") by error replaced spin_unlock_irqrestore() with
|
|
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
|
|
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
|
|
inconsistent lock state warning.
|
|
|
|
Use plain spin_{lock,unlock}() for sync_print_obj(), for
|
|
sync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/9p: fix uninit-value in p9_client_rpc()
|
|
|
|
Syzbot with the help of KMSAN reported the following error:
|
|
|
|
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
alloc_slab_page mm/slub.c:2175 [inline]
|
|
allocate_slab mm/slub.c:2338 [inline]
|
|
new_slab+0x2de/0x1400 mm/slub.c:2391
|
|
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
|
|
__slab_alloc mm/slub.c:3610 [inline]
|
|
__slab_alloc_node mm/slub.c:3663 [inline]
|
|
slab_alloc_node mm/slub.c:3835 [inline]
|
|
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
|
|
p9_tag_alloc net/9p/client.c:278 [inline]
|
|
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
|
|
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
|
|
will not be properly initialized. However, trace_9p_client_res()
|
|
ends up trying to print it out anyway before p9_client_rpc()
|
|
finishes.
|
|
|
|
Fix this issue by assigning default values to p9_fcall fields
|
|
such as 'tag' and (just in case KMSAN unearths something new) 'id'
|
|
during the tag allocation stage.(CVE-2024-39301)</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/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47270</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47515</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47583</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47611</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47619</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48717</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48722</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48736</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48738</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48743</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48744</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48758</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48772</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52730</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-23848</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-31076</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35893</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35915</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36014</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36949</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37356</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38546</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38553</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38554</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38559</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38578</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38579</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38582</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38583</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38618</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38633</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38634</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38637</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38659</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38780</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39301</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47270</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47515</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47583</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47611</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47619</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48717</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48722</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48736</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48738</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48743</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48744</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48758</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48772</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52730</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-23848</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-31076</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35893</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35915</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36014</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36949</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37356</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38546</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38553</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38554</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38559</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38578</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38579</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38582</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38583</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38634</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38637</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38659</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38780</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39301</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="x86_64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.3.0.0285.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.3.0.0285" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.3.0.0285.oe2003sp4.aarch64.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:
|
|
|
|
usb: fix various gadgets null ptr deref on 10gbps cabling.
|
|
|
|
This avoids a null pointer dereference in
|
|
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
|
|
by simply reusing the 5gbps config for 10gbps.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47270</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
seg6: fix the iif in the IPv6 socket control block
|
|
|
|
When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving
|
|
interface index into the IPv4 socket control block (v5.16-rc4,
|
|
net/ipv4/ip_input.c line 510):
|
|
|
|
IPCB(skb)->iif = skb->skb_iif;
|
|
|
|
If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH
|
|
header, the seg6_do_srh_encap(...) performs the required encapsulation.
|
|
In this case, the seg6_do_srh_encap function clears the IPv6 socket control
|
|
block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):
|
|
|
|
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
|
|
|
|
The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear
|
|
IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).
|
|
|
|
Since the IPv6 socket control block and the IPv4 socket control block share
|
|
the same memory area (skb->cb), the receiving interface index info is lost
|
|
(IP6CB(skb)->iif is set to zero).
|
|
|
|
As a side effect, that condition triggers a NULL pointer dereference if
|
|
commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig
|
|
netdev") is applied.
|
|
|
|
To fix that issue, we set the IP6CB(skb)->iif with the index of the
|
|
receiving interface once again.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47515</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
media: mxl111sf: change mutex_init() location
|
|
|
|
Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized
|
|
mutex. The problem was in wrong mutex_init() location.
|
|
|
|
Previous mutex_init(&state->msg_lock) call was in ->init() function, but
|
|
dvb_usbv2_init() has this order of calls:
|
|
|
|
dvb_usbv2_init()
|
|
dvb_usbv2_adapter_init()
|
|
dvb_usbv2_adapter_frontend_init()
|
|
props->frontend_attach()
|
|
|
|
props->init()
|
|
|
|
Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()
|
|
internally we need to initialize state->msg_lock before
|
|
frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*
|
|
devices, which will simply initiaize mutex.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47583</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
mac80211: validate extended element ID is present
|
|
|
|
Before attempting to parse an extended element, verify that
|
|
the extended element ID is present.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47611</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
i40e: Fix queues reservation for XDP
|
|
|
|
When XDP was configured on a system with large number of CPUs
|
|
and X722 NIC there was a call trace with NULL pointer dereference.
|
|
|
|
i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12
|
|
i40e 0000:87:00.0: setup of MAIN VSI failed
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
|
|
Call Trace:
|
|
? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
|
|
dev_xdp_install+0x61/0xe0
|
|
dev_xdp_attach+0x18a/0x4c0
|
|
dev_change_xdp_fd+0x1e6/0x220
|
|
do_setlink+0x616/0x1030
|
|
? ahci_port_stop+0x80/0x80
|
|
? ata_qc_issue+0x107/0x1e0
|
|
? lock_timer_base+0x61/0x80
|
|
? __mod_timer+0x202/0x380
|
|
rtnl_setlink+0xe5/0x170
|
|
? bpf_lsm_binder_transaction+0x10/0x10
|
|
? security_capable+0x36/0x50
|
|
rtnetlink_rcv_msg+0x121/0x350
|
|
? rtnl_calcit.isra.0+0x100/0x100
|
|
netlink_rcv_skb+0x50/0xf0
|
|
netlink_unicast+0x1d3/0x2a0
|
|
netlink_sendmsg+0x22a/0x440
|
|
sock_sendmsg+0x5e/0x60
|
|
__sys_sendto+0xf0/0x160
|
|
? __sys_getsockname+0x7e/0xc0
|
|
? _copy_from_user+0x3c/0x80
|
|
? __sys_setsockopt+0xc8/0x1a0
|
|
__x64_sys_sendto+0x20/0x30
|
|
do_syscall_64+0x33/0x40
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f83fa7a39e0
|
|
|
|
This was caused by PF queue pile fragmentation due to
|
|
flow director VSI queue being placed right after main VSI.
|
|
Because of this main VSI was not able to resize its
|
|
queue allocation for XDP resulting in no queues allocated
|
|
for main VSI when XDP was turned on.
|
|
|
|
Fix this by always allocating last queue in PF queue pile
|
|
for a flow director VSI.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2021-47619</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
ASoC: max9759: fix underflow in speaker_gain_control_put()
|
|
|
|
Check for negative values of "priv->gain" to prevent an out of bounds
|
|
access. The concern is that these might come from the user via:
|
|
-> snd_ctl_elem_write_user()
|
|
-> snd_ctl_elem_write()
|
|
-> kctl->put()</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48717</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
net: ieee802154: ca8210: Stop leaking skb's
|
|
|
|
Upon error the ieee802154_xmit_complete() helper is not called. Only
|
|
ieee802154_wake_queue() is called manually. We then leak the skb
|
|
structure.
|
|
|
|
Free the skb structure upon error before returning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48722</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48736</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
|
|
|
|
We don't currently validate that the values being set are within the range
|
|
we advertised to userspace as being valid, do so and reject any values
|
|
that are out of range.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48738</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
net: amd-xgbe: Fix skb data length underflow
|
|
|
|
There will be BUG_ON() triggered in include/linux/skbuff.h leading to
|
|
intermittent kernel panic, when the skb length underflow is detected.
|
|
|
|
Fix this by dropping the packet if such length underflows are seen
|
|
because of inconsistencies in the hardware descriptors.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48743</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
net/mlx5e: Avoid field-overflowing memcpy()
|
|
|
|
In preparation for FORTIFY_SOURCE performing compile-time and run-time
|
|
field bounds checking for memcpy(), memmove(), and memset(), avoid
|
|
intentionally writing across neighboring fields.
|
|
|
|
Use flexible arrays instead of zero-element arrays (which look like they
|
|
are always overflowing) and split the cross-field memcpy() into two halves
|
|
that can be appropriately bounds-checked by the compiler.
|
|
|
|
We were doing:
|
|
|
|
#define ETH_HLEN 14
|
|
#define VLAN_HLEN 4
|
|
...
|
|
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
|
|
...
|
|
struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi);
|
|
...
|
|
struct mlx5_wqe_eth_seg *eseg = &wqe->eth;
|
|
struct mlx5_wqe_data_seg *dseg = wqe->data;
|
|
...
|
|
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
|
|
|
|
target is wqe->eth.inline_hdr.start (which the compiler sees as being
|
|
2 bytes in size), but copying 18, intending to write across start
|
|
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
|
|
wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
|
|
(8 bytes).
|
|
|
|
struct mlx5e_tx_wqe {
|
|
struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */
|
|
struct mlx5_wqe_eth_seg eth; /* 16 16 */
|
|
struct mlx5_wqe_data_seg data[]; /* 32 0 */
|
|
|
|
/* size: 32, cachelines: 1, members: 3 */
|
|
/* last cacheline: 32 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_eth_seg {
|
|
u8 swp_outer_l4_offset; /* 0 1 */
|
|
u8 swp_outer_l3_offset; /* 1 1 */
|
|
u8 swp_inner_l4_offset; /* 2 1 */
|
|
u8 swp_inner_l3_offset; /* 3 1 */
|
|
u8 cs_flags; /* 4 1 */
|
|
u8 swp_flags; /* 5 1 */
|
|
__be16 mss; /* 6 2 */
|
|
__be32 flow_table_metadata; /* 8 4 */
|
|
union {
|
|
struct {
|
|
__be16 sz; /* 12 2 */
|
|
u8 start[2]; /* 14 2 */
|
|
} inline_hdr; /* 12 4 */
|
|
struct {
|
|
__be16 type; /* 12 2 */
|
|
__be16 vlan_tci; /* 14 2 */
|
|
} insert; /* 12 4 */
|
|
__be32 trailer; /* 12 4 */
|
|
}; /* 12 4 */
|
|
|
|
/* size: 16, cachelines: 1, members: 9 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
struct mlx5_wqe_data_seg {
|
|
__be32 byte_count; /* 0 4 */
|
|
__be32 lkey; /* 4 4 */
|
|
__be64 addr; /* 8 8 */
|
|
|
|
/* size: 16, cachelines: 1, members: 3 */
|
|
/* last cacheline: 16 bytes */
|
|
};
|
|
|
|
So, split the memcpy() so the compiler can reason about the buffer
|
|
sizes.
|
|
|
|
"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
|
|
nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
|
|
code changes (i.e. only source line number induced differences and
|
|
optimizations).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48744</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
|
|
|
|
The bnx2fc_destroy() functions are removing the interface before calling
|
|
destroy_work. This results multiple WARNings from sysfs_remove_group() as
|
|
the controller rport device attributes are removed too early.
|
|
|
|
Replace the fcoe_port's destroy_work queue. It's not needed.
|
|
|
|
The problem is easily reproducible with the following steps.
|
|
|
|
Example:
|
|
|
|
$ dmesg -w &
|
|
$ systemctl enable --now fcoe
|
|
$ fipvlan -s -c ens2f1
|
|
$ fcoeadm -d ens2f1.802
|
|
[ 583.464488] host2: libfc: Link down on port (7500a1)
|
|
[ 583.472651] bnx2fc: 7500a1 - rport not created Yet!!
|
|
[ 583.490468] ------------[ cut here ]------------
|
|
[ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
|
|
[ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
|
|
[ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
|
|
[ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
|
|
[ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
|
|
[ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
|
|
[ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
|
|
[ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
|
|
[ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
|
|
[ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
|
|
[ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
|
|
[ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
|
|
[ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
|
|
[ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
|
|
[ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
|
|
[ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
|
|
[ 584.454888] Call Trace:
|
|
[ 584.466108] device_del+0xb2/0x3e0
|
|
[ 584.481701] device_unregister+0x13/0x60
|
|
[ 584.501306] bsg_unregister_queue+0x5b/0x80
|
|
[ 584.522029] bsg_remove_queue+0x1c/0x40
|
|
[ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
|
|
[ 584.573823] process_one_work+0x1e3/0x3b0
|
|
[ 584.592396] worker_thread+0x50/0x3b0
|
|
[ 584.609256] ? rescuer_thread+0x370/0x370
|
|
[ 584.628877] kthread+0x149/0x170
|
|
[ 584.643673] ? set_kthread_struct+0x40/0x40
|
|
[ 584.662909] ret_from_fork+0x22/0x30
|
|
[ 584.680002] ---[ end trace 53575ecefa942ece ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48758</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
media: lgdt3306a: Add a check against null-pointer-def
|
|
|
|
The driver should check whether the client provides the platform_data.
|
|
|
|
The following log reveals it:
|
|
|
|
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
|
|
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
|
|
[ 29.612820] Call Trace:
|
|
[ 29.613030] <TASK>
|
|
[ 29.613201] dump_stack_lvl+0x56/0x6f
|
|
[ 29.613496] ? kmemdup+0x30/0x40
|
|
[ 29.613754] print_report.cold+0x494/0x6b7
|
|
[ 29.614082] ? kmemdup+0x30/0x40
|
|
[ 29.614340] kasan_report+0x8a/0x190
|
|
[ 29.614628] ? kmemdup+0x30/0x40
|
|
[ 29.614888] kasan_check_range+0x14d/0x1d0
|
|
[ 29.615213] memcpy+0x20/0x60
|
|
[ 29.615454] kmemdup+0x30/0x40
|
|
[ 29.615700] lgdt3306a_probe+0x52/0x310
|
|
[ 29.616339] i2c_device_probe+0x951/0xa90</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2022-48772</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
mmc: sdio: fix possible resource leaks in some error paths
|
|
|
|
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
|
|
not release the resources, because the sdio function is not presented
|
|
in these two cases, it won't call of_node_put() or put_device().
|
|
|
|
To fix these leaks, make sdio_func_present() only control whether
|
|
device_del() needs to be called or not, then always call of_node_put()
|
|
and put_device().
|
|
|
|
In error case in sdio_init_func(), the reference of 'card->dev' is
|
|
not get, to avoid redundant put in sdio_free_func_cis(), move the
|
|
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
|
|
it can keep the get/put function be balanced.
|
|
|
|
Without this patch, while doing fault inject test, it can get the
|
|
following leak reports, after this fix, the leak is gone.
|
|
|
|
unreferenced object 0xffff888112514000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
|
|
hex dump (first 32 bytes):
|
|
00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......
|
|
10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
|
|
[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
|
|
[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
|
|
|
|
unreferenced object 0xffff888112511000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
|
|
hex dump (first 32 bytes):
|
|
00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......
|
|
10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
|
|
[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2023-52730</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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 through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-23848</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-31076</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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:
|
|
|
|
net/sched: act_skbmod: prevent kernel-infoleak
|
|
|
|
syzbot found that tcf_skbmod_dump() was copying four bytes
|
|
from kernel stack to user space [1].
|
|
|
|
The issue here is that 'struct tc_skbmod' has a four bytes hole.
|
|
|
|
We need to clear the structure before filling fields.
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
|
copy_to_iter include/linux/uio.h:196 [inline]
|
|
simple_copy_to_iter net/core/datagram.c:532 [inline]
|
|
__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
|
|
netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
|
|
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
|
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
|
__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
|
|
__do_sys_recvfrom net/socket.c:2260 [inline]
|
|
__se_sys_recvfrom net/socket.c:2256 [inline]
|
|
__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
|
|
netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
|
|
netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
|
|
nlmsg_unicast include/net/netlink.h:1144 [inline]
|
|
nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
|
|
rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
|
|
rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2048 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
|
|
rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
|
netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
|
|
netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was stored to memory at:
|
|
__nla_put lib/nlattr.c:1041 [inline]
|
|
nla_put+0x1c6/0x230 lib/nlattr.c:1099
|
|
tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
|
|
tcf_action_dump_old net/sched/act_api.c:1191 [inline]
|
|
tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
|
|
tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
|
|
tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
|
|
tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
|
|
tcf_add_notify net/sched/act_api.c:2042 [inline]
|
|
tcf_action_add net/sched/act_api.c:2071 [inline]
|
|
tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
|
|
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
|
|
netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35893</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
|
|
|
|
syzbot reported the following uninit-value access issue [1][2]:
|
|
|
|
nci_rx_work() parses and processes received packet. When the payload
|
|
length is zero, each message type handler reads uninitialized payload
|
|
and KMSAN detects this issue. The receipt of a packet with a zero-size
|
|
payload is considered unexpected, and therefore, such packets should be
|
|
silently discarded.
|
|
|
|
This patch resolved this issue by checking payload size before calling
|
|
each message type handler codes.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-35915</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/arm/malidp: fix a possible null pointer dereference
|
|
|
|
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
|
|
no check is performed. In order to prevent null pointer dereferencing,
|
|
ensure that mw_state is checked before calling
|
|
__drm_atomic_helper_connector_reset.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36014</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-36949</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
|
|
|
|
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
|
|
as follows:
|
|
|
|
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
|
|
...
|
|
delivered_ce <<= (10 - dctcp_shift_g);
|
|
|
|
It seems syzkaller started fuzzing module parameters and triggered
|
|
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
|
|
|
|
memcpy((void*)0x20000080,
|
|
"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
|
|
res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
|
|
/*flags=*/2ul, /*mode=*/0ul);
|
|
memcpy((void*)0x20000000, "100\000", 4);
|
|
syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
|
|
|
|
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
|
|
|
|
With this patch:
|
|
|
|
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
# cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
10
|
|
# echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
|
|
-bash: echo: write error: Invalid argument
|
|
|
|
[0]:
|
|
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
|
|
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
|
|
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
|
|
ubsan_epilogue lib/ubsan.c:231 [inline]
|
|
__ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
|
|
dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
|
|
tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
|
|
tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
|
|
tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
|
|
tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
|
|
sk_backlog_rcv include/net/sock.h:1106 [inline]
|
|
__release_sock+0x20f/0x350 net/core/sock.c:2983
|
|
release_sock+0x61/0x1f0 net/core/sock.c:3549
|
|
mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
|
|
mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
|
|
__mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
|
|
mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
|
|
inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xc0/0x240 net/socket.c:1421
|
|
__fput+0x41b/0x890 fs/file_table.c:422
|
|
task_work_run+0x23b/0x300 kernel/task_work.c:180
|
|
exit_task_work include/linux/task_work.h:38 [inline]
|
|
do_exit+0x9c8/0x2540 kernel/exit.c:878
|
|
do_group_exit+0x201/0x2b0 kernel/exit.c:1027
|
|
__do_sys_exit_group kernel/exit.c:1038 [inline]
|
|
__se_sys_exit_group kernel/exit.c:1036 [inline]
|
|
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
RIP: 0033:0x7f6c2b5005b6
|
|
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
|
|
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
|
|
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
|
|
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
|
|
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
|
|
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
|
|
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-37356</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: vc4: Fix possible null pointer dereference
|
|
|
|
In vc4_hdmi_audio_init() of_get_address() may return
|
|
NULL which is later dereferenced. Fix this bug by adding NULL check.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38546</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>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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fec: remove .ndo_poll_controller to avoid deadlocks
|
|
|
|
There is a deadlock issue found in sungem driver, please refer to the
|
|
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
|
|
deadlocks"). The root cause of the issue is that netpoll is in atomic
|
|
context and disable_irq() is called by .ndo_poll_controller interface
|
|
of sungem driver, however, disable_irq() might sleep. After analyzing
|
|
the implementation of fec_poll_controller(), the fec driver should have
|
|
the same issue. Due to the fec driver uses NAPI for TX completions, the
|
|
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
|
|
so fec_poll_controller() can be safely removed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38553</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ax25: Fix reference count leak issue of net_device
|
|
|
|
There is a reference count leak issue of the object "net_device" in
|
|
ax25_dev_device_down(). When the ax25 device is shutting down, the
|
|
ax25_dev_device_down() drops the reference count of net_device one
|
|
or zero times depending on if we goto unlock_put or not, which will
|
|
cause memory leak.
|
|
|
|
In order to solve the above issue, decrease the reference count of
|
|
net_device after dev->ax25_ptr is set to null.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38554</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: qedf: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a count-sized kernel buffer and copy count from
|
|
userspace to that buffer. Later, we use kstrtouint on this buffer but we
|
|
don't ensure that the string is terminated inside the buffer, this can
|
|
lead to OOB read when using kstrtouint. Fix this issue by using
|
|
memdup_user_nul instead of memdup_user.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38559</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ecryptfs: Fix buffer size for tag 66 packet
|
|
|
|
The 'TAG 66 Packet Format' description is missing the cipher code and
|
|
checksum fields that are packed into the message packet. As a result,
|
|
the buffer allocated for the packet is 3 bytes too small and
|
|
write_tag_66_packet() will write up to 3 bytes past the end of the
|
|
buffer.
|
|
|
|
Fix this by increasing the size of the allocation so the whole packet
|
|
will always fit in the buffer.
|
|
|
|
This fixes the below kasan slab-out-of-bounds bug:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
|
|
|
|
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x4c/0x70
|
|
print_report+0xc5/0x610
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? kasan_complete_mode_report_info+0x44/0x210
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
kasan_report+0xc2/0x110
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
__asan_store1+0x62/0x80
|
|
ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
|
|
? __alloc_pages+0x2e2/0x540
|
|
? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
|
|
? dentry_open+0x8f/0xd0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
? __pfx_ecryptfs_write_metadata+0x10/0x10
|
|
? ecryptfs_get_lower_file+0x6b/0x190
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
? __pfx_path_openat+0x10/0x10
|
|
do_filp_open+0x15e/0x290
|
|
? __pfx_do_filp_open+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? _raw_spin_lock+0x86/0xf0
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? alloc_fd+0xf4/0x330
|
|
do_sys_openat2+0x122/0x160
|
|
? __pfx_do_sys_openat2+0x10/0x10
|
|
__x64_sys_openat+0xef/0x170
|
|
? __pfx___x64_sys_openat+0x10/0x10
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
RIP: 0033:0x7f00a703fd67
|
|
Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
|
|
RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
|
|
RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
|
|
RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
|
|
RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
|
|
R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
|
|
</TASK>
|
|
|
|
Allocated by task 181:
|
|
kasan_save_stack+0x2f/0x60
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x25/0x40
|
|
__kasan_kmalloc+0xc5/0xd0
|
|
__kmalloc+0x66/0x160
|
|
ecryptfs_generate_key_packet_set+0x6d2/0xde0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
do_filp_open+0x15e/0x290
|
|
do_sys_openat2+0x122/0x160
|
|
__x64_sys_openat+0xef/0x170
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38578</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: bcm - Fix pointer arithmetic
|
|
|
|
In spu2_dump_omd() value of ptr is increased by ciph_key_len
|
|
instead of hash_iv_len which could lead to going beyond the
|
|
buffer boundaries.
|
|
Fix this bug by changing ciph_key_len to hash_iv_len.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38579</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:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential hang in nilfs_detach_log_writer()
|
|
|
|
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
|
|
during nilfs2 unmount.
|
|
|
|
Analysis revealed that this is because nilfs_segctor_sync(), which
|
|
synchronizes with the log writer thread, can be called after
|
|
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
|
|
below:
|
|
|
|
nilfs_detach_log_writer
|
|
nilfs_segctor_destroy
|
|
nilfs_segctor_kill_thread --> Shut down log writer thread
|
|
flush_work
|
|
nilfs_iput_work_func
|
|
nilfs_dispose_list
|
|
iput
|
|
nilfs_evict_inode
|
|
nilfs_transaction_commit
|
|
nilfs_construct_segment (if inode needs sync)
|
|
nilfs_segctor_sync --> Attempt to synchronize with
|
|
log writer thread
|
|
*** DEADLOCK ***
|
|
|
|
Fix this issue by changing nilfs_segctor_sync() so that the log writer
|
|
thread returns normally without synchronizing after it terminates, and by
|
|
forcing tasks that are already waiting to complete once after the thread
|
|
terminates.
|
|
|
|
The skipped inode metadata flushout will then be processed together in the
|
|
subsequent cleanup work in nilfs_segctor_destroy().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38582</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix use-after-free of timer for log writer thread
|
|
|
|
Patch series "nilfs2: fix log writer related issues".
|
|
|
|
This bug fix series covers three nilfs2 log writer-related issues,
|
|
including a timer use-after-free issue and potential deadlock issue on
|
|
unmount, and a potential freeze issue in event synchronization found
|
|
during their analysis. Details are described in each commit log.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
A use-after-free issue has been reported regarding the timer sc_timer on
|
|
the nilfs_sc_info structure.
|
|
|
|
The problem is that even though it is used to wake up a sleeping log
|
|
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
|
|
is about to be freed, and is used regardless of the thread's lifetime.
|
|
|
|
Fix this issue by limiting the use of sc_timer only while the log writer
|
|
thread is alive.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38583</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.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: timer: Set lower bound of start tick time
|
|
|
|
Currently ALSA timer doesn't have the lower limit of the start tick
|
|
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
|
|
for hrtimer. Such a situation may lead to an unexpected RCU stall,
|
|
where the callback repeatedly queuing the expire update, as reported
|
|
by fuzzer.
|
|
|
|
This patch introduces a sanity check of the timer start tick time, so
|
|
that the system returns an error when a too small start size is set.
|
|
As of this patch, the lower limit is hard-coded to 100us, which is
|
|
small enough but can still work somehow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38618</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-07-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Update uart_driver_registered on driver removal
|
|
|
|
The removal of the last MAX3100 device triggers the removal of
|
|
the driver. However, code doesn't update the respective global
|
|
variable and after insmod — rmmod — insmod cycle the kernel
|
|
oopses:
|
|
|
|
max3100 spi-PRP0001:01: max3100_probe: adding port 0
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000408
|
|
...
|
|
RIP: 0010:serial_core_register_port+0xa0/0x840
|
|
...
|
|
max3100_probe+0x1b6/0x280 [max3100]
|
|
spi_probe+0x8d/0xb0
|
|
|
|
Update the actual state so next time UART driver will be registered
|
|
again.
|
|
|
|
Hugo also noticed, that the error path in the probe also affected
|
|
by having the variable set, and not cleared. Instead of clearing it
|
|
move the assignment after the successfull uart_register_driver() call.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38633</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38634</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
greybus: lights: check return of get_channel_from_mode
|
|
|
|
If channel for the given node is not found we return null from
|
|
get_channel_from_mode. Make sure we validate the return pointer
|
|
before using it in two of the missing places.
|
|
|
|
This was originally reported in [0]:
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.
|
|
|
|
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38637</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
enic: Validate length of nl attributes in enic_set_vf_port
|
|
|
|
enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE
|
|
is of length PORT_PROFILE_MAX and that the nl attributes
|
|
IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.
|
|
These attributes are validated (in the function do_setlink in rtnetlink.c)
|
|
using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE
|
|
as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and
|
|
IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation
|
|
using the policy is for the max size of the attributes and not on exact
|
|
size so the length of these attributes might be less than the sizes that
|
|
enic_set_vf_port expects. This might cause an out of bands
|
|
read access in the memcpys of the data of these
|
|
attributes in enic_set_vf_port.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38659</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ( dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context ) by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-38780</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/9p: fix uninit-value in p9_client_rpc()
|
|
|
|
Syzbot with the help of KMSAN reported the following error:
|
|
|
|
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
trace_9p_client_res include/trace/events/9p.h:146 [inline]
|
|
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
alloc_slab_page mm/slub.c:2175 [inline]
|
|
allocate_slab mm/slub.c:2338 [inline]
|
|
new_slab+0x2de/0x1400 mm/slub.c:2391
|
|
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
|
|
__slab_alloc mm/slub.c:3610 [inline]
|
|
__slab_alloc_node mm/slub.c:3663 [inline]
|
|
slab_alloc_node mm/slub.c:3835 [inline]
|
|
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
|
|
p9_tag_alloc net/9p/client.c:278 [inline]
|
|
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
|
|
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
|
|
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
|
|
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
|
|
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
|
|
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
|
|
vfs_get_tree+0xa7/0x570 fs/super.c:1797
|
|
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
|
|
path_mount+0x742/0x1f20 fs/namespace.c:3679
|
|
do_mount fs/namespace.c:3692 [inline]
|
|
__do_sys_mount fs/namespace.c:3898 [inline]
|
|
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
|
|
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
|
|
will not be properly initialized. However, trace_9p_client_res()
|
|
ends up trying to print it out anyway before p9_client_rpc()
|
|
finishes.
|
|
|
|
Fix this issue by assigning default values to p9_fcall fields
|
|
such as 'tag' and (just in case KMSAN unearths something new) 'id'
|
|
during the tag allocation stage.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-12</ReleaseDate>
|
|
<CVE>CVE-2024-39301</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-12</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1835</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |