<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
	<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler security committee</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-SA-2024-1839</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2024-07-12</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2024-07-12</InitialReleaseDate>
		<CurrentReleaseDate>2024-07-12</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2024-07-12</Date>
		</Generator>
	</DocumentTracking>
	<DocumentNotes>
		<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
		<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</Note>
		<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hex_dump_to_buffer() and stack address used
in dump error output.(CVE-2021-47381)

In the Linux kernel, the following vulnerability has been resolved:

ARM: 9170/1: fix panic when kasan and kprobe are enabled

arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.

the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.

for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
&lt;cap_capable&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000	mov	r5, r0
e280006c	add	r0, r0, #108    ; 0x6c
e1a04001	mov	r4, r1
e1a06002	mov	r6, r2
e59fa090	ldr	sl, [pc, #144]  ;
ebfc7bf8	bl	c03aa4b4 &lt;__asan_load4&gt;
e595706c	ldr	r7, [r5, #108]  ; 0x6c
e2859014	add	r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 &lt;emulate_ldr&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e282803c	add	r8, r2, #60     ; 0x3c
e1a05000	mov	r5, r0
e7e37855	ubfx	r7, r5, #16, #4
e1a00008	mov	r0, r8
e1a09001	mov	r9, r1
e1a04002	mov	r4, r2
ebf35462	bl	c03c6530 &lt;__asan_load4&gt;
e357000f	cmp	r7, #15
e7e36655	ubfx	r6, r5, #12, #4
e205a00f	and	sl, r5, #15
0a000001	beq	c06f13bc &lt;emulate_ldr+0x38&gt;
e0840107	add	r0, r4, r7, lsl #2
ebf3545c	bl	c03c6530 &lt;__asan_load4&gt;
e084010a	add	r0, r4, sl, lsl #2
ebf3545a	bl	c03c6530 &lt;__asan_load4&gt;
e2890010	add	r0, r9, #16
ebf35458	bl	c03c6530 &lt;__asan_load4&gt;
e5990010	ldr	r0, [r9, #16]
e12fff30	blx	r0
e356000f	cm	r6, #15
1a000014	bne	c06f1430 &lt;emulate_ldr+0xac&gt;
e1a06000	mov	r6, r0
e2840040	add	r0, r4, #64     ; 0x40
......

when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c
r10: 00000000  r9 : c30897f4  r8 : ecd63cd4
r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98
r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 32c5387d  Table: 2d546400  DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix use-after-free after failure to create a snapshot

At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
then attach it to the transaction&apos;s list of pending snapshots. After that
we call btrfs_commit_transaction(), and if that returns an error we jump
to &apos;fail&apos; label, where we kfree() the pending snapshot structure. This can
result in a later use-after-free of the pending snapshot:

1) We allocated the pending snapshot and added it to the transaction&apos;s
   list of pending snapshots;

2) We call btrfs_commit_transaction(), and it fails either at the first
   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
   In both cases, we don&apos;t abort the transaction and we release our
   transaction handle. We jump to the &apos;fail&apos; label and free the pending
   snapshot structure. We return with the pending snapshot still in the
   transaction&apos;s list;

3) Another task commits the transaction. This time there&apos;s no error at
   all, and then during the transaction commit it accesses a pointer
   to the pending snapshot structure that the snapshot creation task
   has already freed, resulting in a user-after-free.

This issue could actually be detected by smatch, which produced the
following warning:

  fs/btrfs/ioctl.c:843 create_snapshot() warn: &apos;&amp;pending_snapshot-&gt;list&apos; not removed from list

So fix this by not having the snapshot creation ioctl directly add the
pending snapshot to the transaction&apos;s list. Instead add the pending
snapshot to the transaction handle, and then at btrfs_commit_transaction()
we add the snapshot to the list only when we can guarantee that any error
returned after that point will result in a transaction abort, in which
case the ioctl code can safely free the pending snapshot and no one can
access it anymore.(CVE-2022-48733)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Avoid field-overflowing memcpy()

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

Use flexible arrays instead of zero-element arrays (which look like they
are always overflowing) and split the cross-field memcpy() into two halves
that can be appropriately bounds-checked by the compiler.

We were doing:

	#define ETH_HLEN  14
	#define VLAN_HLEN  4
	...
	#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
	...
        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
	...
        struct mlx5_wqe_eth_seg  *eseg = &amp;wqe-&gt;eth;
        struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;
	...
	memcpy(eseg-&gt;inline_hdr.start, xdptxd-&gt;data, MLX5E_XDP_MIN_INLINE);

target is wqe-&gt;eth.inline_hdr.start (which the compiler sees as being
2 bytes in size), but copying 18, intending to write across start
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
wqe-&gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
(8 bytes).

struct mlx5e_tx_wqe {
        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */
        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */
        struct mlx5_wqe_data_seg   data[];               /*    32     0 */

        /* size: 32, cachelines: 1, members: 3 */
        /* last cacheline: 32 bytes */
};

struct mlx5_wqe_eth_seg {
        u8                         swp_outer_l4_offset;  /*     0     1 */
        u8                         swp_outer_l3_offset;  /*     1     1 */
        u8                         swp_inner_l4_offset;  /*     2     1 */
        u8                         swp_inner_l3_offset;  /*     3     1 */
        u8                         cs_flags;             /*     4     1 */
        u8                         swp_flags;            /*     5     1 */
        __be16                     mss;                  /*     6     2 */
        __be32                     flow_table_metadata;  /*     8     4 */
        union {
                struct {
                        __be16     sz;                   /*    12     2 */
                        u8         start[2];             /*    14     2 */
                } inline_hdr;                            /*    12     4 */
                struct {
                        __be16     type;                 /*    12     2 */
                        __be16     vlan_tci;             /*    14     2 */
                } insert;                                /*    12     4 */
                __be32             trailer;              /*    12     4 */
        };                                               /*    12     4 */

        /* size: 16, cachelines: 1, members: 9 */
        /* last cacheline: 16 bytes */
};

struct mlx5_wqe_data_seg {
        __be32                     byte_count;           /*     0     4 */
        __be32                     lkey;                 /*     4     4 */
        __be64                     addr;                 /*     8     8 */

        /* size: 16, cachelines: 1, members: 3 */
        /* last cacheline: 16 bytes */
};

So, split the memcpy() so the compiler can reason about the buffer
sizes.

