Page 288 of 2226 results (0.008 seconds)

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cgroup: cgroup_get_from_id() debe verificar que el kn buscado sea un directorio. cgroup tiene que ser un directorio kernfs; de lo contrario, se produce un pánico en el kernel, especialmente la identificación de cgroup se proporciona desde el espacio de usuario. A flaw was found in the Linux kernel in which certain cgroup configurations could cause a kernel panic, resulting in a Denial of Service. • https://git.kernel.org/stable/c/6b658c4863c15936872a93c9ee879043bf6393c9 https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37 https://access.redhat.com/security/cve/CVE-2022-48638 https://bugzilla.redhat.com/show_bug.cgi?id=2277829 • CWE-588: Attempt to Access Child of a Non-structure Pointer •

CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bnxt: prevent skb UAF after handing over to PTP worker When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt: impide que skb UAF se entregue al trabajador de PTP. Cuando se requiere leer la marca de tiempo, bnxt_tx_int() entrega la propiedad del skb completado al trabajador de PTP. El skb no debe usarse después, ya que el trabajador puede ejecutarse antes que el resto de nuestro código y liberar el skb, lo que lleva a un use-after-free. Dado que dev_kfree_skb_any() acepta NULL, la pérdida de propiedad es más obvia y establece skb en NULL. • https://git.kernel.org/stable/c/83bb623c968e7351aee5111547693f95f330dc5a https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6 https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338 https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65 https://access.redhat.com/security/cve/CVE-2022-48637 https://bugzilla.redhat.com/show_bug.cgi?id=2277831 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/dasd: corrige Ups en dasd_alias_get_start_dev debido a la falta de pavgroup. Corrige Ups en la función dasd_alias_get_start_dev() causada porque el puntero pavgroup es NULL. El puntero pavgroup se verifica en la entrada de la función pero sin que se mantenga presionado el bloqueo lcu->. • https://git.kernel.org/stable/c/8e09f21574ea3028d5629e5de759e0b196c690c5 https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70 https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4 https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1 https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1 https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6 https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a20 •

CVSS: 6.2EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: fsdax: Fix infinite loop in dax_iomap_rw() I got an infinite loop and a WARNING report when executing a tail command in virtiofs. WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in: CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace: <TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The tail command will call read() with a count of 0. In this case, iomap_iter() will report this WARNING, and always return 1 which casuing the infinite loop in dax_iomap_rw(). Fixing by checking count whether is 0 in dax_iomap_rw(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fsdax: Reparar bucle infinito en dax_iomap_rw() Obtuve un bucle infinito y un informe de ADVERTENCIA al ejecutar un comando tail en virtiofs. • https://git.kernel.org/stable/c/ca289e0b95afa973d204c77a4ad5c37e06145fbf https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744 https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0 https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix BUG: sleeping function called from invalid context errors gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex. The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors. Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set. This fixes the following WARN/stacktrace: [ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? • https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281 •