Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ds90ub9x3: Fix extra fwnode_handle_put()<br /> <br /> The ub913 and ub953 drivers call fwnode_handle_put(priv-&gt;sd.fwnode) as<br /> part of their remove process, and if the driver is removed multiple<br /> times, eventually leads to put "overflow", possibly causing memory<br /> corruption or crash.<br /> <br /> The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media:<br /> i2c: ds90ub9x3: Fix sub-device matching"), which changed the code<br /> related to the sd.fwnode, but missed removing these fwnode_handle_put()<br /> calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: intel/ipu6: remove cpu latency qos request on error<br /> <br /> Fix cpu latency qos list corruption like below. It happens when<br /> we do not remove cpu latency request on error path and free<br /> corresponding memory.<br /> <br /> [ 30.634378] l7 kernel: list_add corruption. prev-&gt;next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).<br /> [ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0<br /> <br /> [ 30.634640] l7 kernel: Call Trace:<br /> [ 30.634650] l7 kernel: <br /> [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6<br /> [ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634690] l7 kernel: ? report_bug+0xff/0x140<br /> [ 30.634702] l7 kernel: ? handle_bug+0x58/0x90<br /> [ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70<br /> [ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20<br /> [ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0<br /> [ 30.634742] l7 kernel: plist_add+0xdd/0x140<br /> [ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0<br /> [ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0<br /> [ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()<br /> <br /> In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update<br /> inbound map address") set_bar() was modified to support dynamically<br /> changing the backing physical address of a BAR that was already configured.<br /> <br /> This means that set_bar() can be called twice, without ever calling<br /> clear_bar() (as calling clear_bar() would clear the BAR&amp;#39;s PCI address<br /> assigned by the host).<br /> <br /> This can only be done if the new BAR size/flags does not differ from the<br /> existing BAR configuration. Add these missing checks.<br /> <br /> If we allow set_bar() to set e.g. a new BAR size that differs from the<br /> existing BAR size, the new address translation range will be smaller than<br /> the BAR size already determined by the host, which would mean that a read<br /> past the new BAR size would pass the iATU untranslated, which could allow<br /> the host to read memory not belonging to the new struct pci_epf_bar.<br /> <br /> While at it, add comments which clarifies the support for dynamically<br /> changing the physical address of a BAR. (Which was also missing.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y<br /> <br /> With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted<br /> keys can crash during en- and decryption of the blob encryption key via<br /> the DCP crypto driver. This is caused by improperly using sg_init_one()<br /> with vmalloc&amp;#39;d stack buffers (plain_key_blob).<br /> <br /> Fix this by always using kmalloc() for buffers we give to the DCP crypto<br /> driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/tracing: Fix a potential TP_printk UAF<br /> <br /> The commit<br /> afd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format")<br /> exposes potential UAFs in the xe_bo_move trace event.<br /> <br /> Fix those by avoiding dereferencing the<br /> xe_mem_type_to_name[] array at TP_printk time.<br /> <br /> Since some code refactoring has taken place, explicit backporting may<br /> be needed for kernels older than 6.10.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread<br /> <br /> syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]<br /> <br /> If dvb-&gt;mux is not initialized successfully by vidtv_mux_init() in the<br /> vidtv_start_streaming(), it will trigger null pointer dereference about mux<br /> in vidtv_mux_stop_thread().<br /> <br /> Adjust the timing of streaming initialization and check it before<br /> stopping it.<br /> <br /> [1]<br /> KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]<br /> CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471<br /> Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8<br /> RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125<br /> RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128<br /> RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188<br /> R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710<br /> FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]<br /> vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252<br /> dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000<br /> dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486<br /> dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3f8/0xb60 fs/file_table.c:450<br /> task_work_run+0x14e/0x250 kernel/task_work.c:239<br /> get_signal+0x1d3/0x2610 kernel/signal.c:2790<br /> arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218<br /> do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()<br /> <br /> Extended the `mi_enum_attr()` function interface with an additional<br /> parameter, `struct ntfs_inode *ni`, to allow marking the inode<br /> as bad as soon as an error is detected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()<br /> <br /> name is char[64] where the size of clnt-&gt;cl_program-&gt;name remains<br /> unknown. Invoking strcat() directly will also lead to potential buffer<br /> overflow. Change them to strscpy() and strncat() to fix potential<br /> issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: smc: Handle missing SCM device<br /> <br /> Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer<br /> dereference") makes it explicit that qcom_scm_get_tzmem_pool() can<br /> return NULL, therefore its users should handle this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get()<br /> <br /> This patch fixes a potential integer overflow in the zynqmp_dp_rate_get()<br /> <br /> The issue comes up when the expression<br /> drm_dp_bw_code_to_link_rate(dp-&gt;test.bw_code) * 10000 is evaluated using 32-bit<br /> Now the constant is a compatible 64-bit type.<br /> <br /> Resolves coverity issues: CID 1636340 and CID 1635811

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()<br /> <br /> The "submit-&gt;cmd[i].size" and "submit-&gt;cmd[i].offset" variables are u32<br /> values that come from the user via the submit_lookup_cmds() function.<br /> This addition could lead to an integer wrapping bug so use size_add()<br /> to prevent that.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/624696/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: bsg: Set bsg_queue to NULL after removal<br /> <br /> Currently, this does not cause any issues, but I believe it is necessary to<br /> set bsg_queue to NULL after removing it to prevent potential use-after-free<br /> (UAF) access.