&quot;pahole&quot; shows no size nor member offset changes to struct mlx5e_tx_wqe
nor struct mlx5e_umr_wqe. &quot;objdump -d&quot; shows no meaningful object
code changes (i.e. only source line number induced differences and
optimizations).(CVE-2022-48744)

In the Linux kernel, the following vulnerability has been resolved:

KVM: LAPIC: Also cancel preemption timer during SET_LAPIC

The below warning is splatting during guest reboot.

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_vcpu_ioctl+0x279/0x710 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fd39797350b

This can be triggered by not exposing tsc-deadline mode and doing a reboot in
the guest. The lapic_shutdown() function which is called in sys_reboot path
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
switch between tsc-deadline and oneshot/periodic, which can result in preemption
timer be cancelled in apic_update_lvtt(). However, We can&apos;t depend on this when
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
timer. Qemu will synchronise states around reset, let&apos;s cancel preemption timer
under KVM_SET_LAPIC.(CVE-2022-48765)

In the Linux kernel, the following vulnerability has been resolved:

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &lt;TASK&gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: Add date-&gt;evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753]  rfkill_set_block+0x92/0x160
[ 6104.969755]  rfkill_fop_write+0x136/0x1e0
[ 6104.969759]  __vfs_write+0x18/0x40
[ 6104.969761]  vfs_write+0xdf/0x1c0
[ 6104.969763]  ksys_write+0xb1/0xe0
[ 6104.969765]  __x64_sys_write+0x1a/0x20
[ 6104.969769]  do_syscall_64+0x51/0x180
[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)

In the Linux kernel, the following vulnerability has been resolved:

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.

When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU&apos;s vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.

In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&gt;prev_vector because the interrupt isn&apos;t currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn&apos;t reclaim apicd-&gt;prev_vector; instead, it simply resets both
apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.

To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the
interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
following a warning message, although theoretically it should never see
apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)

In the Linux kernel, the following vulnerability has been resolved:

of: dynamic: Synchronize of_changeset_destroy() with the devlink removals

In the following sequence:
  1) of_platform_depopulate()
  2) of_overlay_remove()

During the step 1, devices are destroyed and devlinks are removed.
During the step 2, OF nodes are destroyed but
__of_changeset_entry_destroy() can raise warnings related to missing
of_node_put():
  ERROR: memory leak, expected refcount 1 instead of 2 ...

Indeed, during the devlink removals performed at step 1, the removal
itself releasing the device (and the attached of_node) is done by a job
queued in a workqueue and so, it is done asynchronously with respect to
function calls.
When the warning is present, of_node_put() will be called but wrongly
too late from the workqueue job.

In order to be sure that any ongoing devlink removals are done before
the of_node destruction, synchronize the of_changeset_destroy() with the
devlink removals.(CVE-2024-35879)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_skbmod: prevent kernel-infoleak

syzbot found that tcf_skbmod_dump() was copying four bytes
from kernel stack to user space [1].

The issue here is that &apos;struct tc_skbmod&apos; has a four bytes hole.

We need to clear the structure before filling fields.

