Page 16 of 2671 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction. • https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05 https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148 https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463 https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79 https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633 https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506 https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() when freeing tree block after error When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block(). So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection. • https://git.kernel.org/stable/c/98251cd60b4d702a8a81de442ab621e83a3fb24f https://git.kernel.org/stable/c/bb3868033a4cccff7be57e9145f2117cbdc91c11 •

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

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) • https://git.kernel.org/stable/c/4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016 https://git.kernel.org/stable/c/28bbb5011a9723700006da67bdb57ab6a914452b https://git.kernel.org/stable/c/0d0df1e750bac0fdaa77940e711c1625cff08d33 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01) • https://git.kernel.org/stable/c/0da0b06165d83a8ecbb6582d9d5a135f9d38a52a https://git.kernel.org/stable/c/c28d207edfc5679585f4e96acb67000076ce90be https://git.kernel.org/stable/c/829798c789f567ef6ba4b084c15b7b5f3bd98d51 •

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

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: Check for unset descriptor Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. • https://git.kernel.org/stable/c/d1c188d330ca33cc35d1590441ba276f31144299 https://git.kernel.org/stable/c/54f83b8c8ea9b22082a496deadf90447a326954e https://git.kernel.org/stable/c/d7e3f2fe01372eb914d0e451f0e7a46cbcb98f9e https://git.kernel.org/stable/c/85c9ece11264499890d0e9f0dee431ac1bda981c https://git.kernel.org/stable/c/fc71e39a6c07440e6968227f3db1988f45d7a7b7 https://git.kernel.org/stable/c/94f5de2eefae22c449e367c2dacafe869af73e3f https://git.kernel.org/stable/c/8212b44b7109bd30dbf7eb7f5ecbbc413757a7d7 https://git.kernel.org/stable/c/ba15815dd24cc5ec0d23e2170dc58c7db •