Vulnerabilities

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 /> mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats<br /> <br /> Cited commit added a dedicated mutex (instead of RTNL) to protect the<br /> multicast route list, so that it will not change while the driver<br /> periodically traverses it in order to update the kernel about multicast<br /> route stats that were queried from the device.<br /> <br /> One instance of list entry deletion (during route replace) was missed<br /> and it can result in a use-after-free [1].<br /> <br /> Fix by acquiring the mutex before deleting the entry from the list and<br /> releasing it afterwards.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043<br /> <br /> CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)<br /> Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017<br /> Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> print_report+0x174/0x4f5<br /> kasan_report+0xdf/0x110<br /> mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x70<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x14e/0x700<br /> mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_router: Fix neighbour use-after-free<br /> <br /> We sometimes observe use-after-free when dereferencing a neighbour [1].<br /> The problem seems to be that the driver stores a pointer to the<br /> neighbour, but without holding a reference on it. A reference is only<br /> taken when the neighbour is used by a nexthop.<br /> <br /> Fix by simplifying the reference counting scheme. Always take a<br /> reference when storing a neighbour pointer in a neighbour entry. Avoid<br /> taking a referencing when the neighbour is used by a nexthop as the<br /> neighbour entry associated with the nexthop already holds a reference.<br /> <br /> Tested by running the test that uncovered the problem over 300 times.<br /> Without this patch the problem was reproduced after a handful of<br /> iterations.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> Read of size 8 at addr ffff88817f8e3420 by task ip/3929<br /> <br /> CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)<br /> Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6e/0x300<br /> print_report+0xfc/0x1fb<br /> kasan_report+0xe4/0x110<br /> mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> mlxsw_sp_router_rif_gone_sync+0x35f/0x510<br /> mlxsw_sp_rif_destroy+0x1ea/0x730<br /> mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0<br /> __mlxsw_sp_inetaddr_lag_event+0xcc/0x130<br /> __mlxsw_sp_inetaddr_event+0xf5/0x3c0<br /> mlxsw_sp_router_netdevice_event+0x1015/0x1580<br /> notifier_call_chain+0xcc/0x150<br /> call_netdevice_notifiers_info+0x7e/0x100<br /> __netdev_upper_dev_unlink+0x10b/0x210<br /> netdev_upper_dev_unlink+0x79/0xa0<br /> vrf_del_slave+0x18/0x50<br /> do_set_master+0x146/0x7d0<br /> do_setlink.isra.0+0x9a0/0x2880<br /> rtnl_newlink+0x637/0xb20<br /> rtnetlink_rcv_msg+0x6fe/0xb90<br /> netlink_rcv_skb+0x123/0x380<br /> netlink_unicast+0x4a3/0x770<br /> netlink_sendmsg+0x75b/0xc90<br /> __sock_sendmsg+0xbe/0x160<br /> ____sys_sendmsg+0x5b2/0x7d0<br /> ___sys_sendmsg+0xfd/0x180<br /> __sys_sendmsg+0x124/0x1c0<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [...]<br /> <br /> Allocated by task 109:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7b/0x90<br /> __kmalloc_noprof+0x2c1/0x790<br /> neigh_alloc+0x6af/0x8f0<br /> ___neigh_create+0x63/0xe90<br /> mlxsw_sp_nexthop_neigh_init+0x430/0x7e0<br /> mlxsw_sp_nexthop_type_init+0x212/0x960<br /> mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280<br /> mlxsw_sp_nexthop6_group_get+0x392/0x6a0<br /> mlxsw_sp_fib6_entry_create+0x46a/0xfd0<br /> mlxsw_sp_router_fib6_replace+0x1ed/0x5f0<br /> mlxsw_sp_router_fib6_event_work+0x10a/0x2a0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Freed by task 154:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kmem_cache_free_bulk.part.0+0x1eb/0x5e0<br /> kvfree_rcu_bulk+0x1f2/0x260<br /> kfree_rcu_work+0x130/0x1b0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x30/0x50<br /> kasan_record_aux_stack+0x8c/0xa0<br /> kvfree_call_rcu+0x93/0x5b0<br /> mlxsw_sp_router_neigh_event_work+0x67d/0x860<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: NFSv4 file creation neglects setting ACL<br /> <br /> An NFSv4 client that sets an ACL with a named principal during file<br /> creation retrieves the ACL afterwards, and finds that it is only a<br /> default ACL (based on the mode bits) and not the ACL that was<br /> requested during file creation. This violates RFC 8881 section<br /> 6.4.1.3: "the ACL attribute is set as given".<br /> <br /> The issue occurs in nfsd_create_setattr(), which calls<br /> nfsd_attrs_valid() to determine whether to call nfsd_setattr().<br /> However, nfsd_attrs_valid() checks only for iattr changes and<br /> security labels, but not POSIX ACLs. When only an ACL is present,<br /> the function returns false, nfsd_setattr() is skipped, and the<br /> POSIX ACL is never applied to the inode.<br /> <br /> Subsequently, when the client retrieves the ACL, the server finds<br /> no POSIX ACL on the inode and returns one generated from the file&amp;#39;s<br /> mode bits rather than returning the originally-specified ACL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver<br /> <br /> After unbinding the driver, another kthread `cros_ec_console_log_work`<br /> is still accessing the device, resulting an UAF and crash.<br /> <br /> The driver doesn&amp;#39;t unregister the EC device in .remove() which should<br /> shutdown sub-devices synchronously. Fix it.

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 /> 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 /> 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 /> 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 /> 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.