[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
 BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  instrument_copy_to_user include/linux/instrumented.h:114 [inline]
  copy_to_user_iter lib/iov_iter.c:24 [inline]
  iterate_ubuf include/linux/iov_iter.h:29 [inline]
  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
  iterate_and_advance include/linux/iov_iter.h:271 [inline]
  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  copy_to_iter include/linux/uio.h:196 [inline]
  simple_copy_to_iter net/core/datagram.c:532 [inline]
  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x2c4/0x340 net/socket.c:1068
  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
  __do_sys_recvfrom net/socket.c:2260 [inline]
  __se_sys_recvfrom net/socket.c:2256 [inline]
  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
  nlmsg_unicast include/net/netlink.h:1144 [inline]
  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
  tcf_add_notify net/sched/act_api.c:2048 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
  __sys_sendmsg net/socket.c:2667 [inline]
  __do_sys_sendmsg net/socket.c:2676 [inline]
  __se_sys_sendmsg net/socket.c:2674 [inline]
  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  __nla_put lib/nlattr.c:1041 [inline]
  nla_put+0x1c6/0x230 lib/nlattr.c:1099
  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
  tcf_action_dump_old net/sched/act_api.c:1191 [inline]
  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
  tcf_add_notify net/sched/act_api.c:2042 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
---truncated---(CVE-2024-35893)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr

Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:

1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.

2. Then, the whole ipv6_del_addr is executed for the given entry. The
   reference count drops to zero and kfree_rcu is scheduled.

3. ipv6_get_ifaddr continues and tries to increments the reference count
   (in6_ifa_hold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.

[   41.506330] refcount_t: addition on 0; use-after-free.
[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[   41.507413] Modules linked in: veth bridge stp llc
[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 &lt;0f&gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   41.516799] Call Trace:
[   41.517037]  &lt;TASK&gt;
[   41.517249]  ? __warn+0x7b/0x120
[   41.517535]  ? refcount_warn_saturate+0xa5/0x130
[   41.517923]  ? report_bug+0x164/0x190
[   41.518240]  ? handle_bug+0x3d/0x70
[   41.518541]  ? exc_invalid_op+0x17/0x70
[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
[   41.521325]  ? refcount_warn_saturate+0xa5/0x130
[   41.521708]  ipv6_get_ifaddr+0xda/0xe0
[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
[   41.523102]  ? netlink_unicast+0x30f/0x390
[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[   41.523832]  netlink_rcv_skb+0x53/0x100
[   41.524157]  netlink_unicast+0x23b/0x390
[   41.524484]  netlink_sendmsg+0x1f2/0x440
[   41.524826]  __sys_sendto+0x1d8/0x1f0
[   41.525145]  __x64_sys_sendto+0x1f/0x30
[   41.525467]  do_syscall_64+0xa5/0x1b0
[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
[   41.526213] RIP: 0033:0x7fbc4cfcea9a
[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[   41.527942] RSP: 002b:00007f
---truncated---(CVE-2024-35969)

In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix TASK_SIZE on 64-bit NOMMU

On NOMMU, userspace memory can come from anywhere in physical RAM. The
current definition of TASK_SIZE is wrong if any RAM exists above 4G,
causing spurious failures in the userspace access routines.(CVE-2024-35988)

In the Linux kernel, the following vulnerability has been resolved:

drm/arm/malidp: fix a possible null pointer dereference

In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.(CVE-2024-36014)

In the Linux kernel, the following vulnerability has been resolved:

tls: fix missing memory barrier in tls_init

In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

CPU0                               CPU1
-----                              -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)

// In update_sk_prot()
WRITE_ONCE(sk-&gt;sk_prot, tls_prots)     -(2)

                                   // In sock_common_setsockopt()
                                   READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()

                                   // In tls_{setsockopt,getsockopt}()
                                   ctx-&gt;sk_proto-&gt;setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx-&gt;sk_proto, causing NULL dereference.

To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is
initialized, we can ensure that ctx-&gt;sk_proto are visible when
changing sk-&gt;sk_prot.(CVE-2024-36489)

In the Linux kernel, the following vulnerability has been resolved:

virtio: delete vq in vp_find_vqs_msix() when request_irq() fails

When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
present in the list, free_irq() is called for the same vector. That
causes following splat:

[    0.414355] Trying to free already-free IRQ 27
[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
[    0.414510] Modules linked in:
[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 &lt;0f&gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
[    0.414540] Call Trace:
[    0.414540]  &lt;TASK&gt;
[    0.414540]  ? __warn+0x80/0x120
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  ? report_bug+0x164/0x190
[    0.414540]  ? handle_bug+0x3b/0x70
[    0.414540]  ? exc_invalid_op+0x17/0x70
[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  vp_del_vqs+0xc1/0x220
[    0.414540]  vp_find_vqs_msix+0x305/0x470
[    0.414540]  vp_find_vqs+0x3e/0x1a0
[    0.414540]  vp_modern_find_vqs+0x1b/0x70
[    0.414540]  init_vqs+0x387/0x600
[    0.414540]  virtnet_probe+0x50a/0xc80
[    0.414540]  virtio_dev_probe+0x1e0/0x2b0
[    0.414540]  really_probe+0xc0/0x2c0
[    0.414540]  ? __pfx___driver_attach+0x10/0x10
[    0.414540]  __driver_probe_device+0x73/0x120
[    0.414540]  driver_probe_device+0x1f/0xe0
[    0.414540]  __driver_attach+0x88/0x180
[    0.414540]  bus_for_each_dev+0x85/0xd0
[    0.414540]  bus_add_driver+0xec/0x1f0
[    0.414540]  driver_register+0x59/0x100
[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10
[    0.414540]  virtio_net_driver_init+0x90/0xb0
[    0.414540]  do_one_initcall+0x58/0x230
[    0.414540]  kernel_init_freeable+0x1a3/0x2d0
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  kernel_init+0x1a/0x1c0
[    0.414540]  ret_from_fork+0x31/0x50
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  ret_from_fork_asm+0x1a/0x30
[    0.414540]  &lt;/TASK&gt;

Fix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix crash on racing fsync and size-extending write into prealloc

We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():

  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/ctree.c:2620!
  invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]

With the following stack trace:

  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)
  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)
  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)
  #8  vfs_fsync_range (fs/sync.c:188:9)
  #9  vfs_fsync (fs/sync.c:202:9)
  #10 do_fsync (fs/sync.c:212:9)
  #11 __do_sys_fdatasync (fs/sync.c:225:9)
  #12 __se_sys_fdatasync (fs/sync.c:223:1)
  #13 __x64_sys_fdatasync (fs/sync.c:223:1)
  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)
  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)

So we&apos;re logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().

This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:

  &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][&quot;eb&quot;])
  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
  leaf 33439744 flags 0x100000000000000
  fs uuid e5bd3946-400c-4223-8923-190ef1f18677
  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
                  generation 7 transid 9 size 8192 nbytes 8473563889606862198
                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
                  sequence 204 flags 0x10(PREALLOC)
                  atime 1716417703.220000000 (2024-05-22 15:41:43)
                  ctime 1716417704.983333333 (2024-05-22 15:41:44)
                  mtime 1716417704.983333333 (2024-05-22 15:41:44)
                  otime 17592186044416.000000000 (559444-03-08 01:40:16)
          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
                  index 195 namelen 3 name: 193
          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
                  location key (0 UNKNOWN.0 0) type XATTR
                  transid 7 data_len 1 name_len 6
                  name: user.a
                  data a
          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
                  generation 9 type 1 (regular)
                  extent data disk byte 303144960 nr 12288
                  extent data offset 0 nr 4096 ram 12288
                  extent compression 0 (none)
          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 4096 nr 8192
          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 8192 nr 4096
  ...

So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.

Here is the state of 
---truncated---(CVE-2024-37354)

In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: Fix uninit-value in nci_rx_work

syzbot reported the following uninit-value access issue [1]

nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be
validated header size, payload size and total packet size before
processing the packet. If an invalid packet is detected, it should be
silently discarded.(CVE-2024-38381)

In the Linux kernel, the following vulnerability has been resolved:

media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries

The allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()
is followed with a dereference of mycs-&gt;yuv_scaler_binary after the
following call chain:

sh_css_pipe_load_binaries()
  |-&gt; load_video_binaries(mycs-&gt;yuv_scaler_binary == NULL)
  |
  |-&gt; sh_css_pipe_unload_binaries()
        |-&gt; unload_video_binaries()

In unload_video_binaries(), it calls to ia_css_binary_unload with argument
&amp;pipe-&gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the
same memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointer
dereference is triggered.(CVE-2024-38547)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index &apos;i&apos; exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).

The fix adds a check to ensure &apos;i&apos; is within bounds before accessing the
transfer function points. If &apos;i&apos; is out of bounds, an error message is
logged and the function returns false to indicate an error.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.red&apos; 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.green&apos; 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.blue&apos; 1025 &lt;= s32max(CVE-2024-38552)

In the Linux kernel, the following vulnerability has been resolved:

ax25: Fix reference count leak issue of net_device

There is a reference count leak issue of the object &quot;net_device&quot; in
ax25_dev_device_down(). When the ax25 device is shutting down, the
ax25_dev_device_down() drops the reference count of net_device one
or zero times depending on if we goto unlock_put or not, which will
cause memory leak.

In order to solve the above issue, decrease the reference count of
net_device after dev-&gt;ax25_ptr is set to null.(CVE-2024-38554)

In the Linux kernel, the following vulnerability has been resolved:

rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow

There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.

Use snprintf() with buffer size instead of sprintf().

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)

In the Linux kernel, the following vulnerability has been resolved:

crypto: bcm - Fix pointer arithmetic

In spu2_dump_omd() value of ptr is increased by ciph_key_len
instead of hash_iv_len which could lead to going beyond the
buffer boundaries.
Fix this bug by changing ciph_key_len to hash_iv_len.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential hang in nilfs_detach_log_writer()

Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.

Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:

nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***

Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.

The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix use-after-free of timer for log writer thread

Patch series &quot;nilfs2: fix log writer related issues&quot;.

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&apos;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:

RDMA/hns: Modify the print level of CQE error

Too much print may lead to a panic in kernel. Change ibdev_err() to
ibdev_err_ratelimited(), and change the printing level of cqe dump
to debug level.(CVE-2024-38590)

In the Linux kernel, the following vulnerability has been resolved:

md: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &lt;TASK&gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30

And the detailed process is as follows:

md_do_sync
 j = mddev-&gt;resync_min
 while (j &lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change

Root cause is that commit 301867b1c168 (&quot;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&quot;) return early from
md_bitmap_get_counter(), without setting returned blocks.

Fix this problem by always set returned blocks from
md_bitmap_get_counter&quot;(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&apos;t match array size still need to be fixed.(CVE-2024-38598)

In the Linux kernel, the following vulnerability has been resolved:

ax25: Fix reference count leak issues of ax25_dev

The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
count leak issue of the object &quot;ax25_dev&quot;.

Memory leak issue in ax25_addr_ax25dev():

The reference count of the object &quot;ax25_dev&quot; can be increased multiple
times in ax25_addr_ax25dev(). This will cause a memory leak.

Memory leak issues in ax25_dev_device_down():

The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
then increase the reference count when ax25_dev is added to ax25_dev_list.
As a result, the reference count of ax25_dev is 2. But when the device is
shutting down. The ax25_dev_device_down() drops the reference count once
or twice depending on if we goto unlock_put or not, which will cause
memory leak.

As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
issue of ax25_dev_device_down(), increase the reference count of ax25_dev
once in ax25_dev_device_up() and decrease the reference count of ax25_dev
after it is removed from the ax25_dev_list.(CVE-2024-38602)

In the Linux kernel, the following vulnerability has been resolved:

drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()

pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
fails, the irq vector is not freed, which leads to a memory leak.

Replace the devm_add_action with devm_add_action_or_reset to ensure
the irq vector can be destroyed when it fails.(CVE-2024-38603)

In the Linux kernel, the following vulnerability has been resolved:

cpufreq: exit() callback is optional

The exit() callback is optional and shouldn&apos;t be called without checking
a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn&apos;t
present.(CVE-2024-38615)

In the Linux kernel, the following vulnerability has been resolved:

media: stk1160: fix bounds checking in stk1160_copy_video()

The subtract in this condition is reversed.  The -&gt;length is the length
of the buffer.  The -&gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&apos;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.

Additionally, the -&gt;bytesused doesn&apos;t actually work for this purpose
because we&apos;re not writing to &quot;buf-&gt;mem + buf-&gt;bytesused&quot;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&gt;length bytes.(CVE-2024-38621)

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning:
	ntfs_set_label() error: __builtin_memcpy() &apos;uni-&gt;name&apos; too small (20 vs 256)(CVE-2024-38623)

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Check &apos;folio&apos; pointer for NULL

It can be NULL if bmap is called.(CVE-2024-38625)

In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Update uart_driver_registered on driver removal

The removal of the last MAX3100 device triggers the removal of
the driver. However, code doesn&apos;t update the respective global
variable and after insmod — rmmod — insmod cycle the kernel
oopses:

  max3100 spi-PRP0001:01: max3100_probe: adding port 0
  BUG: kernel NULL pointer dereference, address: 0000000000000408
  ...
  RIP: 0010:serial_core_register_port+0xa0/0x840
  ...
   max3100_probe+0x1b6/0x280 [max3100]
   spi_probe+0x8d/0xb0

Update the actual state so next time UART driver will be registered
again.

Hugo also noticed, that the error path in the probe also affected
by having the variable set, and not cleared. Instead of clearing it
move the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)

In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Lock port-&gt;lock when calling uart_handle_cts_change()

uart_handle_cts_change() has to be called with port lock taken,
Since we run it in a separate work, the lock may not be taken at
the time of running. Make sure that it&apos;s taken by explicitly doing
that. Without it we got a splat:

  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
  ...
  Workqueue: max3100-0 max3100_work [max3100]
  RIP: 0010:uart_handle_cts_change+0xa6/0xb0
  ...
   max3100_handlerx+0xc5/0x110 [max3100]
   max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)

In the Linux kernel, the following vulnerability has been resolved:

greybus: lights: check return of get_channel_from_mode

If channel for the given node is not found we return null from
get_channel_from_mode. Make sure we validate the return pointer
before using it in two of the missing places.

This was originally reported in [0]:
Found by Linux Verification Center (linuxtesting.org) with SVACE.

[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)

In the Linux kernel, the following vulnerability has been resolved:

dma-buf/sw-sync: don&apos;t enable IRQ from sync_print_obj()

Since commit a6aa8fca4d79 (&quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context&quot;) by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
inconsistent lock state warning.

Use plain spin_{lock,unlock}() for sync_print_obj(), for
sync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)

