Page 157 of 2368 results (0.013 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en() dom->sdev is equal to NULL, which leads to null dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/92c089a931fd3939cd32318cf4f54e69e8f51a19 https://git.kernel.org/stable/c/8745f3592ee4a7b49ede16ddd3f12a41ecaa23c9 https://git.kernel.org/stable/c/9afea57384d4ae7b2034593eac7fa76c7122762a https://git.kernel.org/stable/c/d0a917fd5e3b3ed9d9306b4260ba684b982da9f3 https://git.kernel.org/stable/c/8c79ceb4ecf823e6ec10fee6febb0fca3de79922 https://git.kernel.org/stable/c/dfe90030a0cfa26dca4cb6510de28920e5ad22fb https://git.kernel.org/stable/c/b62841e49a2b7938f6fdeaaf93fb57e4eb880bdb https://git.kernel.org/stable/c/d5fe884ce28c5005f8582c35333c195a1 •

CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: add missing condition check for existence of mapped data nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference. • https://git.kernel.org/stable/c/4aedb705437f6f98b45f45c394e6803ca67abd33 https://git.kernel.org/stable/c/3f8ec1d6b0ebd8268307d52be8301973fa5a01ec https://git.kernel.org/stable/c/be23ae63080e0bf9e246ab20207200bca6585eba https://git.kernel.org/stable/c/7cc1f4cd90a00b6191cb8cda2d1302fdce59361c https://git.kernel.org/stable/c/d135c3352f7c947a922da93c8e763ee6bc208b64 https://git.kernel.org/stable/c/77848b379e9f85a08048a2c8b3b4a7e8396f5f83 https://git.kernel.org/stable/c/70100fe721840bf6d8e5abd25b8bffe4d2e049b7 https://git.kernel.org/stable/c/c31fad1470389666ac7169fe43aa65bf5 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix null pointer deref when receiving skb during sock creation The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: <IRQ> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? • https://git.kernel.org/stable/c/ab9f2115081ab7ba63b77a759e0f3eb5d6463d7f https://git.kernel.org/stable/c/0abe35bc48d4ec80424b1f4b3560c0e082cbd5c1 https://git.kernel.org/stable/c/347dcb84a4874b5fb375092c08d8cc4069b94f81 https://git.kernel.org/stable/c/290a6b88e8c19b6636ed1acc733d1458206f7697 https://git.kernel.org/stable/c/ead2ad1d9f045f26fdce3ef1644913b3a6cd38f2 https://git.kernel.org/stable/c/6c920754f62cefc63fccdc38a062c7c3452e2961 https://git.kernel.org/stable/c/46c17ead5b7389e22e7dc9903fd0ba865d05bda2 https://git.kernel.org/stable/c/fce09ea314505a52f2436397608fa0a5d •

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

In the Linux kernel, the following vulnerability has been resolved: Revert "ALSA: firewire-lib: operate for period elapse event in process context" Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") removed the process context workqueue from amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove its overhead. With RME Fireface 800, this lead to a regression since Kernels 5.14.0, causing an AB/BA deadlock competition for the substream lock with eventual system freeze under ALSA operation: thread 0: * (lock A) acquire substream lock by snd_pcm_stream_lock_irq() in snd_pcm_status64() * (lock B) wait for tasklet to finish by calling tasklet_unlock_spin_wait() in tasklet_disable_in_atomic() in ohci_flush_iso_completions() of ohci.c thread 1: * (lock B) enter tasklet * (lock A) attempt to acquire substream lock, waiting for it to be released: snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed() in update_pcm_pointers() in process_ctx_payloads() in process_rx_packets() of amdtp-stream.c ? tasklet_unlock_spin_wait </NMI> <TASK> ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm ? native_queued_spin_lock_slowpath </NMI> <IRQ> _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci Restore the process context work queue to prevent deadlock AB/BA deadlock competition for ALSA substream lock of snd_pcm_stream_lock_irq() in snd_pcm_status64() and snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed(). revert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") Replace inline description to prevent future deadlock. • https://git.kernel.org/stable/c/7ba5ca32fe6e8d2e153fb5602997336517b34743 https://git.kernel.org/stable/c/7c07220cf634002f93a87ca2252a32766850f2d1 https://git.kernel.org/stable/c/b239a37d68e8bc59f9516444da222841e3b13ba9 https://git.kernel.org/stable/c/f5043e69aeb2786f32e84132817a007a6430aa7d https://git.kernel.org/stable/c/36c255db5a25edd42d1aca48e38b8e95ee5fd9ef https://git.kernel.org/stable/c/3dab73ab925a51ab05543b491bf17463a48ca323 •

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: assign CURSEG_ALL_DATA_ATGC if blkaddr is valid mkdir /mnt/test/comp f2fs_io setflags compression /mnt/test/comp dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1 truncate --size 13 /mnt/test/comp/testfile In the above scenario, we can get a BUG_ON. kernel BUG at fs/f2fs/segment.c:3589! Call Trace: do_write_page+0x78/0x390 [f2fs] f2fs_outplace_write_data+0x62/0xb0 [f2fs] f2fs_do_write_data_page+0x275/0x740 [f2fs] f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs] f2fs_write_multi_pages+0x1e5/0xae0 [f2fs] f2fs_write_cache_pages+0xab1/0xc60 [f2fs] f2fs_write_data_pages+0x2d8/0x330 [f2fs] do_writepages+0xcf/0x270 __writeback_single_inode+0x44/0x350 writeback_sb_inodes+0x242/0x530 __writeback_inodes_wb+0x54/0xf0 wb_writeback+0x192/0x310 wb_workfn+0x30d/0x400 The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the page was set the gcing flag by set_cluster_dirty(). • https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136 https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3 https://git.kernel.org/stable/c/5fd057160ab240dd816ae09b625395d54c297de1 https://git.kernel.org/stable/c/4239571c5db46a42f723b8fa8394039187c34439 https://git.kernel.org/stable/c/0cd106612396656d6f1ca17ef192c6759 •