CVE-2022-49289

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().(CVE-2022-49121)

In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: <IRQ>kernel: dump_stack+0x66/0x81kernel: __schedule_bug.cold.90+0x5/0x1dkernel: __schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: schedule_timeout+0x26d/0x3b0kernel: wait_for_completion+0xb4/0x140kernel: ? wake_up_q+0x70/0x70kernel: __wait_rcu_gp+0x12c/0x160kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel: synchronize_sched+0x6c/0x80kernel: ? call_rcu_bh+0x20/0x20kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]kernel: device_for_each_child+0x54/0x90kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel: __handle_irq_event_percpu+0x40/0x180kernel: handle_irq_event_percpu+0x30/0x80kernel: handle_irq_event+0x36/0x60(CVE-2022-49156)

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

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inline_dots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfolio_mark_dirty+0x33/0x50f2fs_add_regular_entry+0x541/0xad0 [f2fs]f2fs_add_dentry+0x6c/0xb0 [f2fs]f2fs_do_add_link+0x182/0x230 [f2fs]__recover_dot_dentries+0x2d6/0x470 [f2fs]f2fs_lookup+0x5af/0x6a0 [f2fs]__lookup_slow+0xac/0x200lookup_slow+0x45/0x70walk_component+0x16c/0x250path_lookupat+0x8b/0x1f0filename_lookup+0xef/0x250user_path_at_empty+0x46/0x70vfs_statx+0x98/0x190__do_sys_newlstat+0x41/0x90__x64_sys_newlstat+0x1a/0x30do_syscall_64+0x37/0xb0entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping->a_ops field, so, in a fuzzed image, if inline_dots flag wastagged in special file, during lookup(), when f2fs runs into__recover_dot_dentries(), it will cause NULL pointer access oncef2fs_add_regular_entry() calls…

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

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

parisc: Fix double SIGFPE crash

Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.

When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.

The issue can be reproduced with this test program:

root@parisc:~# cat fpe.c

static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }

int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }

root@parisc:# gcc fpe.c -lm root@parisc:# ./a.out Floating point exception

root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=81921024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)

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

drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries.

Return -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)

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

arm64/fpsimd: signal: Fix restoration of SVE context

When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.

(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.

This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM…

Root has patched CVE-2022-49289 in the linux package for Root:Debian:11. Multiple fixed versions available.

In the Linux kernel, the following vulnerability has been resolved: uaccess: fix integer overflow on access_ok() Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not. Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.