In the Linux kernel, the following vulnerability has been resolved:

net/9p: fix uninit-value in p9_client_rpc()

Syzbot with the help of KMSAN reported the following error:

BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 trace_9p_client_res include/trace/events/9p.h:146 [inline]
 p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
 __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2175 [inline]
 allocate_slab mm/slub.c:2338 [inline]
 new_slab+0x2de/0x1400 mm/slub.c:2391
 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
 __slab_alloc mm/slub.c:3610 [inline]
 __slab_alloc_node mm/slub.c:3663 [inline]
 slab_alloc_node mm/slub.c:3835 [inline]
 kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
 p9_tag_alloc net/9p/client.c:278 [inline]
 p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.

Fix this issue by assigning default values to p9_fcall fields
such as &apos;tag&apos; and (just in case KMSAN unearths something new) &apos;id&apos;
during the tag allocation stage.(CVE-2024-39301)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()

syzbot reports a kernel bug as below:

F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076

CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
 current_nat_addr fs/f2fs/node.h:213 [inline]
 f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
 f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
 ioctl_fiemap fs/ioctl.c:220 [inline]
 do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
 __do_sys_ioctl fs/ioctl.c:902 [inline]
 __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890
 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

The root cause is we missed to do sanity check on i_xattr_nid during
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
kasan bug report, fix it.(CVE-2024-39467)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.

