Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix buffer validation by including null terminator size in EA length<br /> <br /> The smb2_set_ea function, which handles Extended Attributes (EA),<br /> was performing buffer validation checks that incorrectly omitted the size<br /> of the null terminating character (+1 byte) for EA Name.<br /> This patch fixes the issue by explicitly adding &amp;#39;+ 1&amp;#39; to EaNameLength where<br /> the null terminator is expected to be present in the buffer, ensuring<br /> the validation accurately reflects the total required buffer size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix race between wbt_enable_default and IO submission<br /> <br /> When wbt_enable_default() is moved out of queue freezing in elevator_change(),<br /> it can cause the wbt inflight counter to become negative (-1), leading to hung<br /> tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter<br /> is in an inconsistent state.<br /> <br /> The issue occurs because wbt_enable_default() could race with IO submission,<br /> allowing the counter to be decremented before proper initialization. This manifests<br /> as:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() checks the state, which can be updated exactly between wbt_wait()<br /> (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter<br /> will become negative.<br /> <br /> And results in hung task warnings like:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Fix this by:<br /> <br /> 1. Splitting wbt_enable_default() into:<br /> - __wbt_enable_default(): Returns true if wbt_init() should be called<br /> - wbt_enable_default(): Wrapper for existing callers (no init)<br /> - wbt_init_enable_default(): New function that checks and inits WBT<br /> <br /> 2. Using wbt_init_enable_default() in blk_register_queue() to ensure<br /> proper initialization during queue registration<br /> <br /> 3. Move wbt_init() out of wbt_enable_default() which is only for enabling<br /> disabled wbt from bfq and iocost, and wbt_init() isn&amp;#39;t needed. Then the<br /> original lock warning can be avoided.<br /> <br /> 4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling<br /> code since it&amp;#39;s no longer needed<br /> <br /> This ensures WBT is properly initialized before any IO can be submitted,<br /> preventing the counter from going negative.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: initialize local pointers upon transfer of memory ownership<br /> <br /> vidtv_channel_si_init() creates a temporary list (program, service, event)<br /> and ownership of the memory itself is transferred to the PAT/SDT/EIT<br /> tables through vidtv_psi_pat_program_assign(),<br /> vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().<br /> <br /> The problem here is that the local pointer where the memory ownership<br /> transfer was completed is not initialized to NULL. This causes the<br /> vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and<br /> in the flow that jumps to free_eit, the memory that was freed by<br /> vidtv_psi_*_table_destroy() can be accessed again by<br /> vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it<br /> is freed once again.<br /> <br /> Therefore, to prevent use-after-free and double-free vulnerability,<br /> local pointers must be initialized to NULL when transferring memory<br /> ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm2-sessions: Fix out of range indexing in name_size<br /> <br /> &amp;#39;name_size&amp;#39; does not have any range checks, and it just directly indexes<br /> with TPM_ALG_ID, which could lead into memory corruption at worst.<br /> <br /> Address the issue by only processing known values and returning -EINVAL for<br /> unrecognized values.<br /> <br /> Make also &amp;#39;tpm_buf_append_name&amp;#39; and &amp;#39;tpm_buf_fill_hmac_session&amp;#39; fallible so<br /> that errors are detected before causing any spurious TPM traffic.<br /> <br /> End also the authorization session on failure in both of the functions, as<br /> the session state would be then by definition corrupted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix a job-&gt;pasid access race in gpu recovery<br /> <br /> Avoid a possible UAF in GPU recovery due to a race between<br /> the sched timeout callback and the tdr work queue.<br /> <br /> The gpu recovery function calls drm_sched_stop() and<br /> later drm_sched_start(). drm_sched_start() restarts<br /> the tdr queue which will eventually free the job. If<br /> the tdr queue frees the job before time out callback<br /> completes, the job will be freed and we&amp;#39;ll get a UAF<br /> when accessing the pasid. Cache it early to avoid the<br /> UAF.<br /> <br /> Example KASAN trace:<br /> [ 493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323<br /> [ 493.074892]<br /> [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary)<br /> [ 493.076493] Tainted: [E]=UNSIGNED_MODULE<br /> [ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019<br /> [ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]<br /> [ 493.076512] Call Trace:<br /> [ 493.076515] <br /> [ 493.076518] dump_stack_lvl+0x64/0x80<br /> [ 493.076529] print_report+0xce/0x630<br /> [ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0<br /> [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077253] kasan_report+0xb8/0xf0<br /> [ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]<br /> [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]<br /> [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]<br /> [ 493.080903] ? pick_task_fair+0x24e/0x330<br /> [ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]<br /> [ 493.081702] ? _raw_spin_lock+0x75/0xc0<br /> [ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]<br /> [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081725] process_one_work+0x679/0xff0<br /> [ 493.081732] worker_thread+0x6ce/0xfd0<br /> [ 493.081736] ? __pfx_worker_thread+0x10/0x10<br /> [ 493.081739] kthread+0x376/0x730<br /> [ 493.081744] ? __pfx_kthread+0x10/0x10<br /> [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081751] ? __pfx_kthread+0x10/0x10<br /> [ 493.081755] ret_from_fork+0x247/0x330<br /> [ 493.081761] ? __pfx_kthread+0x10/0x10<br /> [ 493.081764] ret_from_fork_asm+0x1a/0x30<br /> [ 493.081771] <br /> <br /> (cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: adjust read range correctly for non-block-aligned positions<br /> <br /> iomap_adjust_read_range() assumes that the position and length passed in<br /> are block-aligned. This is not always the case however, as shown in the<br /> syzbot generated case for erofs. This causes too many bytes to be<br /> skipped for uptodate blocks, which results in returning the incorrect<br /> position and length to read in. If all the blocks are uptodate, this<br /> underflows length and returns a position beyond the folio.<br /> <br /> Fix the calculation to also take into account the block offset when<br /> calculating how many bytes can be skipped for uptodate blocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: Avoid overflowing userspace buffer on stats query<br /> <br /> The ethtool -S command operates across three ioctl calls:<br /> ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and<br /> ETHTOOL_GSTATS for the values.<br /> <br /> If the number of stats changes between these calls (e.g., due to device<br /> reconfiguration), userspace&amp;#39;s buffer allocation will be incorrect,<br /> potentially leading to buffer overflow.<br /> <br /> Drivers are generally expected to maintain stable stat counts, but some<br /> drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making<br /> this scenario possible.<br /> <br /> Some drivers try to handle this internally:<br /> - bnad_get_ethtool_stats() returns early in case stats.n_stats is not<br /> equal to the driver&amp;#39;s stats count.<br /> - micrel/ksz884x also makes sure not to write anything beyond<br /> stats.n_stats and overflow the buffer.<br /> <br /> However, both use stats.n_stats which is already assigned with the value<br /> returned from get_sset_count(), hence won&amp;#39;t solve the issue described<br /> here.<br /> <br /> Change ethtool_get_strings(), ethtool_get_stats(),<br /> ethtool_get_phy_stats() to not return anything in case of a mismatch<br /> between userspace&amp;#39;s size and get_sset_size(), to prevent buffer<br /> overflow.<br /> The returned n_stats value will be equal to zero, to reflect that<br /> nothing has been returned.<br /> <br /> This could result in one of two cases when using upstream ethtool,<br /> depending on when the size change is detected:<br /> 1. When detected in ethtool_get_strings():<br /> # ethtool -S eth2<br /> no stats available<br /> <br /> 2. When detected in get stats, all stats will be reported as zero.<br /> <br /> Both cases are presumably transient, and a subsequent ethtool call<br /> should succeed.<br /> <br /> Other than the overflow avoidance, these two cases are very evident (no<br /> output/cleared stats), which is arguably better than presenting<br /> incorrect/shifted stats.<br /> I also considered returning an error instead of a "silent" response, but<br /> that seems more destructive towards userspace apps.<br /> <br /> Notes:<br /> - This patch does not claim to fix the inherent race, it only makes sure<br /> that we do not overflow the userspace buffer, and makes for a more<br /> predictable behavior.<br /> <br /> - RTNL lock is held during each ioctl, the race window exists between<br /> the separate ioctl calls when the lock is released.<br /> <br /> - Userspace ethtool always fills stats.n_stats, but it is likely that<br /> these stats ioctls are implemented in other userspace applications<br /> which might not fill it. The added code checks that it&amp;#39;s not zero,<br /> to prevent any regressions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid updating zero-sized extent in extent cache<br /> <br /> As syzbot reported:<br /> <br /> F2FS-fs (loop0): __update_extent_tree_range: extent len is zero, type: 0, extent [0, 0, 0], age [0, 0]<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/extent_cache.c:678!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678<br /> Call Trace:<br /> <br /> f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085<br /> f2fs_do_zero_range fs/f2fs/file.c:1657 [inline]<br /> f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737<br /> f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030<br /> vfs_fallocate+0x669/0x7e0 fs/open.c:342<br /> ioctl_preallocate fs/ioctl.c:289 [inline]<br /> file_ioctl+0x611/0x780 fs/ioctl.c:-1<br /> do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576<br /> __do_sys_ioctl fs/ioctl.c:595 [inline]<br /> __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f07bc58eec9<br /> <br /> In error path of f2fs_zero_range(), it may add a zero-sized extent<br /> into extent cache, it should be avoided.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: applicom: fix NULL pointer dereference in ac_ioctl<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.<br /> <br /> In ac_ioctl, the validation of IndexCard and the check for a valid<br /> RamIO pointer are skipped when cmd is 6. However, the function<br /> unconditionally executes readb(apbs[IndexCard].RamIO + VERS) at the<br /> end.<br /> <br /> If cmd is 6, IndexCard may reference a board that does not exist<br /> (where RamIO is NULL), leading to a NULL pointer dereference.<br /> <br /> Fix this by skipping the readb access when cmd is 6, as this<br /> command is a global information query and does not target a specific<br /> board context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd: Check event before enable to avoid GPF<br /> <br /> On AMD machines cpuc-&gt;events[idx] can become NULL in a subtle race<br /> condition with NMI-&gt;throttle-&gt;x86_pmu_stop().<br /> <br /> Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.<br /> This appears to be an AMD only issue.<br /> <br /> Syzkaller reported a GPF in amd_pmu_enable_all.<br /> <br /> INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143<br /> msecs<br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]<br /> CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk<br /> RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195<br /> arch/x86/events/core.c:1430)<br /> RSP: 0018:ffff888118009d60 EFLAGS: 00010012<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601<br /> FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))<br /> x86_pmu_enable (arch/x86/events/core.c:1360)<br /> event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186<br /> kernel/events/core.c:2346)<br /> __perf_remove_from_context (kernel/events/core.c:2435)<br /> event_function (kernel/events/core.c:259)<br /> remote_function (kernel/events/core.c:92 (discriminator 1)<br /> kernel/events/core.c:72 (discriminator 1))<br /> __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64<br /> kernel/smp.c:135 kernel/smp.c:540)<br /> __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207<br /> ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)<br /> sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)<br /> arch/x86/kernel/smp.c:266 (discriminator 47))<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> caif: fix integer underflow in cffrml_receive()<br /> <br /> The cffrml_receive() function extracts a length field from the packet<br /> header and, when FCS is disabled, subtracts 2 from this length without<br /> validating that len &gt;= 2.<br /> <br /> If an attacker sends a malicious packet with a length field of 0 or 1<br /> to an interface with FCS disabled, the subtraction causes an integer<br /> underflow.<br /> <br /> This can lead to memory exhaustion and kernel instability, potential<br /> information disclosure if padding contains uninitialized kernel memory.<br /> <br /> Fix this by validating that len &gt;= 2 before performing the subtraction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix double unregister of HCA_PORTS component<br /> <br /> Clear hca_devcom_comp in device&amp;#39;s private data after unregistering it in<br /> LAG teardown. Otherwise a slightly lagging second pass through<br /> mlx5_unload_one() might try to unregister it again and trip over<br /> use-after-free.<br /> <br /> On s390 almost all PCI level recovery events trigger two passes through<br /> mxl5_unload_one() - one through the poll_health() method and one through<br /> mlx5_pci_err_detected() as callback from generic PCI error recovery.<br /> While testing PCI error recovery paths with more kernel debug features<br /> enabled, this issue reproducibly led to kernel panics with the following<br /> call chain:<br /> <br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 ESOP-2 FSI<br /> Fault in home space mode while using kernel ASCE.<br /> AS:00000000705c4007 R3:0000000000000024<br /> Oops: 0038 ilc:3 [#1]SMP<br /> <br /> CPU: 14 UID: 0 PID: 156 Comm: kmcheck Kdump: loaded Not tainted<br /> 6.18.0-20251130.rc7.git0.16131a59cab1.300.fc43.s390x+debug #1 PREEMPT<br /> <br /> Krnl PSW : 0404e00180000000 0000020fc86aa1dc (__lock_acquire+0x5c/0x15f0)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 0000000000000000 0000020f00000001 6b6b6b6b6b6b6c33 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000001 0000000000000000<br /> 0000000000000000 0000020fca28b820 0000000000000000 0000010a1ced8100<br /> 0000010a1ced8100 0000020fc9775068 0000018fce14f8b8 0000018fce14f7f8<br /> Krnl Code: 0000020fc86aa1cc: e3b003400004 lg %r11,832<br /> 0000020fc86aa1d2: a7840211 brc 8,0000020fc86aa5f4<br /> *0000020fc86aa1d6: c09000df0b25 larl %r9,0000020fca28b820<br /> &gt;0000020fc86aa1dc: d50790002000 clc 0(8,%r9),0(%r2)<br /> 0000020fc86aa1e2: a7840209 brc 8,0000020fc86aa5f4<br /> 0000020fc86aa1e6: c0e001100401 larl %r14,0000020fca8aa9e8<br /> 0000020fc86aa1ec: c01000e25a00 larl %r1,0000020fca2f55ec<br /> 0000020fc86aa1f2: a7eb00e8 aghi %r14,232<br /> <br /> Call Trace:<br /> __lock_acquire+0x5c/0x15f0<br /> lock_acquire.part.0+0xf8/0x270<br /> lock_acquire+0xb0/0x1b0<br /> down_write+0x5a/0x250<br /> mlx5_detach_device+0x42/0x110 [mlx5_core]<br /> mlx5_unload_one_devl_locked+0x50/0xc0 [mlx5_core]<br /> mlx5_unload_one+0x42/0x60 [mlx5_core]<br /> mlx5_pci_err_detected+0x94/0x150 [mlx5_core]<br /> zpci_event_attempt_error_recovery+0xcc/0x388