2712 lines
112 KiB
XML
2712 lines
112 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-24.03-LTS</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-1863</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-19</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-19</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-19</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-19</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-24.03-LTS</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:
|
|
|
|
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
|
|
|
|
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
|
|
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
|
|
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
|
|
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
|
|
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
|
|
is not enough and a too small attribute might be cast to a
|
|
struct ifla_vf_vlan_info, this might result in an out of bands
|
|
read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
|
|
|
|
Writing 'power' and 'submit_queues' concurrently will trigger kernel
|
|
panic:
|
|
|
|
Test script:
|
|
|
|
modprobe null_blk nr_devices=0
|
|
mkdir -p /sys/kernel/config/nullb/nullb0
|
|
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
|
|
while true; do echo 1 > power; echo 0 > power; done
|
|
|
|
Test result:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000148
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
RIP: 0010:__lock_acquire+0x41d/0x28f0
|
|
Call Trace:
|
|
<TASK>
|
|
lock_acquire+0x121/0x450
|
|
down_write+0x5f/0x1d0
|
|
simple_recursive_removal+0x12f/0x5c0
|
|
blk_mq_debugfs_unregister_hctxs+0x7c/0x100
|
|
blk_mq_update_nr_hw_queues+0x4a3/0x720
|
|
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
|
|
nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
|
|
configfs_write_iter+0x119/0x1e0
|
|
vfs_write+0x326/0x730
|
|
ksys_write+0x74/0x150
|
|
|
|
This is because del_gendisk() can concurrent with
|
|
blk_mq_update_nr_hw_queues():
|
|
|
|
nullb_device_power_store nullb_apply_submit_queues
|
|
null_del_dev
|
|
del_gendisk
|
|
nullb_update_nr_hw_queues
|
|
if (!dev->nullb)
|
|
// still set while gendisk is deleted
|
|
return 0
|
|
blk_mq_update_nr_hw_queues
|
|
dev->nullb = NULL
|
|
|
|
Fix this problem by resuing the global mutex to protect
|
|
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing/probes: fix error check in parse_btf_field()
|
|
|
|
btf_find_struct_member() might return NULL or an error via the
|
|
ERR_PTR() macro. However, its caller in parse_btf_field() only checks
|
|
for the NULL condition. Fix this by using IS_ERR() and returning the
|
|
error up the stack.(CVE-2024-36481)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
|
|
|
|
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
|
|
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
|
|
hbalock to avoid potential deadlock.(CVE-2024-36924)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: core: reject skb_copy(_expand) for fraglist GSO skbs
|
|
|
|
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
|
|
invalid. Return NULL if such an skb is passed to skb_copy or
|
|
skb_copy_expand, in order to prevent a crash on a potential later
|
|
call to skb_gso_segment.(CVE-2024-36929)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/cio: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
|
|
userspace to that buffer. Later, we use scanf on this buffer but we don't
|
|
ensure that the string is terminated inside the buffer, this can lead to
|
|
OOB read when using scanf. Fix this issue by using memdup_user_nul instead.(CVE-2024-36931)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdkfd: range check cp bad op exception interrupts
|
|
|
|
Due to a CP interrupt bug, bad packet garbage exception codes are raised.
|
|
Do a range check so that the debugger and runtime do not receive garbage
|
|
codes.
|
|
Update the user api to guard exception code type checking as well.(CVE-2024-36951)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
|
|
|
|
__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start
|
|
is being executed.
|
|
|
|
If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in
|
|
the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one
|
|
stat instance being added in blk_cgroup_bio_start(), then the local
|
|
list in __blkcg_rstat_flush() could be corrupted.
|
|
|
|
Fix the issue by adding one barrier.(CVE-2024-38384)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: fix overwriting ct original tuple for ICMPv6
|
|
|
|
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
|
|
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
|
|
- OVS_PACKET_ATTR_PACKET - Binary packet content.
|
|
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
|
|
|
|
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
|
|
with the metadata like conntrack state, input port, recirculation id,
|
|
etc. Then the packet itself gets parsed to populate the rest of the
|
|
keys from the packet headers.
|
|
|
|
Whenever the packet parsing code starts parsing the ICMPv6 header, it
|
|
first zeroes out fields in the key corresponding to Neighbor Discovery
|
|
information even if it is not an ND packet.
|
|
|
|
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
|
|
the space between 'nd' and 'ct_orig' that holds the original tuple
|
|
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
|
|
|
|
ND packets should not normally have conntrack state, so it's fine to
|
|
share the space, but normal ICMPv6 Echo packets or maybe other types of
|
|
ICMPv6 can have the state attached and it should not be overwritten.
|
|
|
|
The issue results in all but the last 4 bytes of the destination
|
|
address being wiped from the original conntrack tuple leading to
|
|
incorrect packet matching and potentially executing wrong actions
|
|
in case this packet recirculates within the datapath or goes back
|
|
to userspace.
|
|
|
|
ND fields should not be accessed in non-ND packets, so not clearing
|
|
them should be fine. Executing memset() only for actual ND packets to
|
|
avoid the issue.
|
|
|
|
Initializing the whole thing before parsing is needed because ND packet
|
|
may not contain all the options.
|
|
|
|
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
|
|
affect packets entering OVS datapath from network interfaces, because
|
|
in this case CT metadata is populated from skb after the packet is
|
|
already parsed.(CVE-2024-38558)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: Fix potential glock use-after-free on unmount
|
|
|
|
When a DLM lockspace is released and there ares still locks in that
|
|
lockspace, DLM will unlock those locks automatically. Commit
|
|
fb6791d100d1b started exploiting this behavior to speed up filesystem
|
|
unmount: gfs2 would simply free glocks it didn't want to unlock and then
|
|
release the lockspace. This didn't take the bast callbacks for
|
|
asynchronous lock contention notifications into account, which remain
|
|
active until until a lock is unlocked or its lockspace is released.
|
|
|
|
To prevent those callbacks from accessing deallocated objects, put the
|
|
glocks that should not be unlocked on the sd_dead_glocks list, release
|
|
the lockspace, and only then free those glocks.
|
|
|
|
As an additional measure, ignore unexpected ast and bast callbacks if
|
|
the receiving glock is dead.(CVE-2024-38570)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu/mes: fix use-after-free issue
|
|
|
|
Delete fence fallback timer to fix the ramdom
|
|
use-after-free issue.
|
|
|
|
v2: move to amdgpu_mes.c(CVE-2024-38581)
|
|
|
|
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:
|
|
|
|
r8169: Fix possible ring buffer corruption on fragmented Tx packets.
|
|
|
|
An issue was found on the RTL8125b when transmitting small fragmented
|
|
packets, whereby invalid entries were inserted into the transmit ring
|
|
buffer, subsequently leading to calls to dma_unmap_single() with a null
|
|
address.
|
|
|
|
This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
|
|
which may occur when small packets are padded (to work around hardware
|
|
quirks) in rtl8169_tso_csum_v2().
|
|
|
|
To fix this, postpone inspecting nr_frags until after any padding has been
|
|
applied.(CVE-2024-38586)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
openrisc: traps: Don't send signals to kernel mode threads
|
|
|
|
OpenRISC exception handling sends signals to user processes on floating
|
|
point exceptions and trap instructions (for debugging) among others.
|
|
There is a bug where the trap handling logic may send signals to kernel
|
|
threads, we should not send these signals to kernel threads, if that
|
|
happens we treat it as an error.
|
|
|
|
This patch adds conditions to die if the kernel receives these
|
|
exceptions in kernel mode code.(CVE-2024-38614)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: HCI: Remove HCI_AMP support
|
|
|
|
Since BT_HS has been remove HCI_AMP controllers no longer has any use so
|
|
remove it along with the capability of creating AMP controllers.
|
|
|
|
Since we no longer need to differentiate between AMP and Primary
|
|
controllers, as only HCI_PRIMARY is left, this also remove
|
|
hdev->dev_type altogether.(CVE-2024-38620)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: fix potential memory leak in vfio_intx_enable()
|
|
|
|
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.(CVE-2024-38661)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: bcm: dvp: Assign ->num before accessing ->hws
|
|
|
|
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
|
|
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
|
|
with __counted_by, which informs the bounds sanitizer about the number
|
|
of elements in hws, so that it can warn when hws is accessed out of
|
|
bounds. As noted in that change, the __counted_by member must be
|
|
initialized with the number of elements before the first array access
|
|
happens, otherwise there will be a warning from each access prior to the
|
|
initialization because the number of elements is zero. This occurs in
|
|
clk_dvp_probe() due to ->num being assigned after ->hws has been
|
|
accessed:
|
|
|
|
UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2
|
|
index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
|
|
|
|
Move the ->num initialization to before the first access of ->hws, which
|
|
clears up the warning.(CVE-2024-39462)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: v4l: async: Fix notifier list entry init
|
|
|
|
struct v4l2_async_notifier has several list_head members, but only
|
|
waiting_list and done_list are initialized. notifier_entry was kept
|
|
'zeroed' leading to an uninitialized list_head.
|
|
This results in a NULL-pointer dereference if csi2_async_register() fails,
|
|
e.g. node for remote endpoint is disabled, and returns -ENOTCONN.
|
|
The following calls to v4l2_async_nf_unregister() results in a NULL
|
|
pointer dereference.
|
|
Add the missing list head initializer.(CVE-2024-39464)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: starfive - Do not free stack buffer
|
|
|
|
RSA text data uses variable length buffer allocated in software stack.
|
|
Calling kfree on it causes undefined behaviour in subsequent operations.(CVE-2024-39478)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/i915/hwmon: Get rid of devm
|
|
|
|
When both hwmon and hwmon drvdata (on which hwmon depends) are device
|
|
managed resources, the expectation, on device unbind, is that hwmon will be
|
|
released before drvdata. However, in i915 there are two separate code
|
|
paths, which both release either drvdata or hwmon and either can be
|
|
released before the other. These code paths (for device unbind) are as
|
|
follows (see also the bug referenced below):
|
|
|
|
Call Trace:
|
|
release_nodes+0x11/0x70
|
|
devres_release_group+0xb2/0x110
|
|
component_unbind_all+0x8d/0xa0
|
|
component_del+0xa5/0x140
|
|
intel_pxp_tee_component_fini+0x29/0x40 [i915]
|
|
intel_pxp_fini+0x33/0x80 [i915]
|
|
i915_driver_remove+0x4c/0x120 [i915]
|
|
i915_pci_remove+0x19/0x30 [i915]
|
|
pci_device_remove+0x32/0xa0
|
|
device_release_driver_internal+0x19c/0x200
|
|
unbind_store+0x9c/0xb0
|
|
|
|
and
|
|
|
|
Call Trace:
|
|
release_nodes+0x11/0x70
|
|
devres_release_all+0x8a/0xc0
|
|
device_unbind_cleanup+0x9/0x70
|
|
device_release_driver_internal+0x1c1/0x200
|
|
unbind_store+0x9c/0xb0
|
|
|
|
This means that in i915, if use devm, we cannot gurantee that hwmon will
|
|
always be released before drvdata. Which means that we have a uaf if hwmon
|
|
sysfs is accessed when drvdata has been released but hwmon hasn't.
|
|
|
|
The only way out of this seems to be do get rid of devm_ and release/free
|
|
everything explicitly during device unbind.
|
|
|
|
v2: Change commit message and other minor code changes
|
|
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
|
|
v4: Eliminate potential static analyzer warning (Rodrigo)
|
|
Eliminate fetch_and_zero (Jani)
|
|
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)(CVE-2024-39479)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
kdb: Fix buffer overflow during tab-complete
|
|
|
|
Currently, when the user attempts symbol completion with the Tab key, kdb
|
|
will use strncpy() to insert the completed symbol into the command buffer.
|
|
Unfortunately it passes the size of the source buffer rather than the
|
|
destination to strncpy() with predictably horrible results. Most obviously
|
|
if the command buffer is already full but cp, the cursor position, is in
|
|
the middle of the buffer, then we will write past the end of the supplied
|
|
buffer.
|
|
|
|
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
|
|
calls plus explicit boundary checks to make sure we have enough space
|
|
before we start moving characters around.(CVE-2024-39480)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
|
|
|
|
In function bond_option_arp_ip_targets_set(), if newval->string is an
|
|
empty string, newval->string+1 will point to the byte after the
|
|
string, causing an out-of-bound read.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
|
|
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
|
|
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:364 [inline]
|
|
print_report+0xc1/0x5e0 mm/kasan/report.c:475
|
|
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
|
|
strlen+0x7d/0xa0 lib/string.c:418
|
|
__fortify_strlen include/linux/fortify-string.h:210 [inline]
|
|
in4_pton+0xa3/0x3f0 net/core/utils.c:130
|
|
bond_option_arp_ip_targets_set+0xc2/0x910
|
|
drivers/net/bonding/bond_options.c:1201
|
|
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
|
|
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
|
|
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
|
|
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
|
|
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
|
|
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
|
|
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x96a/0xd80 fs/read_write.c:584
|
|
ksys_write+0x122/0x250 fs/read_write.c:637
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
---[ end trace ]---
|
|
|
|
Fix it by adding a check of string length before using it.(CVE-2024-39487)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
|
|
to bug_table entries, and as a result the last entry in a bug table will
|
|
be ignored, potentially leading to an unexpected panic(). All prior
|
|
entries in the table will be handled correctly.
|
|
|
|
The arm64 ABI requires that struct fields of up to 8 bytes are
|
|
naturally-aligned, with padding added within a struct such that struct
|
|
are suitably aligned within arrays.
|
|
|
|
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
signed int file_disp; // 4 bytes
|
|
unsigned short line; // 2 bytes
|
|
unsigned short flags; // 2 bytes
|
|
}
|
|
|
|
... with 12 bytes total, requiring 4-byte alignment.
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
unsigned short flags; // 2 bytes
|
|
< implicit padding > // 2 bytes
|
|
}
|
|
|
|
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
|
|
padding, requiring 4-byte alginment.
|
|
|
|
When we create a bug_entry in assembly, we align the start of the entry
|
|
to 4 bytes, which implicitly handles padding for any prior entries.
|
|
However, we do not align the end of the entry, and so when
|
|
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
|
|
bytes.
|
|
|
|
For the main kernel image this is not a problem as find_bug() doesn't
|
|
depend on the trailing padding bytes when searching for entries:
|
|
|
|
for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
return bug;
|
|
|
|
However for modules, module_bug_finalize() depends on the trailing
|
|
bytes when calculating the number of entries:
|
|
|
|
mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
|
|
|
|
... and as the last bug_entry lacks the necessary padding bytes, this entry
|
|
will not be counted, e.g. in the case of a single entry:
|
|
|
|
sechdrs[i].sh_size == 6
|
|
sizeof(struct bug_entry) == 8;
|
|
|
|
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
|
|
|
|
Consequently module_find_bug() will miss the last bug_entry when it does:
|
|
|
|
for (i = 0; i < mod->num_bugs; ++i, ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
goto out;
|
|
|
|
... which can lead to a kenrel panic due to an unhandled bug.
|
|
|
|
This can be demonstrated with the following module:
|
|
|
|
static int __init buginit(void)
|
|
{
|
|
WARN(1, "hello\n");
|
|
return 0;
|
|
}
|
|
|
|
static void __exit bugexit(void)
|
|
{
|
|
}
|
|
|
|
module_init(buginit);
|
|
module_exit(bugexit);
|
|
MODULE_LICENSE("GPL");
|
|
|
|
... which will trigger a kernel panic when loaded:
|
|
|
|
------------[ cut here ]------------
|
|
hello
|
|
Unexpected kernel BRK exception at EL1
|
|
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in: hello(O+)
|
|
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
|
|
Hardware name: linux,dummy-virt (DT)
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : buginit+0x18/0x1000 [hello]
|
|
lr : buginit+0x18/0x1000 [hello]
|
|
sp : ffff800080533ae0
|
|
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
|
|
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
|
|
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
|
|
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
|
|
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
|
|
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
|
|
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
|
|
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
|
|
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
|
|
Call trace:
|
|
buginit+0x18/0x1000 [hello]
|
|
do_one_initcall+0x80/0x1c8
|
|
do_init_module+0x60/0x218
|
|
load_module+0x1ba4/0x1d70
|
|
__do_sys_init_module+0x198/0x1d0
|
|
__arm64_sys_init_module+0x1c/0x28
|
|
invoke_syscall+0x48/0x114
|
|
el0_svc
|
|
---truncated---(CVE-2024-39488)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix memleak in seg6_hmac_init_algo
|
|
|
|
seg6_hmac_init_algo returns without cleaning up the previous allocations
|
|
if one fails, so it's going to leak all that memory and the crypto tfms.
|
|
|
|
Update seg6_hmac_exit to only free the memory when allocated, so we can
|
|
reuse the code directly.(CVE-2024-39489)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sock_map: avoid race between sock_map_close and sk_psock_put
|
|
|
|
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
|
|
will happen when the last call of sk_psock_put is done. However,
|
|
sk_psock_drop may not have finished yet, so the close callback will still
|
|
point to sock_map_close despite psock being NULL.
|
|
|
|
This can be reproduced with a thread deleting an element from the sock map,
|
|
while the second one creates a socket, adds it to the map and closes it.
|
|
|
|
That will trigger the WARN_ON_ONCE:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Modules linked in:
|
|
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
|
|
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
|
|
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
|
|
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
|
|
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
|
|
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
|
|
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
|
|
FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
unix_release+0x87/0xc0 net/unix/af_unix.c:1048
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xbe/0x240 net/socket.c:1421
|
|
__fput+0x42b/0x8a0 fs/file_table.c:422
|
|
__do_sys_close fs/open.c:1556 [inline]
|
|
__se_sys_close fs/open.c:1541 [inline]
|
|
__x64_sys_close+0x7f/0x110 fs/open.c:1541
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7fb37d618070
|
|
Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
|
|
RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
|
|
RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
|
|
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
Use sk_psock, which will only check that the pointer is not been set to
|
|
NULL yet, which should only happen after the callbacks are restored. If,
|
|
then, a reference can still be gotten, we may call sk_psock_stop and cancel
|
|
psock->work.
|
|
|
|
As suggested by Paolo Abeni, reorder the condition so the control flow is
|
|
less convoluted.
|
|
|
|
After that change, the reproducer does not trigger the WARN_ON_ONCE
|
|
anymore.(CVE-2024-39500)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ionic: fix use after netif_napi_del()
|
|
|
|
When queues are started, netif_napi_add() and napi_enable() are called.
|
|
If there are 4 queues and only 3 queues are used for the current
|
|
configuration, only 3 queues' napi should be registered and enabled.
|
|
The ionic_qcq_enable() checks whether the .poll pointer is not NULL for
|
|
enabling only the using queue' napi. Unused queues' napi will not be
|
|
registered by netif_napi_add(), so the .poll pointer indicates NULL.
|
|
But it couldn't distinguish whether the napi was unregistered or not
|
|
because netif_napi_del() doesn't reset the .poll pointer to NULL.
|
|
So, ionic_qcq_enable() calls napi_enable() for the queue, which was
|
|
unregistered by netif_napi_del().
|
|
|
|
Reproducer:
|
|
ethtool -L <interface name> rx 1 tx 1 combined 0
|
|
ethtool -L <interface name> rx 0 tx 0 combined 1
|
|
ethtool -L <interface name> rx 0 tx 0 combined 4
|
|
|
|
Splat looks like:
|
|
kernel BUG at net/core/dev.c:6666!
|
|
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16
|
|
Workqueue: events ionic_lif_deferred_work [ionic]
|
|
RIP: 0010:napi_enable+0x3b/0x40
|
|
Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f
|
|
RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029
|
|
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28
|
|
RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001
|
|
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
|
|
R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20
|
|
FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x33/0x90
|
|
? do_trap+0xd9/0x100
|
|
? napi_enable+0x3b/0x40
|
|
? do_error_trap+0x83/0xb0
|
|
? napi_enable+0x3b/0x40
|
|
? napi_enable+0x3b/0x40
|
|
? exc_invalid_op+0x4e/0x70
|
|
? napi_enable+0x3b/0x40
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? napi_enable+0x3b/0x40
|
|
ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
process_one_work+0x145/0x360
|
|
worker_thread+0x2bb/0x3d0
|
|
? __pfx_worker_thread+0x10/0x10
|
|
kthread+0xcc/0x100
|
|
? __pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x2d/0x50
|
|
? __pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1a/0x30(CVE-2024-39502)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: fix possible race in __fib6_drop_pcpu_from()
|
|
|
|
syzbot found a race in __fib6_drop_pcpu_from() [1]
|
|
|
|
If compiler reads more than once (*ppcpu_rt),
|
|
second read could read NULL, if another cpu clears
|
|
the value in rt6_get_pcpu_route().
|
|
|
|
Add a READ_ONCE() to prevent this race.
|
|
|
|
Also add rcu_read_lock()/rcu_read_unlock() because
|
|
we rely on RCU protection while dereferencing pcpu_rt.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
|
|
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
Workqueue: netns cleanup_net
|
|
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
|
|
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
|
|
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
|
|
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
|
|
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
|
|
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
|
|
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
|
|
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
|
|
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
__fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
|
|
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
|
|
fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
|
|
fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
|
|
fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
|
|
fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
|
|
fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
|
|
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
|
|
fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
|
|
__fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
|
|
rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
|
|
rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
|
|
addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
|
|
addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
|
|
notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
|
|
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
|
|
call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
|
|
call_netdevice_notifiers net/core/dev.c:2044 [inline]
|
|
dev_close_many+0x333/0x6a0 net/core/dev.c:1585
|
|
unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
|
|
unregister_netdevice_many net/core/dev.c:11276 [inline]
|
|
default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
|
|
ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
|
|
cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
|
|
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
|
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
|
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
|
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40905)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: ensure snd_una is properly initialized on connect
|
|
|
|
This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
|
|
is properly initialized on connect"). It turns out that syzkaller can
|
|
trigger the retransmit after fallback and before processing any other
|
|
incoming packet - so that snd_una is still left uninitialized.
|
|
|
|
Address the issue explicitly initializing snd_una together with snd_nxt
|
|
and write_seq.(CVE-2024-40931)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
|
|
|
|
Fix a memory leak on logi_dj_recv_send_report() error path.(CVE-2024-40934)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
|
|
|
|
The cs35l41_hda_unbind() function clears the hda_component entry
|
|
matching it's index and then dereferences the codec pointer held in the
|
|
first element of the hda_component array, this is an issue when the
|
|
device index was 0.
|
|
|
|
Instead use the codec pointer stashed in the cs35l41_hda structure as it
|
|
will still be valid.(CVE-2024-40964)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: remove clear SB_INLINECRYPT flag in default_options
|
|
|
|
In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
|
|
If create new file or open file during this gap, these files
|
|
will not use inlinecrypt. Worse case, it may lead to data
|
|
corruption if wrappedkey_v0 is enable.
|
|
|
|
Thread A: Thread B:
|
|
|
|
-f2fs_remount -f2fs_file_open or f2fs_new_inode
|
|
-default_options
|
|
<- clear SB_INLINECRYPT flag
|
|
|
|
-fscrypt_select_encryption_impl
|
|
|
|
-parse_options
|
|
<- set SB_INLINECRYPT again(CVE-2024-40971)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpufreq: amd-pstate: fix memory leak on CPU EPP exit
|
|
|
|
The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
|
|
not freed in the analogous exit function, so fix that.
|
|
|
|
[ rjw: Subject and changelog edits ](CVE-2024-40997)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of critical. 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">Critical</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-1863</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36017</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36478</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36481</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36924</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36929</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36931</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36951</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38384</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38558</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38570</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38581</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-38586</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38614</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38620</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38632</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38661</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39462</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39464</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39478</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39479</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39480</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39487</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39488</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39489</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39500</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39502</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40905</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40931</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40934</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40964</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40971</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40997</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36017</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36478</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36481</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36924</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36929</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36931</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36951</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38384</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38558</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38570</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38581</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38583</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38586</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38614</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38620</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38632</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38661</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39462</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39464</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39478</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39479</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39480</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39487</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39488</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39489</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39500</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39502</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40905</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40931</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40934</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40964</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40971</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40997</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-6.6.0-34.0.0.41" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-34.0.0.41.oe2403.src.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
|
|
|
|
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
|
|
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
|
|
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
|
|
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
|
|
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
|
|
is not enough and a too small attribute might be cast to a
|
|
struct ifla_vf_vlan_info, this might result in an out of bands
|
|
read access when accessing the saved (casted) entry in ivvl.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36017</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
|
|
|
|
Writing 'power' and 'submit_queues' concurrently will trigger kernel
|
|
panic:
|
|
|
|
Test script:
|
|
|
|
modprobe null_blk nr_devices=0
|
|
mkdir -p /sys/kernel/config/nullb/nullb0
|
|
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
|
|
while true; do echo 1 > power; echo 0 > power; done
|
|
|
|
Test result:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000148
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
RIP: 0010:__lock_acquire+0x41d/0x28f0
|
|
Call Trace:
|
|
<TASK>
|
|
lock_acquire+0x121/0x450
|
|
down_write+0x5f/0x1d0
|
|
simple_recursive_removal+0x12f/0x5c0
|
|
blk_mq_debugfs_unregister_hctxs+0x7c/0x100
|
|
blk_mq_update_nr_hw_queues+0x4a3/0x720
|
|
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
|
|
nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
|
|
configfs_write_iter+0x119/0x1e0
|
|
vfs_write+0x326/0x730
|
|
ksys_write+0x74/0x150
|
|
|
|
This is because del_gendisk() can concurrent with
|
|
blk_mq_update_nr_hw_queues():
|
|
|
|
nullb_device_power_store nullb_apply_submit_queues
|
|
null_del_dev
|
|
del_gendisk
|
|
nullb_update_nr_hw_queues
|
|
if (!dev->nullb)
|
|
// still set while gendisk is deleted
|
|
return 0
|
|
blk_mq_update_nr_hw_queues
|
|
dev->nullb = NULL
|
|
|
|
Fix this problem by resuing the global mutex to protect
|
|
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36478</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:tracing/probes: fix error check in parse_btf_field()btf_find_struct_member() might return NULL or an error via theERR_PTR() macro. However, its caller in parse_btf_field() only checksfor the NULL condition. Fix this by using IS_ERR() and returning theerror up the stack.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36481</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
|
|
|
|
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
|
|
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
|
|
hbalock to avoid potential deadlock.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36924</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
net: core: reject skb_copy(_expand) for fraglist GSO skbs
|
|
|
|
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
|
|
invalid. Return NULL if such an skb is passed to skb_copy or
|
|
skb_copy_expand, in order to prevent a crash on a potential later
|
|
call to skb_gso_segment.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36929</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.7</BaseScore>
|
|
<Vector>AV:A/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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
s390/cio: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
|
|
userspace to that buffer. Later, we use scanf on this buffer but we don't
|
|
ensure that the string is terminated inside the buffer, this can lead to
|
|
OOB read when using scanf. Fix this issue by using memdup_user_nul instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36931</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
drm/amdkfd: range check cp bad op exception interrupts
|
|
|
|
Due to a CP interrupt bug, bad packet garbage exception codes are raised.
|
|
Do a range check so that the debugger and runtime do not receive garbage
|
|
codes.
|
|
Update the user api to guard exception code type checking as well.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36951</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
|
|
|
|
__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start
|
|
is being executed.
|
|
|
|
If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in
|
|
the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one
|
|
stat instance being added in blk_cgroup_bio_start(), then the local
|
|
list in __blkcg_rstat_flush() could be corrupted.
|
|
|
|
Fix the issue by adding one barrier.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38384</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>8.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:N/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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
net: openvswitch: fix overwriting ct original tuple for ICMPv6
|
|
|
|
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
|
|
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
|
|
- OVS_PACKET_ATTR_PACKET - Binary packet content.
|
|
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
|
|
|
|
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
|
|
with the metadata like conntrack state, input port, recirculation id,
|
|
etc. Then the packet itself gets parsed to populate the rest of the
|
|
keys from the packet headers.
|
|
|
|
Whenever the packet parsing code starts parsing the ICMPv6 header, it
|
|
first zeroes out fields in the key corresponding to Neighbor Discovery
|
|
information even if it is not an ND packet.
|
|
|
|
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
|
|
the space between 'nd' and 'ct_orig' that holds the original tuple
|
|
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
|
|
|
|
ND packets should not normally have conntrack state, so it's fine to
|
|
share the space, but normal ICMPv6 Echo packets or maybe other types of
|
|
ICMPv6 can have the state attached and it should not be overwritten.
|
|
|
|
The issue results in all but the last 4 bytes of the destination
|
|
address being wiped from the original conntrack tuple leading to
|
|
incorrect packet matching and potentially executing wrong actions
|
|
in case this packet recirculates within the datapath or goes back
|
|
to userspace.
|
|
|
|
ND fields should not be accessed in non-ND packets, so not clearing
|
|
them should be fine. Executing memset() only for actual ND packets to
|
|
avoid the issue.
|
|
|
|
Initializing the whole thing before parsing is needed because ND packet
|
|
may not contain all the options.
|
|
|
|
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
|
|
affect packets entering OVS datapath from network interfaces, because
|
|
in this case CT metadata is populated from skb after the packet is
|
|
already parsed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38558</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
gfs2: Fix potential glock use-after-free on unmount
|
|
|
|
When a DLM lockspace is released and there ares still locks in that
|
|
lockspace, DLM will unlock those locks automatically. Commit
|
|
fb6791d100d1b started exploiting this behavior to speed up filesystem
|
|
unmount: gfs2 would simply free glocks it didn't want to unlock and then
|
|
release the lockspace. This didn't take the bast callbacks for
|
|
asynchronous lock contention notifications into account, which remain
|
|
active until until a lock is unlocked or its lockspace is released.
|
|
|
|
To prevent those callbacks from accessing deallocated objects, put the
|
|
glocks that should not be unlocked on the sd_dead_glocks list, release
|
|
the lockspace, and only then free those glocks.
|
|
|
|
As an additional measure, ignore unexpected ast and bast callbacks if
|
|
the receiving glock is dead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38570</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
drm/amdgpu/mes: fix use-after-free issue
|
|
|
|
Delete fence fallback timer to fix the ramdom
|
|
use-after-free issue.
|
|
|
|
v2: move to amdgpu_mes.c</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38581</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
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-19</ReleaseDate>
|
|
<CVE>CVE-2024-38583</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
r8169: Fix possible ring buffer corruption on fragmented Tx packets.
|
|
|
|
An issue was found on the RTL8125b when transmitting small fragmented
|
|
packets, whereby invalid entries were inserted into the transmit ring
|
|
buffer, subsequently leading to calls to dma_unmap_single() with a null
|
|
address.
|
|
|
|
This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
|
|
which may occur when small packets are padded (to work around hardware
|
|
quirks) in rtl8169_tso_csum_v2().
|
|
|
|
To fix this, postpone inspecting nr_frags until after any padding has been
|
|
applied.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38586</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
openrisc: traps: Don't send signals to kernel mode threads
|
|
|
|
OpenRISC exception handling sends signals to user processes on floating
|
|
point exceptions and trap instructions (for debugging) among others.
|
|
There is a bug where the trap handling logic may send signals to kernel
|
|
threads, we should not send these signals to kernel threads, if that
|
|
happens we treat it as an error.
|
|
|
|
This patch adds conditions to die if the kernel receives these
|
|
exceptions in kernel mode code.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38614</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: HCI: Remove HCI_AMP support
|
|
|
|
Since BT_HS has been remove HCI_AMP controllers no longer has any use so
|
|
remove it along with the capability of creating AMP controllers.
|
|
|
|
Since we no longer need to differentiate between AMP and Primary
|
|
controllers, as only HCI_PRIMARY is left, this also remove
|
|
hdev->dev_type altogether.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38620</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
vfio/pci: fix potential memory leak in vfio_intx_enable()
|
|
|
|
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38632</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
s390/ap: Fix crash in AP internal function modify_bitmap()
|
|
|
|
A system crash like this
|
|
|
|
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
|
|
Fault in home space mode while using kernel ASCE.
|
|
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
|
|
Oops: 0038 ilc:3 [#1] PREEMPT SMP
|
|
Modules linked in: mlx5_ib ...
|
|
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
|
|
Hardware name: IBM 3931 A01 704 (LPAR)
|
|
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
|
|
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
|
|
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
|
|
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
|
|
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
|
|
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
|
|
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
|
|
0000014b75e7b600: 18b2 lr %r11,%r2
|
|
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
|
|
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
|
|
0000014b75e7b60c: a7680001 lhi %r6,1
|
|
0000014b75e7b610: 187b lr %r7,%r11
|
|
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
|
|
0000014b75e7b616: 18e9 lr %r14,%r9
|
|
Call Trace:
|
|
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
|
|
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
|
|
[<0000014b75e7b758>] apmask_store+0x68/0x140
|
|
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
|
|
[<0000014b75598524>] vfs_write+0x1b4/0x448
|
|
[<0000014b7559894c>] ksys_write+0x74/0x100
|
|
[<0000014b7618a440>] __do_syscall+0x268/0x328
|
|
[<0000014b761a3558>] system_call+0x70/0x98
|
|
INFO: lockdep is turned off.
|
|
Last Breaking-Event-Address:
|
|
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
|
|
Kernel panic - not syncing: Fatal exception: panic_on_oops
|
|
|
|
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
|
|
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
|
|
|
|
The fix is simple: use unsigned long values for the internal variables. The
|
|
correct checks are already in place in the function but a simple int for
|
|
the internal variables was used with the possibility to overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38661</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:clk: bcm: dvp: Assign ->num before accessing ->hwsCommit f316cdff8d67 ( clk: Annotate struct clk_hw_onecell_data with__counted_by ) annotated the hws member of struct clk_hw_onecell_data with __counted_by, which informs the bounds sanitizer about the numberof elements in hws, so that it can warn when hws is accessed out ofbounds. As noted in that change, the __counted_by member must beinitialized with the number of elements before the first array accesshappens, otherwise there will be a warning from each access prior to theinitialization because the number of elements is zero. This occurs inclk_dvp_probe() due to ->num being assigned after ->hws has beenaccessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type struct clk_hw *[] __counted_by(num) (aka struct clk_hw *[] )Move the ->num initialization to before the first access of ->hws, whichclears up the warning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39462</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Critical</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>9.8</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
media: v4l: async: Fix notifier list entry init
|
|
|
|
struct v4l2_async_notifier has several list_head members, but only
|
|
waiting_list and done_list are initialized. notifier_entry was kept
|
|
'zeroed' leading to an uninitialized list_head.
|
|
This results in a NULL-pointer dereference if csi2_async_register() fails,
|
|
e.g. node for remote endpoint is disabled, and returns -ENOTCONN.
|
|
The following calls to v4l2_async_nf_unregister() results in a NULL
|
|
pointer dereference.
|
|
Add the missing list head initializer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39464</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
crypto: starfive - Do not free stack buffer
|
|
|
|
RSA text data uses variable length buffer allocated in software stack.
|
|
Calling kfree on it causes undefined behaviour in subsequent operations.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39478</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
drm/i915/hwmon: Get rid of devm
|
|
|
|
When both hwmon and hwmon drvdata (on which hwmon depends) are device
|
|
managed resources, the expectation, on device unbind, is that hwmon will be
|
|
released before drvdata. However, in i915 there are two separate code
|
|
paths, which both release either drvdata or hwmon and either can be
|
|
released before the other. These code paths (for device unbind) are as
|
|
follows (see also the bug referenced below):
|
|
|
|
Call Trace:
|
|
release_nodes+0x11/0x70
|
|
devres_release_group+0xb2/0x110
|
|
component_unbind_all+0x8d/0xa0
|
|
component_del+0xa5/0x140
|
|
intel_pxp_tee_component_fini+0x29/0x40 [i915]
|
|
intel_pxp_fini+0x33/0x80 [i915]
|
|
i915_driver_remove+0x4c/0x120 [i915]
|
|
i915_pci_remove+0x19/0x30 [i915]
|
|
pci_device_remove+0x32/0xa0
|
|
device_release_driver_internal+0x19c/0x200
|
|
unbind_store+0x9c/0xb0
|
|
|
|
and
|
|
|
|
Call Trace:
|
|
release_nodes+0x11/0x70
|
|
devres_release_all+0x8a/0xc0
|
|
device_unbind_cleanup+0x9/0x70
|
|
device_release_driver_internal+0x1c1/0x200
|
|
unbind_store+0x9c/0xb0
|
|
|
|
This means that in i915, if use devm, we cannot gurantee that hwmon will
|
|
always be released before drvdata. Which means that we have a uaf if hwmon
|
|
sysfs is accessed when drvdata has been released but hwmon hasn't.
|
|
|
|
The only way out of this seems to be do get rid of devm_ and release/free
|
|
everything explicitly during device unbind.
|
|
|
|
v2: Change commit message and other minor code changes
|
|
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
|
|
v4: Eliminate potential static analyzer warning (Rodrigo)
|
|
Eliminate fetch_and_zero (Jani)
|
|
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39479</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39480</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
|
|
|
|
In function bond_option_arp_ip_targets_set(), if newval->string is an
|
|
empty string, newval->string+1 will point to the byte after the
|
|
string, causing an out-of-bound read.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
|
|
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
|
|
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:364 [inline]
|
|
print_report+0xc1/0x5e0 mm/kasan/report.c:475
|
|
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
|
|
strlen+0x7d/0xa0 lib/string.c:418
|
|
__fortify_strlen include/linux/fortify-string.h:210 [inline]
|
|
in4_pton+0xa3/0x3f0 net/core/utils.c:130
|
|
bond_option_arp_ip_targets_set+0xc2/0x910
|
|
drivers/net/bonding/bond_options.c:1201
|
|
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
|
|
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
|
|
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
|
|
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
|
|
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
|
|
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
|
|
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x96a/0xd80 fs/read_write.c:584
|
|
ksys_write+0x122/0x250 fs/read_write.c:637
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
---[ end trace ]---
|
|
|
|
Fix it by adding a check of string length before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39487</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
|
|
to bug_table entries, and as a result the last entry in a bug table will
|
|
be ignored, potentially leading to an unexpected panic(). All prior
|
|
entries in the table will be handled correctly.
|
|
|
|
The arm64 ABI requires that struct fields of up to 8 bytes are
|
|
naturally-aligned, with padding added within a struct such that struct
|
|
are suitably aligned within arrays.
|
|
|
|
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
signed int file_disp; // 4 bytes
|
|
unsigned short line; // 2 bytes
|
|
unsigned short flags; // 2 bytes
|
|
}
|
|
|
|
... with 12 bytes total, requiring 4-byte alignment.
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
unsigned short flags; // 2 bytes
|
|
< implicit padding > // 2 bytes
|
|
}
|
|
|
|
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
|
|
padding, requiring 4-byte alginment.
|
|
|
|
When we create a bug_entry in assembly, we align the start of the entry
|
|
to 4 bytes, which implicitly handles padding for any prior entries.
|
|
However, we do not align the end of the entry, and so when
|
|
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
|
|
bytes.
|
|
|
|
For the main kernel image this is not a problem as find_bug() doesn't
|
|
depend on the trailing padding bytes when searching for entries:
|
|
|
|
for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
return bug;
|
|
|
|
However for modules, module_bug_finalize() depends on the trailing
|
|
bytes when calculating the number of entries:
|
|
|
|
mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
|
|
|
|
... and as the last bug_entry lacks the necessary padding bytes, this entry
|
|
will not be counted, e.g. in the case of a single entry:
|
|
|
|
sechdrs[i].sh_size == 6
|
|
sizeof(struct bug_entry) == 8;
|
|
|
|
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
|
|
|
|
Consequently module_find_bug() will miss the last bug_entry when it does:
|
|
|
|
for (i = 0; i < mod->num_bugs; ++i, ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
goto out;
|
|
|
|
... which can lead to a kenrel panic due to an unhandled bug.
|
|
|
|
This can be demonstrated with the following module:
|
|
|
|
static int __init buginit(void)
|
|
{
|
|
WARN(1, "hello\n");
|
|
return 0;
|
|
}
|
|
|
|
static void __exit bugexit(void)
|
|
{
|
|
}
|
|
|
|
module_init(buginit);
|
|
module_exit(bugexit);
|
|
MODULE_LICENSE("GPL");
|
|
|
|
... which will trigger a kernel panic when loaded:
|
|
|
|
------------[ cut here ]------------
|
|
hello
|
|
Unexpected kernel BRK exception at EL1
|
|
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in: hello(O+)
|
|
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
|
|
Hardware name: linux,dummy-virt (DT)
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : buginit+0x18/0x1000 [hello]
|
|
lr : buginit+0x18/0x1000 [hello]
|
|
sp : ffff800080533ae0
|
|
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
|
|
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
|
|
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
|
|
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
|
|
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
|
|
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
|
|
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
|
|
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
|
|
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
|
|
Call trace:
|
|
buginit+0x18/0x1000 [hello]
|
|
do_one_initcall+0x80/0x1c8
|
|
do_init_module+0x60/0x218
|
|
load_module+0x1ba4/0x1d70
|
|
__do_sys_init_module+0x198/0x1d0
|
|
__arm64_sys_init_module+0x1c/0x28
|
|
invoke_syscall+0x48/0x114
|
|
el0_svc
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39488</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
ipv6: sr: fix memleak in seg6_hmac_init_algo
|
|
|
|
seg6_hmac_init_algo returns without cleaning up the previous allocations
|
|
if one fails, so it's going to leak all that memory and the crypto tfms.
|
|
|
|
Update seg6_hmac_exit to only free the memory when allocated, so we can
|
|
reuse the code directly.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39489</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
sock_map: avoid race between sock_map_close and sk_psock_put
|
|
|
|
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
|
|
will happen when the last call of sk_psock_put is done. However,
|
|
sk_psock_drop may not have finished yet, so the close callback will still
|
|
point to sock_map_close despite psock being NULL.
|
|
|
|
This can be reproduced with a thread deleting an element from the sock map,
|
|
while the second one creates a socket, adds it to the map and closes it.
|
|
|
|
That will trigger the WARN_ON_ONCE:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Modules linked in:
|
|
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
|
|
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
|
|
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
|
|
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
|
|
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
|
|
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
|
|
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
|
|
FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
unix_release+0x87/0xc0 net/unix/af_unix.c:1048
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xbe/0x240 net/socket.c:1421
|
|
__fput+0x42b/0x8a0 fs/file_table.c:422
|
|
__do_sys_close fs/open.c:1556 [inline]
|
|
__se_sys_close fs/open.c:1541 [inline]
|
|
__x64_sys_close+0x7f/0x110 fs/open.c:1541
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7fb37d618070
|
|
Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
|
|
RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
|
|
RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
|
|
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
Use sk_psock, which will only check that the pointer is not been set to
|
|
NULL yet, which should only happen after the callbacks are restored. If,
|
|
then, a reference can still be gotten, we may call sk_psock_stop and cancel
|
|
psock->work.
|
|
|
|
As suggested by Paolo Abeni, reorder the condition so the control flow is
|
|
less convoluted.
|
|
|
|
After that change, the reproducer does not trigger the WARN_ON_ONCE
|
|
anymore.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39500</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
ionic: fix use after netif_napi_del()
|
|
|
|
When queues are started, netif_napi_add() and napi_enable() are called.
|
|
If there are 4 queues and only 3 queues are used for the current
|
|
configuration, only 3 queues' napi should be registered and enabled.
|
|
The ionic_qcq_enable() checks whether the .poll pointer is not NULL for
|
|
enabling only the using queue' napi. Unused queues' napi will not be
|
|
registered by netif_napi_add(), so the .poll pointer indicates NULL.
|
|
But it couldn't distinguish whether the napi was unregistered or not
|
|
because netif_napi_del() doesn't reset the .poll pointer to NULL.
|
|
So, ionic_qcq_enable() calls napi_enable() for the queue, which was
|
|
unregistered by netif_napi_del().
|
|
|
|
Reproducer:
|
|
ethtool -L <interface name> rx 1 tx 1 combined 0
|
|
ethtool -L <interface name> rx 0 tx 0 combined 1
|
|
ethtool -L <interface name> rx 0 tx 0 combined 4
|
|
|
|
Splat looks like:
|
|
kernel BUG at net/core/dev.c:6666!
|
|
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16
|
|
Workqueue: events ionic_lif_deferred_work [ionic]
|
|
RIP: 0010:napi_enable+0x3b/0x40
|
|
Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f
|
|
RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029
|
|
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28
|
|
RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001
|
|
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
|
|
R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20
|
|
FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x33/0x90
|
|
? do_trap+0xd9/0x100
|
|
? napi_enable+0x3b/0x40
|
|
? do_error_trap+0x83/0xb0
|
|
? napi_enable+0x3b/0x40
|
|
? napi_enable+0x3b/0x40
|
|
? exc_invalid_op+0x4e/0x70
|
|
? napi_enable+0x3b/0x40
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? napi_enable+0x3b/0x40
|
|
ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
|
|
process_one_work+0x145/0x360
|
|
worker_thread+0x2bb/0x3d0
|
|
? __pfx_worker_thread+0x10/0x10
|
|
kthread+0xcc/0x100
|
|
? __pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x2d/0x50
|
|
? __pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1a/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39502</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
ipv6: fix possible race in __fib6_drop_pcpu_from()
|
|
|
|
syzbot found a race in __fib6_drop_pcpu_from() [1]
|
|
|
|
If compiler reads more than once (*ppcpu_rt),
|
|
second read could read NULL, if another cpu clears
|
|
the value in rt6_get_pcpu_route().
|
|
|
|
Add a READ_ONCE() to prevent this race.
|
|
|
|
Also add rcu_read_lock()/rcu_read_unlock() because
|
|
we rely on RCU protection while dereferencing pcpu_rt.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
|
|
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
Workqueue: netns cleanup_net
|
|
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
|
|
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
|
|
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
|
|
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
|
|
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
|
|
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
|
|
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
|
|
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
|
|
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
__fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
|
|
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
|
|
fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
|
|
fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
|
|
fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
|
|
fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
|
|
fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
|
|
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
|
|
fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
|
|
__fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
|
|
rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
|
|
rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
|
|
addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
|
|
addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
|
|
notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
|
|
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
|
|
call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
|
|
call_netdevice_notifiers net/core/dev.c:2044 [inline]
|
|
dev_close_many+0x333/0x6a0 net/core/dev.c:1585
|
|
unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
|
|
unregister_netdevice_many net/core/dev.c:11276 [inline]
|
|
default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
|
|
ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
|
|
cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
|
|
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
|
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
|
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
|
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40905</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
mptcp: ensure snd_una is properly initialized on connect
|
|
|
|
This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
|
|
is properly initialized on connect"). It turns out that syzkaller can
|
|
trigger the retransmit after fallback and before processing any other
|
|
incoming packet - so that snd_una is still left uninitialized.
|
|
|
|
Address the issue explicitly initializing snd_una together with snd_nxt
|
|
and write_seq.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40931</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
|
|
|
|
Fix a memory leak on logi_dj_recv_send_report() error path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40934</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
|
|
|
|
The cs35l41_hda_unbind() function clears the hda_component entry
|
|
matching it's index and then dereferences the codec pointer held in the
|
|
first element of the hda_component array, this is an issue when the
|
|
device index was 0.
|
|
|
|
Instead use the codec pointer stashed in the cs35l41_hda structure as it
|
|
will still be valid.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40964</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.7</BaseScore>
|
|
<Vector>AV:A/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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
f2fs: remove clear SB_INLINECRYPT flag in default_options
|
|
|
|
In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
|
|
If create new file or open file during this gap, these files
|
|
will not use inlinecrypt. Worse case, it may lead to data
|
|
corruption if wrappedkey_v0 is enable.
|
|
|
|
Thread A: Thread B:
|
|
|
|
-f2fs_remount -f2fs_file_open or f2fs_new_inode
|
|
-default_options
|
|
<- clear SB_INLINECRYPT flag
|
|
|
|
-fscrypt_select_encryption_impl
|
|
|
|
-parse_options
|
|
<- set SB_INLINECRYPT again</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40971</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</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:
|
|
|
|
cpufreq: amd-pstate: fix memory leak on CPU EPP exit
|
|
|
|
The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
|
|
not freed in the analogous exit function, so fix that.
|
|
|
|
[ rjw: Subject and changelog edits ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40997</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |