Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix a missing return value check bug<br /> <br /> In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct()<br /> fails to allocate a node, it returns a NULL pointer to the<br /> in_work pointer. This can lead to an illegal memory write of<br /> in_work-&gt;response_buf when allocate_interim_rsp_buf() attempts<br /> to perform a kzalloc() on it.<br /> <br /> To address this issue, incorporating a check for the return<br /> value of ksmbd_alloc_work_struct() ensures that the function<br /> returns immediately upon allocation failure, thereby preventing<br /> the aforementioned illegal memory access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: bh1745: fix information leak in triggered buffer<br /> <br /> The &amp;#39;scan&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it does not set values for inactive channels, as<br /> it only uses iio_for_each_active_channel() to assign new values.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpci: fix NULL pointer issue on shared irq case<br /> <br /> The tcpci_irq() may meet below NULL pointer dereference issue:<br /> <br /> [ 2.641851] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> [ 2.641951] status 0x1, 0x37f<br /> [ 2.650659] Mem abort info:<br /> [ 2.656490] ESR = 0x0000000096000004<br /> [ 2.660230] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 2.665532] SET = 0, FnV = 0<br /> [ 2.668579] EA = 0, S1PTW = 0<br /> [ 2.671715] FSC = 0x04: level 0 translation fault<br /> [ 2.676584] Data abort info:<br /> [ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 2.695284] [0000000000000010] user address but active_mm is swapper<br /> [ 2.701632] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 2.707883] Modules linked in:<br /> [ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 Not tainted 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4<br /> [ 2.720570] Hardware name: NXP i.MX93 11X11 EVK board (DT)<br /> [ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2.732989] pc : tcpci_irq+0x38/0x318<br /> [ 2.736647] lr : _tcpci_irq+0x14/0x20<br /> [ 2.740295] sp : ffff80008324bd30<br /> [ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70<br /> [ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000<br /> [ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000<br /> [ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001<br /> [ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040<br /> [ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a<br /> [ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00<br /> [ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031<br /> [ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002<br /> [ 2.807713] x2 : ffff80008324bd3a x1 : 0000000000000010 x0 : 0000000000000000<br /> [ 2.814838] Call trace:<br /> [ 2.817273] tcpci_irq+0x38/0x318<br /> [ 2.820583] _tcpci_irq+0x14/0x20<br /> [ 2.823885] irq_thread_fn+0x2c/0xa8<br /> [ 2.827456] irq_thread+0x16c/0x2f4<br /> [ 2.830940] kthread+0x110/0x114<br /> [ 2.834164] ret_from_fork+0x10/0x20<br /> [ 2.837738] Code: f9426420 f9001fe0 d2800000 52800201 (f9400a60)<br /> <br /> This may happen on shared irq case. Such as two Type-C ports share one<br /> irq. After the first port finished tcpci_register_port(), it may trigger<br /> interrupt. However, if the interrupt comes by chance the 2nd port finishes<br /> devm_request_threaded_irq(), the 2nd port interrupt handler will run at<br /> first. Then the above issue happens due to tcpci is still a NULL pointer<br /> in tcpci_irq() when dereference to regmap.<br /> <br /> devm_request_threaded_irq()<br /> irq);<br /> tcpci_register_port()<br /> <br /> This will restore the logic to the state before commit (77e85107a771 "usb:<br /> typec: tcpci: support edge irq").<br /> <br /> However, moving tcpci_register_port() earlier creates a problem when use<br /> edge irq because tcpci_init() will be called before<br /> devm_request_threaded_irq(). The tcpci_init() writes the ALERT_MASK to<br /> the hardware to tell it to start generating interrupts but we&amp;#39;re not ready<br /> to deal with them yet, then the ALERT events may be missed and ALERT line<br /> will not recover to high level forever. To avoid the issue, this will also<br /> set ALERT_MASK register after devm_request_threaded_irq() return.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix page fault due to max surface definition mismatch<br /> <br /> DC driver is using two different values to define the maximum number of<br /> surfaces: MAX_SURFACES and MAX_SURFACE_NUM. Consolidate MAX_SURFACES as<br /> the unique definition for surface updates across DC.<br /> <br /> It fixes page fault faced by Cosmic users on AMD display versions that<br /> support two overlay planes, since the introduction of cursor overlay<br /> mode.<br /> <br /> [Nov26 21:33] BUG: unable to handle page fault for address: 0000000051d0f08b<br /> [ +0.000015] #PF: supervisor read access in kernel mode<br /> [ +0.000006] #PF: error_code(0x0000) - not-present page<br /> [ +0.000005] PGD 0 P4D 0<br /> [ +0.000007] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ +0.000006] CPU: 4 PID: 71 Comm: kworker/u32:6 Not tainted 6.10.0+ #300<br /> [ +0.000006] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024<br /> [ +0.000007] Workqueue: events_unbound commit_work [drm_kms_helper]<br /> [ +0.000040] RIP: 0010:copy_stream_update_to_stream.isra.0+0x30d/0x750 [amdgpu]<br /> [ +0.000847] Code: 8b 10 49 89 94 24 f8 00 00 00 48 8b 50 08 49 89 94 24 00 01 00 00 8b 40 10 41 89 84 24 08 01 00 00 49 8b 45 78 48 85 c0 74 0b b6 00 41 88 84 24 90 64 00 00 49 8b 45 60 48 85 c0 74 3b 48 8b<br /> [ +0.000010] RSP: 0018:ffffc203802f79a0 EFLAGS: 00010206<br /> [ +0.000009] RAX: 0000000051d0f08b RBX: 0000000000000004 RCX: ffff9f964f0a8070<br /> [ +0.000004] RDX: ffff9f9710f90e40 RSI: ffff9f96600c8000 RDI: ffff9f964f000000<br /> [ +0.000004] RBP: ffffc203802f79f8 R08: 0000000000000000 R09: 0000000000000000<br /> [ +0.000005] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9f96600c8000<br /> [ +0.000004] R13: ffff9f9710f90e40 R14: ffff9f964f000000 R15: ffff9f96600c8000<br /> [ +0.000004] FS: 0000000000000000(0000) GS:ffff9f9970000000(0000) knlGS:0000000000000000<br /> [ +0.000005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000005] CR2: 0000000051d0f08b CR3: 00000002e6a20000 CR4: 0000000000350ef0<br /> [ +0.000005] Call Trace:<br /> [ +0.000011] <br /> [ +0.000010] ? __die_body.cold+0x19/0x27<br /> [ +0.000012] ? page_fault_oops+0x15a/0x2d0<br /> [ +0.000014] ? exc_page_fault+0x7e/0x180<br /> [ +0.000009] ? asm_exc_page_fault+0x26/0x30<br /> [ +0.000013] ? copy_stream_update_to_stream.isra.0+0x30d/0x750 [amdgpu]<br /> [ +0.000739] ? dc_commit_state_no_check+0xd6c/0xe70 [amdgpu]<br /> [ +0.000470] update_planes_and_stream_state+0x49b/0x4f0 [amdgpu]<br /> [ +0.000450] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000009] ? commit_minimal_transition_state+0x239/0x3d0 [amdgpu]<br /> [ +0.000446] update_planes_and_stream_v2+0x24a/0x590 [amdgpu]<br /> [ +0.000464] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000009] ? sort+0x31/0x50<br /> [ +0.000007] ? amdgpu_dm_atomic_commit_tail+0x159f/0x3a30 [amdgpu]<br /> [ +0.000508] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000009] ? amdgpu_crtc_get_scanout_position+0x28/0x40 [amdgpu]<br /> [ +0.000377] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000009] ? drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x160/0x390 [drm]<br /> [ +0.000058] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? dma_fence_default_wait+0x8c/0x260<br /> [ +0.000010] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? wait_for_completion_timeout+0x13b/0x170<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? dma_fence_wait_timeout+0x108/0x140<br /> [ +0.000010] ? commit_tail+0x94/0x130 [drm_kms_helper]<br /> [ +0.000024] ? process_one_work+0x177/0x330<br /> [ +0.000008] ? worker_thread+0x266/0x3a0<br /> [ +0.000006] ? __pfx_worker_thread+0x10/0x10<br /> [ +0.000004] ? kthread+0xd2/0x100<br /> [ +0.000006] ? __pfx_kthread+0x10/0x10<br /> [ +0.000006] ? ret_from_fork+0x34/0x50<br /> [ +0.000004] ? __pfx_kthread+0x10/0x10<br /> [ +0.000005] ? ret_from_fork_asm+0x1a/0x30<br /> [ +0.000011] <br /> <br /> (cherry picked from commit 1c86c81a86c60f9b15d3e3f43af0363cf56063e7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: vcnl4035: fix information leak in triggered buffer<br /> <br /> The &amp;#39;buffer&amp;#39; local array is used to push data to userspace from a<br /> triggered buffer, but it does not set an initial value for the single<br /> data element, which is an u16 aligned to 8 bytes. That leaves at least<br /> 4 bytes uninitialized even after writing an integer value with<br /> regmap_read().<br /> <br /> Initialize the array to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer<br /> <br /> The &amp;#39;data&amp;#39; array is allocated via kmalloc() and it is used to push data<br /> to user space from a triggered buffer, but it does not set values for<br /> inactive channels, as it only uses iio_for_each_active_channel()<br /> to assign new values.<br /> <br /> Use kzalloc for the memory allocation to avoid pushing uninitialized<br /> information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: pressure: zpa2326: fix information leak in triggered buffer<br /> <br /> The &amp;#39;sample&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it has a hole between the temperature and the<br /> timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).<br /> This hole is never initialized.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Remove WARN_ON in functionfs_bind<br /> <br /> This commit addresses an issue related to below kernel panic where<br /> panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON<br /> in functionsfs_bind, which easily leads to the following scenarios.<br /> <br /> 1.adb_write in adbd 2. UDC write via configfs<br /> ================= =====================<br /> <br /> -&gt;usb_ffs_open_thread() -&gt;UDC write<br /> -&gt;open_functionfs() -&gt;configfs_write_iter()<br /> -&gt;adb_open() -&gt;gadget_dev_desc_UDC_store()<br /> -&gt;adb_write() -&gt;usb_gadget_register_driver_owner<br /> -&gt;driver_register()<br /> -&gt;StartMonitor() -&gt;bus_add_driver()<br /> -&gt;adb_read() -&gt;gadget_bind_driver()<br /> -&gt;configfs_composite_bind()<br /> -&gt;usb_add_function()<br /> -&gt;open_functionfs() -&gt;ffs_func_bind()<br /> -&gt;adb_open() -&gt;functionfs_bind()<br /> state !=FFS_ACTIVE&gt;<br /> <br /> The adb_open, adb_read, and adb_write operations are invoked from the<br /> daemon, but trying to bind the function is a process that is invoked by<br /> UDC write through configfs, which opens up the possibility of a race<br /> condition between the two paths. In this race scenario, the kernel panic<br /> occurs due to the WARN_ON from functionfs_bind when panic_on_warn is<br /> enabled. This commit fixes the kernel panic by removing the unnecessary<br /> WARN_ON.<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> [ 14.542395] Call trace:<br /> [ 14.542464] ffs_func_bind+0x1c8/0x14a8<br /> [ 14.542468] usb_add_function+0xcc/0x1f0<br /> [ 14.542473] configfs_composite_bind+0x468/0x588<br /> [ 14.542478] gadget_bind_driver+0x108/0x27c<br /> [ 14.542483] really_probe+0x190/0x374<br /> [ 14.542488] __driver_probe_device+0xa0/0x12c<br /> [ 14.542492] driver_probe_device+0x3c/0x220<br /> [ 14.542498] __driver_attach+0x11c/0x1fc<br /> [ 14.542502] bus_for_each_dev+0x104/0x160<br /> [ 14.542506] driver_attach+0x24/0x34<br /> [ 14.542510] bus_add_driver+0x154/0x270<br /> [ 14.542514] driver_register+0x68/0x104<br /> [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4<br /> [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144<br /> [ 14.542526] configfs_write_iter+0xf0/0x138

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling<br /> <br /> Resolve kernel panic caused by improper handling of IRQs while<br /> accessing GPIO values. This is done by replacing generic_handle_irq with<br /> handle_nested_irq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> topology: Keep the cpumask unchanged when printing cpumap<br /> <br /> During fuzz testing, the following warning was discovered:<br /> <br /> different return values (15 and 11) from vsnprintf("%*pbl<br /> ", ...)<br /> <br /> test:keyward is WARNING in kvasprintf<br /> WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130<br /> Call Trace:<br /> kvasprintf+0x121/0x130<br /> kasprintf+0xa6/0xe0<br /> bitmap_print_to_buf+0x89/0x100<br /> core_siblings_list_read+0x7e/0xb0<br /> kernfs_file_read_iter+0x15b/0x270<br /> new_sync_read+0x153/0x260<br /> vfs_read+0x215/0x290<br /> ksys_read+0xb9/0x160<br /> do_syscall_64+0x56/0x100<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The call trace shows that kvasprintf() reported this warning during the<br /> printing of core_siblings_list. kvasprintf() has several steps:<br /> <br /> (1) First, calculate the length of the resulting formatted string.<br /> <br /> (2) Allocate a buffer based on the returned length.<br /> <br /> (3) Then, perform the actual string formatting.<br /> <br /> (4) Check whether the lengths of the formatted strings returned in<br /> steps (1) and (2) are consistent.<br /> <br /> If the core_cpumask is modified between steps (1) and (3), the lengths<br /> obtained in these two steps may not match. Indeed our test includes cpu<br /> hotplugging, which should modify core_cpumask while printing.<br /> <br /> To fix this issue, cache the cpumask into a temporary variable before<br /> calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged<br /> during the printing process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads1119: fix information leak in triggered buffer<br /> <br /> The &amp;#39;scan&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it has a hole between the sample (unsigned int)<br /> and the timestamp. This hole is never initialized.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.