openEuler Security has rated this update as having a security impact of 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-1839</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47381</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47618</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48733</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48744</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48765</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48772</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52833</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-31076</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35879</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35893</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35969</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35988</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36014</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36489</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37353</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37354</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38381</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38547</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38552</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38554</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38577</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38579</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38582</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38583</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38590</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38598</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38602</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38603</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38615</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38621</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38623</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38625</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38633</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38634</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38637</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38780</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39301</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39362</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39467</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47381</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47618</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48733</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48744</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48765</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48772</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52833</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-31076</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35879</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35893</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35969</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35988</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36014</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36489</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37353</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37354</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38381</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38547</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38552</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38554</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38577</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38579</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38582</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38583</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38590</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38598</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38602</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38603</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38615</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38621</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38623</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38625</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38633</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38634</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38637</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38780</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39301</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39362</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39467</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-5.10.0-218.0.0.121" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-218.0.0.121.oe2203sp3.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:

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hex_dump_to_buffer() and stack address used
in dump error output.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2021-47381</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

ARM: 9170/1: fix panic when kasan and kprobe are enabled

arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.

the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.

for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
&lt;cap_capable&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000	mov	r5, r0
e280006c	add	r0, r0, #108    ; 0x6c
e1a04001	mov	r4, r1
e1a06002	mov	r6, r2
e59fa090	ldr	sl, [pc, #144]  ;
ebfc7bf8	bl	c03aa4b4 &lt;__asan_load4&gt;
e595706c	ldr	r7, [r5, #108]  ; 0x6c
e2859014	add	r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 &lt;emulate_ldr&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e282803c	add	r8, r2, #60     ; 0x3c
e1a05000	mov	r5, r0
e7e37855	ubfx	r7, r5, #16, #4
e1a00008	mov	r0, r8
e1a09001	mov	r9, r1
e1a04002	mov	r4, r2
ebf35462	bl	c03c6530 &lt;__asan_load4&gt;
e357000f	cmp	r7, #15
e7e36655	ubfx	r6, r5, #12, #4
e205a00f	and	sl, r5, #15
0a000001	beq	c06f13bc &lt;emulate_ldr+0x38&gt;
e0840107	add	r0, r4, r7, lsl #2
ebf3545c	bl	c03c6530 &lt;__asan_load4&gt;
e084010a	add	r0, r4, sl, lsl #2
ebf3545a	bl	c03c6530 &lt;__asan_load4&gt;
e2890010	add	r0, r9, #16
ebf35458	bl	c03c6530 &lt;__asan_load4&gt;
e5990010	ldr	r0, [r9, #16]
e12fff30	blx	r0
e356000f	cm	r6, #15
1a000014	bne	c06f1430 &lt;emulate_ldr+0xac&gt;
e1a06000	mov	r6, r0
e2840040	add	r0, r4, #64     ; 0x40
......

when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c
r10: 00000000  r9 : c30897f4  r8 : ecd63cd4
r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98
r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 32c5387d  Table: 2d546400  DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2021-47618</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

btrfs: fix use-after-free after failure to create a snapshot

At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
then attach it to the transaction&apos;s list of pending snapshots. After that
we call btrfs_commit_transaction(), and if that returns an error we jump
to &apos;fail&apos; label, where we kfree() the pending snapshot structure. This can
result in a later use-after-free of the pending snapshot:

1) We allocated the pending snapshot and added it to the transaction&apos;s
   list of pending snapshots;

2) We call btrfs_commit_transaction(), and it fails either at the first
   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
   In both cases, we don&apos;t abort the transaction and we release our
   transaction handle. We jump to the &apos;fail&apos; label and free the pending
   snapshot structure. We return with the pending snapshot still in the
   transaction&apos;s list;

3) Another task commits the transaction. This time there&apos;s no error at
   all, and then during the transaction commit it accesses a pointer
   to the pending snapshot structure that the snapshot creation task
   has already freed, resulting in a user-after-free.

This issue could actually be detected by smatch, which produced the
following warning:

  fs/btrfs/ioctl.c:843 create_snapshot() warn: &apos;&amp;pending_snapshot-&gt;list&apos; not removed from list

So fix this by not having the snapshot creation ioctl directly add the
pending snapshot to the transaction&apos;s list. Instead add the pending
snapshot to the transaction handle, and then at btrfs_commit_transaction()
we add the snapshot to the list only when we can guarantee that any error
returned after that point will result in a transaction abort, in which
case the ioctl code can safely free the pending snapshot and no one can
access it anymore.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2022-48733</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.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-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

net/mlx5e: Avoid field-overflowing memcpy()

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

Use flexible arrays instead of zero-element arrays (which look like they
are always overflowing) and split the cross-field memcpy() into two halves
that can be appropriately bounds-checked by the compiler.

We were doing:

	#define ETH_HLEN  14
	#define VLAN_HLEN  4
	...
	#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
	...
        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
	...
        struct mlx5_wqe_eth_seg  *eseg = &amp;wqe-&gt;eth;
        struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;
	...
	memcpy(eseg-&gt;inline_hdr.start, xdptxd-&gt;data, MLX5E_XDP_MIN_INLINE);

target is wqe-&gt;eth.inline_hdr.start (which the compiler sees as being
2 bytes in size), but copying 18, intending to write across start
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
wqe-&gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
(8 bytes).

struct mlx5e_tx_wqe {
        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */
        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */
        struct mlx5_wqe_data_seg   data[];               /*    32     0 */

        /* size: 32, cachelines: 1, members: 3 */
        /* last cacheline: 32 bytes */
};

struct mlx5_wqe_eth_seg {
        u8                         swp_outer_l4_offset;  /*     0     1 */
        u8                         swp_outer_l3_offset;  /*     1     1 */
        u8                         swp_inner_l4_offset;  /*     2     1 */
        u8                         swp_inner_l3_offset;  /*     3     1 */
        u8                         cs_flags;             /*     4     1 */
        u8                         swp_flags;            /*     5     1 */
        __be16                     mss;                  /*     6     2 */
        __be32                     flow_table_metadata;  /*     8     4 */
        union {
                struct {
                        __be16     sz;                   /*    12     2 */
                        u8         start[2];             /*    14     2 */
                } inline_hdr;                            /*    12     4 */
                struct {
                        __be16     type;                 /*    12     2 */
                        __be16     vlan_tci;             /*    14     2 */
                } insert;                                /*    12     4 */
                __be32             trailer;              /*    12     4 */
        };                                               /*    12     4 */

