Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts
In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.
When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->pr…
In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.
When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->pr…
In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Harden accesses to the reset domains
Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors accesses. In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved: netfilter:…
Affected: openEuler:22.03-LTS-SP1: kernel
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: scsi: iscsi: Fix iscsi_task use after free Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task. This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427) In the Linux kernel, the following vulnerability has been resolved: spi: Fix deadlock when adding SPI controllers on SPI buses Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of d…
kernel: improper input validation may lead to privilege escalation kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: Linux ebpf logic vulnerability leads to critical memory read and write gaining root privileges kernel: local privileges escalation in kernel/bpf/verifier.c kernel: nvme-tcp: fix UAF when detecting digest errors kernel: xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create kernel: bpf: Fix crash due to out of bounds access into reg2btf_ids. kernel: x86/mm: Randomize per-cpu entry area kernel: mm/sparsemem: fix race in accessing memory_section->usage kernel: blk-mq: fix IO hang from sbitmap wakeup race kernel: mac802154: fix llsec key resources release in mac802154_llsec_key_del kernel: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline kernel: vt: fix unicode buffer corruption when deleting characters kernel: mptcp: ensure snd_nxt is properly initialized on connect kernel: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING kernel: bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE kernel: drm/radeon: fix UBSAN warning in kv_dpm.c kernel: bpf: Fix overrunning reservations in ringbuf kernel: xfs: add bounds checking to xlog_recover_process_data kernel: sched/deadline: Fix task_struct reference leak kernel: mptcp: pm: Fix uaf in __timer_delete_sync
kernel: tracing: Restructure trace_clock_global() to never block kernel: ensure definition of the fixmap area is in a limit kernel: net: ieee802154: fix null deref in parse dev addr kernel: isdn: mISDN: netjet: Fix crash in nj_probe kernel: tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized kernel: irqchip/gic-v3-its: Fix potential VPE leak on error kernel: netfilter: conntrack: serialize hash resizes and cleanups kernel: userfaultfd: fix a race between writeprotect and exit_mmap() kernel: isdn: mISDN: Fix sleeping function called from invalid context kernel: mm: khugepaged: skip huge page collapse for special files kernel: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() kernel: ovl: fix warning in ovl_create_real() kernel: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: net: amd-xgbe: Fix skb data length underflow kernel: block: Fix wrong offset in bio_truncate() kernel: net: fix information leakage in /proc/net/ptype kernel: cifs: Fix memory leak when build ntlmssp negotiate blob failed kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: Local information disclosure on Intel(R) Atom(R) processors kernel: powerpc: Fix access beyond end of drmem array kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: use-after-free in kv_parse_power_table kernel: null po…
In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Harden accesses to the reset domains
Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors accesses. In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved: netfilter:…
Security update for the Linux Kernel
Affected: Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 177 more
In the Linux kernel, the following vulnerability has been resolved: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vec…
Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.