Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: net2280: Fix double free in probe error path<br /> <br /> usb_initialize_gadget() installs gadget_release() as the release<br /> callback for the embedded gadget device. The struct net2280 instance is<br /> therefore released through gadget_release() when the gadget device&amp;#39;s last<br /> reference is dropped.<br /> <br /> The probe error path calls net2280_remove(), which tears down the<br /> partially initialized device and drops the gadget reference with<br /> usb_put_gadget(). Calling kfree(dev) afterwards can free the same object<br /> again.<br /> <br /> Drop the explicit kfree() and let the gadget device release callback<br /> handle the final free. This issue was found by a static analysis tool<br /> I am developing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: igorplugusb: fix control request setup packet<br /> <br /> Commit eac69475b01f ("media: rc: igorplugusb: heed coherency<br /> rules") changed the control request storage from an embedded struct to<br /> an allocated pointer so it can obey DMA coherency rules.<br /> <br /> However, the driver still passes &amp;ir-&gt;request to usb_fill_control_urb().<br /> That points the URB setup packet at the pointer field itself rather than<br /> at the allocated struct usb_ctrlrequest.<br /> <br /> USB core then interprets pointer bytes as the setup packet. This can<br /> produce an invalid bRequestType and trigger the control direction warning<br /> reported by syzbot:<br /> <br /> usb 2-1: BOGUS control dir, pipe 80003580 doesn&amp;#39;t match bRequestType 0<br /> <br /> Pass ir-&gt;request itself as the setup packet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/base/memory: set mem-&gt;altmap after successful device registration<br /> <br /> If __add_memory_block() fails at xa_store() (under memory pressure for<br /> example), device_unregister() is called, which eventually triggers<br /> memory_block_release() with mem-&gt;altmap still set, causing a<br /> WARN_ON(mem-&gt;altmap). This was triggered by modifying virtio-mem driver.<br /> <br /> Fix this by delaying the assignment of mem-&gt;altmap until after<br /> __add_memory_block() has succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: modedb: fix a possible UAF in fb_find_mode()<br /> <br /> If mode_option is NULL, it is assigned from mode_option_buf:<br /> <br /> if (!mode_option) {<br /> fb_get_options(NULL, &amp;mode_option_buf);<br /> mode_option = mode_option_buf;<br /> }<br /> <br /> Later, name is assigned from mode_option:<br /> <br /> const char *name = mode_option;<br /> <br /> However, mode_option_buf is freed before name is no longer used:<br /> <br /> kfree(mode_option_buf);<br /> <br /> while name is still accessed by:<br /> <br /> if ((name_matches(db[i], name, namelen) ||<br /> <br /> Since name aliases mode_option_buf, this may result in a<br /> use-after-free.<br /> <br /> Fix this by extending the lifetime of mode_option_buf until the end of the<br /> function by using scope-based resource management for cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: elan_i2c - validate firmware size before use<br /> <br /> Ensure that the firmware file is large enough to contain the expected<br /> number of pages and the signature (which resides at the end of the<br /> firmware blob) before accessing them to prevent potential out-of-bounds<br /> reads.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: davinci: fix division by zero on missing clock-frequency<br /> <br /> When the &amp;#39;clock-frequency&amp;#39; property is missing from the device tree,<br /> the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this<br /> macro was defined in kHz (100), whereas the device tree property is<br /> expected in Hz.<br /> <br /> The probe function divided the fallback value by 1000, causing<br /> integer truncation that resulted in dev-&gt;bus_freq = 0. This triggered<br /> a deterministic division-by-zero kernel panic when calculating clock<br /> dividers later in the probe sequence.<br /> <br /> Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)<br /> to match the expected device tree property unit, allowing the existing<br /> division logic to work correctly for both cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines<br /> <br /> With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform<br /> (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline<br /> crashes on the first call into the traced function:<br /> <br /> BUG: unable to handle page fault for address: ffff88817ae18880<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 4b53067 P4D 4b53067 PUD 0<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014<br /> Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89<br /> Call Trace:<br /> <br /> ? find_held_lock<br /> ? exc_page_fault<br /> ? lock_release<br /> ? __x64_sys_clock_nanosleep<br /> ? lockdep_hardirqs_on_prepare<br /> ? trace_hardirqs_on<br /> __x64_sys_clock_nanosleep<br /> do_syscall_64<br /> ? exc_page_fault<br /> ? call_depth_return_thunk<br /> entry_SYSCALL_64_after_hwframe<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> This small reproducer allows to easily trigger the crash:<br /> <br /> # echo &amp;#39;p __x64_sys_clock_nanosleep&amp;#39; &gt; /sys/kernel/tracing/kprobe_events<br /> # echo 1 &gt; /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable<br /> # usleep 1<br /> <br /> Monitoring the crash under GDB points to the exact instruction in charge of<br /> incrementing the call depth:<br /> <br /> sarq $5, %gs:__x86_call_depth(%rip)<br /> <br /> This instruction matches the one inserted by the ftrace_regs_caller from<br /> ftrace_64.S. This emitted code was likely working fine until the introduction<br /> of<br /> <br /> 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"):<br /> <br /> it has made the call depth accounting addressing relative to $rip, instead of<br /> being based on an absolute address.<br /> <br /> As this code exact location depends on where the trampoline lives in memory,<br /> the corresponding displacement needs to be adjusted at runtime to actually<br /> correctly find the per-cpu __x86_call_depth value, otherwise the targeted<br /> address is wrong, leading to the page fault seen above.<br /> <br /> Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT<br /> instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(),<br /> as it is done for example by the x86 BPF JIT compiler through<br /> x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots,<br /> in ftrace_caller and ftrace_regs_caller.<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: pch_uart: add check for dma_alloc_coherent()<br /> <br /> Add a check for dma_alloc_coherent() failure to prevent a potential<br /> NULL pointer dereference in dma_handle_rx(). Properly release DMA<br /> channels and the PCI device reference using a goto ladder if the<br /> allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: hold opts-&gt;lock across XU walks in uvc_function_bind<br /> <br /> uvc_function_bind() walks &amp;opts-&gt;extension_units twice without holding<br /> opts-&gt;lock:<br /> <br /> - directly, for the iExtension string-descriptor fixup loop;<br /> - indirectly, four times via uvc_copy_descriptors() (once per speed),<br /> where the helper iterates uvc-&gt;desc.extension_units (which aliases<br /> &amp;opts-&gt;extension_units) to size and emit XU descriptors.<br /> <br /> The configfs side (uvcg_extension_make / uvcg_extension_drop, in<br /> drivers/usb/gadget/function/uvc_configfs.c) takes opts-&gt;lock around its<br /> list_add_tail / list_del operations. A privileged userspace process<br /> that holds the configfs subtree open and writes the gadget UDC name<br /> to bind the function while concurrently rmdir()&amp;#39;ing an extensions<br /> subdir can race uvcg_extension_drop() against the bind-time list walks<br /> and dereference a freed struct uvcg_extension.<br /> <br /> Hold opts-&gt;lock from the start of the XU string-descriptor fixup<br /> through the last uvc_copy_descriptors() call, releasing on the<br /> descriptor-error path via a new error_unlock label that drops the<br /> lock before falling through to the existing error label. This<br /> matches the locking discipline of the configfs callbacks and removes<br /> the only remaining unsynchronised reader of the XU list during bind.<br /> <br /> Reachability: only privileged processes that can mount configfs and<br /> write to gadget UDC files can trigger the race, so this is a<br /> correctness fix rather than a security boundary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: recompute nr_integrity_segments in blk_insert_cloned_request<br /> <br /> blk_insert_cloned_request() already recomputes nr_phys_segments<br /> against the bottom queue, because "the queue settings related to<br /> segment counting may differ from the original queue." The exact same<br /> reasoning applies to integrity segments: a stacked driver&amp;#39;s underlying<br /> queue can have tighter virt_boundary_mask, seg_boundary_mask, or<br /> max_segment_size than the top queue, in which case<br /> blk_rq_count_integrity_sg() against the bottom queue produces a<br /> different count than the cached rq-&gt;nr_integrity_segments inherited<br /> from the source request by blk_rq_prep_clone().<br /> <br /> When the cached count is lower than the bottom queue&amp;#39;s actual count,<br /> blk_rq_map_integrity_sg() trips<br /> <br /> BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);<br /> <br /> on dispatch. The same families of stacked setups that motivated the<br /> existing nr_phys_segments recompute -- dm-multipath fanning out to<br /> nvme-rdma in particular -- can produce this.<br /> <br /> Mirror the nr_phys_segments handling: when the request carries<br /> integrity, recompute nr_integrity_segments against the bottom queue<br /> and reject the request if it exceeds the bottom queue&amp;#39;s<br /> max_integrity_segments. blk_rq_count_integrity_sg() and<br /> queue_max_integrity_segments() are both already available via<br /> , which blk-mq.c includes.<br /> <br /> This closes a latent gap in the stacking contract and brings the<br /> integrity-segment accounting in line with the existing<br /> phys-segment accounting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: don&amp;#39;t dump registers past the mapped region<br /> <br /> On DSI 6G platforms the IO address space is internally adjusted by<br /> io_offset. Later this adjusted address might be used for memory dumping.<br /> However the size that is used for memory dumping isn&amp;#39;t adjusted to<br /> account for the io_offset, leading to the potential access to the<br /> unmapped region. Lower ctrl_size by the io_offset value to prevent<br /> access past the mapped area.<br /> <br /> msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P)<br /> msm_dsi_host_snapshot+0x4c/0x78 [msm]<br /> msm_dsi_snapshot+0x28/0x50 [msm]<br /> msm_disp_snapshot_capture_state+0x74/0x140 [msm]<br /> msm_disp_snapshot_state_sync+0x60/0x90 [msm]<br /> _msm_disp_snapshot_work+0x30/0x90 [msm]<br /> kthread_worker_fn+0xdc/0x460<br /> kthread+0x120/0x140<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/721747/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: tps65219: fix irq_data.rdev not being assigned<br /> <br /> Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper<br /> function") removed the tps65219_get_rdev_by_name() helper along with<br /> the irq_data.rdev assignment that depended on it. This left<br /> irq_data.rdev uninitialized for all IRQs, causing undefined behavior<br /> when regulator_notifier_call_chain() is called from the IRQ handler:<br /> <br /> Internal error: Oops: 0000000096000004<br /> pc : regulator_notifier_call_chain<br /> lr : tps65219_regulator_irq_handler<br /> Call trace:<br /> regulator_notifier_call_chain<br /> tps65219_regulator_irq_handler<br /> handle_nested_irq<br /> regmap_irq_thread<br /> irq_thread_fn<br /> irq_thread<br /> kthread<br /> ret_from_fork<br /> <br /> Instead of restoring a dedicated lookup array, restructure the probe<br /> function to combine regulator registration with IRQ registration in<br /> the same loop. This way the rdev returned by devm_regulator_register()<br /> is naturally available for assigning to irq_data.rdev without any<br /> auxiliary data structure.<br /> <br /> Non-regulator IRQs (SENSOR, TIMEOUT) that don&amp;#39;t correspond to any<br /> registered regulator are registered with rdev=NULL, and the IRQ handler<br /> is protected with a NULL check to avoid crashing.