        /* size: 16, cachelines: 1, members: 9 */
        /* last cacheline: 16 bytes */
};

struct mlx5_wqe_data_seg {
        __be32                     byte_count;           /*     0     4 */
        __be32                     lkey;                 /*     4     4 */
        __be64                     addr;                 /*     8     8 */

        /* size: 16, cachelines: 1, members: 3 */
        /* last cacheline: 16 bytes */
};

So, split the memcpy() so the compiler can reason about the buffer
sizes.

&quot;pahole&quot; shows no size nor member offset changes to struct mlx5e_tx_wqe
nor struct mlx5e_umr_wqe. &quot;objdump -d&quot; shows no meaningful object
code changes (i.e. only source line number induced differences and
optimizations).</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2022-48744</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

KVM: LAPIC: Also cancel preemption timer during SET_LAPIC

The below warning is splatting during guest reboot.

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_vcpu_ioctl+0x279/0x710 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fd39797350b

This can be triggered by not exposing tsc-deadline mode and doing a reboot in
the guest. The lapic_shutdown() function which is called in sys_reboot path
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
switch between tsc-deadline and oneshot/periodic, which can result in preemption
timer be cancelled in apic_update_lvtt(). However, We can&apos;t depend on this when
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
timer. Qemu will synchronise states around reset, let&apos;s cancel preemption timer
under KVM_SET_LAPIC.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2022-48765</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &lt;TASK&gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2022-48772</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

Bluetooth: btusb: Add date-&gt;evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753]  rfkill_set_block+0x92/0x160
[ 6104.969755]  rfkill_fop_write+0x136/0x1e0
[ 6104.969759]  __vfs_write+0x18/0x40
[ 6104.969761]  vfs_write+0xdf/0x1c0
[ 6104.969763]  ksys_write+0xb1/0xe0
[ 6104.969765]  __x64_sys_write+0x1a/0x20
[ 6104.969769]  do_syscall_64+0x51/0x180
[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2023-52833</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.

When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU&apos;s vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.

In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&gt;prev_vector because the interrupt isn&apos;t currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn&apos;t reclaim apicd-&gt;prev_vector; instead, it simply resets both
apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.

To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the
interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
following a warning message, although theoretically it should never see
apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-31076</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

of: dynamic: Synchronize of_changeset_destroy() with the devlink removals

In the following sequence:
  1) of_platform_depopulate()
  2) of_overlay_remove()

During the step 1, devices are destroyed and devlinks are removed.
During the step 2, OF nodes are destroyed but
__of_changeset_entry_destroy() can raise warnings related to missing
of_node_put():
  ERROR: memory leak, expected refcount 1 instead of 2 ...

Indeed, during the devlink removals performed at step 1, the removal
itself releasing the device (and the attached of_node) is done by a job
queued in a workqueue and so, it is done asynchronously with respect to
function calls.
When the warning is present, of_node_put() will be called but wrongly
too late from the workqueue job.

In order to be sure that any ongoing devlink removals are done before
the of_node destruction, synchronize the of_changeset_destroy() with the
devlink removals.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-35879</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_skbmod: prevent kernel-infoleak

syzbot found that tcf_skbmod_dump() was copying four bytes
from kernel stack to user space [1].

The issue here is that &apos;struct tc_skbmod&apos; has a four bytes hole.

We need to clear the structure before filling fields.

