CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48633 – drm/gma500: Fix WARN_ON(lock->magic != lock) error
https://notcve.org/view.php?id=CVE-2022-48633
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix WARN_ON(lock->magic != lock) error psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex gets destroyed by drm_gem_object_release() move the drm_gem_object_release() call in psb_gem_free_object() to after the unpin to fix the below warning: [ 79.693962] ------------[ cut here ]------------ [ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G W E 6.0.0-rc3+ #490 [ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000 [ 79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff [ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90 [ 79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138 [ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270 [ 79.694690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000 [ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0 [ 79.694734] Call Trace: [ 79.694749] <TASK> [ 79.694761] ? __schedule+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694830] ? • https://git.kernel.org/stable/c/55c077d97fa67e9f19952bb24122a8316b089474 https://git.kernel.org/stable/c/b6f25c3b94f2aadbf5cbef954db4073614943d74 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48631 – ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
https://notcve.org/view.php?id=CVE-2022-48631
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0 When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero when depth is > 0. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this: [ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? • https://git.kernel.org/stable/c/bb7eb3ca4b3b0d2c7872cf1a41c30f5e5bd65df0 https://git.kernel.org/stable/c/958b0ee23f5ac106e7cc11472b71aa2ea9a033bc https://git.kernel.org/stable/c/be4df018c0be5ebecf1ca510feacc23be415cefc https://git.kernel.org/stable/c/2f5e9de15e4f55fbf56f22d4a2ce406246cc462d https://git.kernel.org/stable/c/29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26928 – smb: client: fix potential UAF in cifs_debug_files_proc_show()
https://notcve.org/view.php?id=CVE-2024-26928
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en cifs_debug_files_proc_show() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF. • https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88 https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1 https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52646 – aio: fix mremap after fork null-deref
https://notcve.org/view.php?id=CVE-2023-52646
In the Linux kernel, the following vulnerability has been resolved: aio: fix mremap after fork null-deref Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [jmoyer@redhat.com: fix 80 column issue] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: aio: corrige mremap después de la bifurcación null-deref Commit e4a0d3e720e7 ("aio: Make it posible reasignar el anillo aio") introdujo un null-deref si se llama a mremap en un mapeo aio antiguo después de la bifurcación como mm->ioctx_table se establecerá en NULL. [jmoyer@redhat.com: soluciona el problema de 80 columnas] • https://git.kernel.org/stable/c/e4a0d3e720e7e508749c1439b5ba3aff56c92976 https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95 https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22 https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2 https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1 https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e2997 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26926 – binder: check offset alignment in binder_get_object()
https://notcve.org/view.php?id=CVE-2024-26926
In the Linux kernel, the following vulnerability has been resolved: binder: check offset alignment in binder_get_object() Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binder_alloc_copy_from_buffer() -> check_buffer(). These calls were replaced in binder_get_object() with copy_from_user(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder. It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Binder: verifique la alineación de desplazamiento en binder_get_object() El commit 6d98eb95b450 ("binder: evite posibles fugas de datos al copiar txn") introdujo cambios en la forma en que se copian los objetos de Binder. Al hacerlo, eliminó involuntariamente una verificación de alineación de desplazamiento realizada mediante llamadas a binder_alloc_copy_from_buffer() -> check_buffer(). • https://git.kernel.org/stable/c/c056a6ba35e00ae943e377eb09abd77a6915b31a https://git.kernel.org/stable/c/23e9d815fad84c1bee3742a8de4bd39510435362 https://git.kernel.org/stable/c/7a9ad4aceb0226b391c9d3b8e4ac2e7d438b6bde https://git.kernel.org/stable/c/6d98eb95b450a75adb4516a1d33652dc78d2b20c https://git.kernel.org/stable/c/66e12f5b3a9733f941893a00753b10498724607d https://git.kernel.org/stable/c/68a28f551e4690db2b27b3db716c7395f6fada12 https://git.kernel.org/stable/c/48a1f83ca9c68518b1a783c62e6a8223144fa9fc https://git.kernel.org/stable/c/a2fd6dbc98be1105a1d8e9e31575da887 •