[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
 BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  instrument_copy_to_user include/linux/instrumented.h:114 [inline]
  copy_to_user_iter lib/iov_iter.c:24 [inline]
  iterate_ubuf include/linux/iov_iter.h:29 [inline]
  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
  iterate_and_advance include/linux/iov_iter.h:271 [inline]
  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  copy_to_iter include/linux/uio.h:196 [inline]
  simple_copy_to_iter net/core/datagram.c:532 [inline]
  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x2c4/0x340 net/socket.c:1068
  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
  __do_sys_recvfrom net/socket.c:2260 [inline]
  __se_sys_recvfrom net/socket.c:2256 [inline]
  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
  nlmsg_unicast include/net/netlink.h:1144 [inline]
  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
  tcf_add_notify net/sched/act_api.c:2048 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
  __sys_sendmsg net/socket.c:2667 [inline]
  __do_sys_sendmsg net/socket.c:2676 [inline]
  __se_sys_sendmsg net/socket.c:2674 [inline]
  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  __nla_put lib/nlattr.c:1041 [inline]
  nla_put+0x1c6/0x230 lib/nlattr.c:1099
  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
  tcf_action_dump_old net/sched/act_api.c:1191 [inline]
  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
  tcf_add_notify net/sched/act_api.c:2042 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
---truncated---</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-35893</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr

Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:

1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.

2. Then, the whole ipv6_del_addr is executed for the given entry. The
   reference count drops to zero and kfree_rcu is scheduled.

3. ipv6_get_ifaddr continues and tries to increments the reference count
   (in6_ifa_hold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.

[   41.506330] refcount_t: addition on 0; use-after-free.
[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[   41.507413] Modules linked in: veth bridge stp llc
[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 &lt;0f&gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   41.516799] Call Trace:
[   41.517037]  &lt;TASK&gt;
[   41.517249]  ? __warn+0x7b/0x120
[   41.517535]  ? refcount_warn_saturate+0xa5/0x130
[   41.517923]  ? report_bug+0x164/0x190
[   41.518240]  ? handle_bug+0x3d/0x70
[   41.518541]  ? exc_invalid_op+0x17/0x70
[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
[   41.521325]  ? refcount_warn_saturate+0xa5/0x130
[   41.521708]  ipv6_get_ifaddr+0xda/0xe0
[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
[   41.523102]  ? netlink_unicast+0x30f/0x390
[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[   41.523832]  netlink_rcv_skb+0x53/0x100
[   41.524157]  netlink_unicast+0x23b/0x390
[   41.524484]  netlink_sendmsg+0x1f2/0x440
[   41.524826]  __sys_sendto+0x1d8/0x1f0
[   41.525145]  __x64_sys_sendto+0x1f/0x30
[   41.525467]  do_syscall_64+0xa5/0x1b0
[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
[   41.526213] RIP: 0033:0x7fbc4cfcea9a
[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[   41.527942] RSP: 002b:00007f
---truncated---</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-35969</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

riscv: Fix TASK_SIZE on 64-bit NOMMU

On NOMMU, userspace memory can come from anywhere in physical RAM. The
current definition of TASK_SIZE is wrong if any RAM exists above 4G,
causing spurious failures in the userspace access routines.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-35988</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

drm/arm/malidp: fix a possible null pointer dereference

In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-36014</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

tls: fix missing memory barrier in tls_init

In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

CPU0                               CPU1
-----                              -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)

// In update_sk_prot()
WRITE_ONCE(sk-&gt;sk_prot, tls_prots)     -(2)

                                   // In sock_common_setsockopt()
                                   READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()

                                   // In tls_{setsockopt,getsockopt}()
                                   ctx-&gt;sk_proto-&gt;setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx-&gt;sk_proto, causing NULL dereference.

To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is
initialized, we can ensure that ctx-&gt;sk_proto are visible when
changing sk-&gt;sk_prot.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-36489</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.7</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

virtio: delete vq in vp_find_vqs_msix() when request_irq() fails

When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
present in the list, free_irq() is called for the same vector. That
causes following splat:

[    0.414355] Trying to free already-free IRQ 27
[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
[    0.414510] Modules linked in:
[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 &lt;0f&gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
[    0.414540] Call Trace:
[    0.414540]  &lt;TASK&gt;
[    0.414540]  ? __warn+0x80/0x120
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  ? report_bug+0x164/0x190
[    0.414540]  ? handle_bug+0x3b/0x70
[    0.414540]  ? exc_invalid_op+0x17/0x70
[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  vp_del_vqs+0xc1/0x220
[    0.414540]  vp_find_vqs_msix+0x305/0x470
[    0.414540]  vp_find_vqs+0x3e/0x1a0
[    0.414540]  vp_modern_find_vqs+0x1b/0x70
[    0.414540]  init_vqs+0x387/0x600
[    0.414540]  virtnet_probe+0x50a/0xc80
[    0.414540]  virtio_dev_probe+0x1e0/0x2b0
[    0.414540]  really_probe+0xc0/0x2c0
[    0.414540]  ? __pfx___driver_attach+0x10/0x10
[    0.414540]  __driver_probe_device+0x73/0x120
[    0.414540]  driver_probe_device+0x1f/0xe0
[    0.414540]  __driver_attach+0x88/0x180
[    0.414540]  bus_for_each_dev+0x85/0xd0
[    0.414540]  bus_add_driver+0xec/0x1f0
[    0.414540]  driver_register+0x59/0x100
[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10
[    0.414540]  virtio_net_driver_init+0x90/0xb0
[    0.414540]  do_one_initcall+0x58/0x230
[    0.414540]  kernel_init_freeable+0x1a3/0x2d0
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  kernel_init+0x1a/0x1c0
[    0.414540]  ret_from_fork+0x31/0x50
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  ret_from_fork_asm+0x1a/0x30
[    0.414540]  &lt;/TASK&gt;

Fix this by calling deleting the current vq when request_irq() fails.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-37353</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Low</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>3.9</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

btrfs: fix crash on racing fsync and size-extending write into prealloc

We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():

  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/ctree.c:2620!
  invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]

With the following stack trace:

  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)
  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)
  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)
  #8  vfs_fsync_range (fs/sync.c:188:9)
  #9  vfs_fsync (fs/sync.c:202:9)
  #10 do_fsync (fs/sync.c:212:9)
  #11 __do_sys_fdatasync (fs/sync.c:225:9)
  #12 __se_sys_fdatasync (fs/sync.c:223:1)
  #13 __x64_sys_fdatasync (fs/sync.c:223:1)
  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)
  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)

So we&apos;re logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().

This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:

  &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][&quot;eb&quot;])
  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
  leaf 33439744 flags 0x100000000000000
  fs uuid e5bd3946-400c-4223-8923-190ef1f18677
  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
                  generation 7 transid 9 size 8192 nbytes 8473563889606862198
                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
                  sequence 204 flags 0x10(PREALLOC)
                  atime 1716417703.220000000 (2024-05-22 15:41:43)
                  ctime 1716417704.983333333 (2024-05-22 15:41:44)
                  mtime 1716417704.983333333 (2024-05-22 15:41:44)
                  otime 17592186044416.000000000 (559444-03-08 01:40:16)
          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
                  index 195 namelen 3 name: 193
          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
                  location key (0 UNKNOWN.0 0) type XATTR
                  transid 7 data_len 1 name_len 6
                  name: user.a
                  data a
          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
                  generation 9 type 1 (regular)
                  extent data disk byte 303144960 nr 12288
                  extent data offset 0 nr 4096 ram 12288
                  extent compression 0 (none)
          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 4096 nr 8192
          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 8192 nr 4096
  ...

So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.

Here is the state of 
---truncated---</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-37354</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.1</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

nfc: nci: Fix uninit-value in nci_rx_work

syzbot reported the following uninit-value access issue [1]

nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be
validated header size, payload size and total packet size before
processing the packet. If an invalid packet is detected, it should be
silently discarded.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38381</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>None</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.3</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries

The allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()
is followed with a dereference of mycs-&gt;yuv_scaler_binary after the
following call chain:

sh_css_pipe_load_binaries()
  |-&gt; load_video_binaries(mycs-&gt;yuv_scaler_binary == NULL)
  |
  |-&gt; sh_css_pipe_unload_binaries()
        |-&gt; unload_video_binaries()

In unload_video_binaries(), it calls to ia_css_binary_unload with argument
&amp;pipe-&gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the
same memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointer
dereference is triggered.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38547</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index &apos;i&apos; exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).

The fix adds a check to ensure &apos;i&apos; is within bounds before accessing the
transfer function points. If &apos;i&apos; is out of bounds, an error message is
logged and the function returns false to indicate an error.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.red&apos; 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.green&apos; 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow &apos;output_tf-&gt;tf_pts.blue&apos; 1025 &lt;= s32max</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38552</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.1</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

ax25: Fix reference count leak issue of net_device

There is a reference count leak issue of the object &quot;net_device&quot; in
ax25_dev_device_down(). When the ax25 device is shutting down, the
ax25_dev_device_down() drops the reference count of net_device one
or zero times depending on if we goto unlock_put or not, which will
cause memory leak.

In order to solve the above issue, decrease the reference count of
net_device after dev-&gt;ax25_ptr is set to null.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38554</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.1</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow

There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.

Use snprintf() with buffer size instead of sprintf().

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38577</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.4</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

crypto: bcm - Fix pointer arithmetic

In spu2_dump_omd() value of ptr is increased by ciph_key_len
instead of hash_iv_len which could lead to going beyond the
buffer boundaries.
Fix this bug by changing ciph_key_len to hash_iv_len.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38579</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.1</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

nilfs2: fix potential hang in nilfs_detach_log_writer()

Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.

Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:

nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***

Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.

The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38582</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>None</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>0.0</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

nilfs2: fix use-after-free of timer for log writer thread

Patch series &quot;nilfs2: fix log writer related issues&quot;.

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&apos;s lifetime.

Fix this issue by limiting the use of sc_timer only while the log writer
thread is alive.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38583</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.0</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

RDMA/hns: Modify the print level of CQE error

Too much print may lead to a panic in kernel. Change ibdev_err() to
ibdev_err_ratelimited(), and change the printing level of cqe dump
to debug level.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38590</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.7</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

md: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &lt;TASK&gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30

And the detailed process is as follows:

md_do_sync
 j = mddev-&gt;resync_min
 while (j &lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change

Root cause is that commit 301867b1c168 (&quot;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&quot;) return early from
md_bitmap_get_counter(), without setting returned blocks.

Fix this problem by always set returned blocks from
md_bitmap_get_counter&quot;(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn&apos;t match array size still need to be fixed.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38598</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

ax25: Fix reference count leak issues of ax25_dev

The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
count leak issue of the object &quot;ax25_dev&quot;.

Memory leak issue in ax25_addr_ax25dev():

The reference count of the object &quot;ax25_dev&quot; can be increased multiple
times in ax25_addr_ax25dev(). This will cause a memory leak.

Memory leak issues in ax25_dev_device_down():

The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
then increase the reference count when ax25_dev is added to ax25_dev_list.
As a result, the reference count of ax25_dev is 2. But when the device is
shutting down. The ax25_dev_device_down() drops the reference count once
or twice depending on if we goto unlock_put or not, which will cause
memory leak.

As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
issue of ax25_dev_device_down(), increase the reference count of ax25_dev
once in ax25_dev_device_up() and decrease the reference count of ax25_dev
after it is removed from the ax25_dev_list.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38602</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()

pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
fails, the irq vector is not freed, which leads to a memory leak.

Replace the devm_add_action with devm_add_action_or_reset to ensure
the irq vector can be destroyed when it fails.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38603</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

cpufreq: exit() callback is optional

The exit() callback is optional and shouldn&apos;t be called without checking
a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn&apos;t
present.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38615</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

media: stk1160: fix bounds checking in stk1160_copy_video()

The subtract in this condition is reversed.  The -&gt;length is the length
of the buffer.  The -&gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it&apos;s unsigned then the result
is a very high positive value.  That means the overflow check is never
true.

Additionally, the -&gt;bytesused doesn&apos;t actually work for this purpose
because we&apos;re not writing to &quot;buf-&gt;mem + buf-&gt;bytesused&quot;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&gt;length bytes.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38621</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning:
	ntfs_set_label() error: __builtin_memcpy() &apos;uni-&gt;name&apos; too small (20 vs 256)</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38623</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</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-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

fs/ntfs3: Check &apos;folio&apos; pointer for NULL

It can be NULL if bmap is called.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38625</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</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:

serial: max3100: Update uart_driver_registered on driver removal

The removal of the last MAX3100 device triggers the removal of
the driver. However, code doesn&apos;t update the respective global
variable and after insmod — rmmod — insmod cycle the kernel
oopses:

  max3100 spi-PRP0001:01: max3100_probe: adding port 0
  BUG: kernel NULL pointer dereference, address: 0000000000000408
  ...
  RIP: 0010:serial_core_register_port+0xa0/0x840
  ...
   max3100_probe+0x1b6/0x280 [max3100]
   spi_probe+0x8d/0xb0

Update the actual state so next time UART driver will be registered
again.

Hugo also noticed, that the error path in the probe also affected
by having the variable set, and not cleared. Instead of clearing it
move the assignment after the successfull uart_register_driver() call.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38633</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Lock port-&gt;lock when calling uart_handle_cts_change()

uart_handle_cts_change() has to be called with port lock taken,
Since we run it in a separate work, the lock may not be taken at
the time of running. Make sure that it&apos;s taken by explicitly doing
that. Without it we got a splat:

  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
  ...
  Workqueue: max3100-0 max3100_work [max3100]
  RIP: 0010:uart_handle_cts_change+0xa6/0xb0
  ...
   max3100_handlerx+0xc5/0x110 [max3100]
   max3100_work+0x12a/0x340 [max3100]</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38634</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

greybus: lights: check return of get_channel_from_mode

If channel for the given node is not found we return null from
get_channel_from_mode. Make sure we validate the return pointer
before using it in two of the missing places.

This was originally reported in [0]:
Found by Linux Verification Center (linuxtesting.org) with SVACE.

[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38637</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Low</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>3.9</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ( dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context ) by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-38780</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/9p: fix uninit-value in p9_client_rpc()

Syzbot with the help of KMSAN reported the following error:

BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 trace_9p_client_res include/trace/events/9p.h:146 [inline]
 p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
 __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2175 [inline]
 allocate_slab mm/slub.c:2338 [inline]
 new_slab+0x2de/0x1400 mm/slub.c:2391
 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
 __slab_alloc mm/slub.c:3610 [inline]
 __slab_alloc_node mm/slub.c:3663 [inline]
 slab_alloc_node mm/slub.c:3835 [inline]
 kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
 p9_tag_alloc net/9p/client.c:278 [inline]
 p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.

Fix this issue by assigning default values to p9_fcall fields
such as &apos;tag&apos; and (just in case KMSAN unearths something new) &apos;id&apos;
during the tag allocation stage.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-39301</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-39362</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()

syzbot reports a kernel bug as below:

F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076

CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
 current_nat_addr fs/f2fs/node.h:213 [inline]
 f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
 f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
 ioctl_fiemap fs/ioctl.c:220 [inline]
 do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
 __do_sys_ioctl fs/ioctl.c:902 [inline]
 __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890
 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

The root cause is we missed to do sanity check on i_xattr_nid during
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
kasan bug report, fix it.</Note>
		</Notes>
		<ReleaseDate>2024-07-12</ReleaseDate>
		<CVE>CVE-2024-39467</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-12</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>