Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix vram leak on bind errors<br /> <br /> Make sure to release the VRAM buffer also in a case a subcomponent fails<br /> to bind.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525094/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: fix NULL pointer dereference when removing device<br /> <br /> In suspend and resume cycle, the removal and rescan of device ends<br /> up in NULL pointer dereference.<br /> <br /> During driver initialization, if the ipc_imem_wwan_channel_init()<br /> fails to get the valid device capabilities it returns an error and<br /> further no resource (wwan struct) will be allocated. Now in this<br /> situation if driver removal procedure is initiated it would result<br /> in NULL pointer exception since unallocated wwan struct is dereferenced<br /> inside ipc_wwan_deinit().<br /> <br /> ipc_imem_run_state_worker() to handle the called functions return value<br /> and to release the resource in failure case. It also reports the link<br /> down event in failure cases. The user space application can handle this<br /> event to do a device reset for restoring the device communication.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/histograms: Add histograms to hist_vars if they have referenced variables<br /> <br /> Hist triggers can have referenced variables without having direct<br /> variables fields. This can be the case if referenced variables are added<br /> for trigger actions. In this case the newly added references will not<br /> have field variables. Not taking such referenced variables into<br /> consideration can result in a bug where it would be possible to remove<br /> hist trigger with variables being refenced. This will result in a bug<br /> that is easily reproducable like so<br /> <br /> $ cd /sys/kernel/tracing<br /> $ echo &amp;#39;synthetic_sys_enter char[] comm; long id&amp;#39; &gt;&gt; synthetic_events<br /> $ echo &amp;#39;hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> $ echo &amp;#39;hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> $ echo &amp;#39;!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> <br /> [ 100.263533] ==================================================================<br /> [ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180<br /> [ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439<br /> [ 100.266320]<br /> [ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4<br /> [ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014<br /> [ 100.268561] Call Trace:<br /> [ 100.268902] <br /> [ 100.269189] dump_stack_lvl+0x4c/0x70<br /> [ 100.269680] print_report+0xc5/0x600<br /> [ 100.270165] ? resolve_var_refs+0xc7/0x180<br /> [ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0<br /> [ 100.271389] ? resolve_var_refs+0xc7/0x180<br /> [ 100.271913] kasan_report+0xbd/0x100<br /> [ 100.272380] ? resolve_var_refs+0xc7/0x180<br /> [ 100.272920] __asan_load8+0x71/0xa0<br /> [ 100.273377] resolve_var_refs+0xc7/0x180<br /> [ 100.273888] event_hist_trigger+0x749/0x860<br /> [ 100.274505] ? kasan_save_stack+0x2a/0x50<br /> [ 100.275024] ? kasan_set_track+0x29/0x40<br /> [ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10<br /> [ 100.276138] ? ksys_write+0xd1/0x170<br /> [ 100.276607] ? do_syscall_64+0x3c/0x90<br /> [ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 100.277771] ? destroy_hist_data+0x446/0x470<br /> [ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860<br /> [ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10<br /> [ 100.279627] ? __kasan_check_write+0x18/0x20<br /> [ 100.280177] ? mutex_unlock+0x85/0xd0<br /> [ 100.280660] ? __pfx_mutex_unlock+0x10/0x10<br /> [ 100.281200] ? kfree+0x7b/0x120<br /> [ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0<br /> [ 100.282197] ? event_trigger_write+0xac/0x100<br /> [ 100.282764] ? __kasan_slab_free+0x16/0x20<br /> [ 100.283293] ? __kmem_cache_free+0x153/0x2f0<br /> [ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250<br /> [ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10<br /> [ 100.285221] ? event_trigger_write+0xbc/0x100<br /> [ 100.285781] ? __kasan_check_read+0x15/0x20<br /> [ 100.286321] ? __bitmap_weight+0x66/0xa0<br /> [ 100.286833] ? _find_next_bit+0x46/0xe0<br /> [ 100.287334] ? task_mm_cid_work+0x37f/0x450<br /> [ 100.287872] event_triggers_call+0x84/0x150<br /> [ 100.288408] trace_event_buffer_commit+0x339/0x430<br /> [ 100.289073] ? ring_buffer_event_data+0x3f/0x60<br /> [ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0<br /> [ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0<br /> [ 100.298653] syscall_enter_from_user_mode+0x32/0x40<br /> [ 100.301808] do_syscall_64+0x1a/0x90<br /> [ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 100.307775] RIP: 0033:0x7f686c75c1cb<br /> [ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48<br /> [ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021<br /> [ 100.321200] RA<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_vti: fix potential slab-use-after-free in decode_session6<br /> <br /> When ip_vti device is set to the qdisc of the sfb type, the cb field<br /> of the sent skb may be modified during enqueuing. Then,<br /> slab-use-after-free may occur when ip_vti device sends IPv6 packets.<br /> As commit f855691975bb ("xfrm6: Fix the nexthdr offset in<br /> _decode_session6.") showed, xfrm_decode_session was originally intended<br /> only for the receive path. IP6CB(skb)-&gt;nhoff is not set during<br /> transmission. Therefore, set the cb field in the skb to 0 before<br /> sending packets.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()<br /> <br /> pr_info() is called with rtp-&gt;cbs_gbl_lock spin lock locked. Because<br /> pr_info() calls printk() that might sleep, this will result in BUG<br /> like below:<br /> <br /> [ 0.206455] cblist_init_generic: Setting adjustable number of callback queues.<br /> [ 0.206463]<br /> [ 0.206464] =============================<br /> [ 0.206464] [ BUG: Invalid wait context ]<br /> [ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted<br /> [ 0.206466] -----------------------------<br /> [ 0.206466] swapper/0/1 is trying to lock:<br /> [ 0.206467] ffffffffa0167a58 (&amp;port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0<br /> [ 0.206473] other info that might help us debug this:<br /> [ 0.206473] context-{5:5}<br /> [ 0.206474] 3 locks held by swapper/0/1:<br /> [ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0<br /> [ 0.206478] #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e<br /> [ 0.206482] #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330<br /> [ 0.206485] stack backtrace:<br /> [ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5<br /> [ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014<br /> [ 0.206489] Call Trace:<br /> [ 0.206490] <br /> [ 0.206491] dump_stack_lvl+0x6a/0x9f<br /> [ 0.206493] __lock_acquire.cold+0x2d7/0x2fe<br /> [ 0.206496] ? stack_trace_save+0x46/0x70<br /> [ 0.206497] lock_acquire+0xd1/0x2f0<br /> [ 0.206499] ? serial8250_console_write+0x327/0x4a0<br /> [ 0.206500] ? __lock_acquire+0x5c7/0x2720<br /> [ 0.206502] _raw_spin_lock_irqsave+0x3d/0x90<br /> [ 0.206504] ? serial8250_console_write+0x327/0x4a0<br /> [ 0.206506] serial8250_console_write+0x327/0x4a0<br /> [ 0.206508] console_emit_next_record.constprop.0+0x180/0x330<br /> [ 0.206511] console_unlock+0xf7/0x1f0<br /> [ 0.206512] vprintk_emit+0xf7/0x330<br /> [ 0.206514] _printk+0x63/0x7e<br /> [ 0.206516] cblist_init_generic.constprop.0.cold+0x24/0x32<br /> [ 0.206518] rcu_init_tasks_generic+0x5/0xd9<br /> [ 0.206522] kernel_init_freeable+0x15b/0x2a2<br /> [ 0.206523] ? rest_init+0x160/0x160<br /> [ 0.206526] kernel_init+0x11/0x120<br /> [ 0.206527] ret_from_fork+0x1f/0x30<br /> [ 0.206530] <br /> [ 0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.<br /> <br /> This patch moves pr_info() so that it is called without<br /> rtp-&gt;cbs_gbl_lock locked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fprobe: Release rethook after the ftrace_ops is unregistered<br /> <br /> While running bpf selftests it&amp;#39;s possible to get following fault:<br /> <br /> general protection fault, probably for non-canonical address \<br /> 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI<br /> ...<br /> Call Trace:<br /> <br /> fprobe_handler+0xc1/0x270<br /> ? __pfx_bpf_testmod_init+0x10/0x10<br /> ? __pfx_bpf_testmod_init+0x10/0x10<br /> ? bpf_fentry_test1+0x5/0x10<br /> ? bpf_fentry_test1+0x5/0x10<br /> ? bpf_testmod_init+0x22/0x80<br /> ? do_one_initcall+0x63/0x2e0<br /> ? rcu_is_watching+0xd/0x40<br /> ? kmalloc_trace+0xaf/0xc0<br /> ? do_init_module+0x60/0x250<br /> ? __do_sys_finit_module+0xac/0x120<br /> ? do_syscall_64+0x37/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> <br /> In unregister_fprobe function we can&amp;#39;t release fp-&gt;rethook while it&amp;#39;s<br /> possible there are some of its users still running on another cpu.<br /> <br /> Moving rethook_free call after fp-&gt;ops is unregistered with<br /> unregister_ftrace_function call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Rework long task execution when adding/deleting entries<br /> <br /> When adding/deleting large number of elements in one step in ipset, it can<br /> take a reasonable amount of time and can result in soft lockup errors. The<br /> patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of<br /> consecutive elements to add/delete") tried to fix it by limiting the max<br /> elements to process at all. However it was not enough, it is still possible<br /> that we get hung tasks. Lowering the limit is not reasonable, so the<br /> approach in this patch is as follows: rely on the method used at resizing<br /> sets and save the state when we reach a smaller internal batch limit,<br /> unlock/lock and proceed from the saved state. Thus we can avoid long<br /> continuous tasks and at the same time removed the limit to add/delete large<br /> number of elements in one step.<br /> <br /> The nfnl mutex is held during the whole operation which prevents one to<br /> issue other ipset commands in parallel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb<br /> <br /> The syzbot fuzzer identified a problem in the usbnet driver:<br /> <br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7<br /> RSP: 0018:ffffc9000463f568 EFLAGS: 00010086<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001<br /> RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003<br /> R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453<br /> __netdev_start_xmit include/linux/netdevice.h:4918 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4932 [inline]<br /> xmit_one net/core/dev.c:3578 [inline]<br /> dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594<br /> ...<br /> <br /> This bug is caused by the fact that usbnet trusts the bulk endpoint<br /> addresses its probe routine receives in the driver_info structure, and<br /> it does not check to see that these endpoints actually exist and have<br /> the expected type and directions.<br /> <br /> The fix is simply to add such a check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix use-after-free in free_netdev<br /> <br /> We do netif_napi_add() for all allocated q_vectors[], but potentially<br /> do netif_napi_del() for part of them, then kfree q_vectors and leave<br /> invalid pointers at dev-&gt;napi_list.<br /> <br /> Reproducer:<br /> <br /> [root@host ~]# cat repro.sh<br /> #!/bin/bash<br /> <br /> pf_dbsf="0000:41:00.0"<br /> vf0_dbsf="0000:41:02.0"<br /> g_pids=()<br /> <br /> function do_set_numvf()<br /> {<br /> echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> }<br /> <br /> function do_set_channel()<br /> {<br /> local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)<br /> [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }<br /> ifconfig $nic 192.168.18.5 netmask 255.255.255.0<br /> ifconfig $nic up<br /> ethtool -L $nic combined 1<br /> ethtool -L $nic combined 4<br /> sleep $((RANDOM%3))<br /> }<br /> <br /> function on_exit()<br /> {<br /> local pid<br /> for pid in "${g_pids[@]}"; do<br /> kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null<br /> done<br /> g_pids=()<br /> }<br /> <br /> trap "on_exit; exit" EXIT<br /> <br /> while :; do do_set_numvf ; done &amp;<br /> g_pids+=($!)<br /> while :; do do_set_channel ; done &amp;<br /> g_pids+=($!)<br /> <br /> wait<br /> <br /> Result:<br /> <br /> [ 4093.900222] ==================================================================<br /> [ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390<br /> [ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699<br /> [ 4093.900233]<br /> [ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1<br /> [ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021<br /> [ 4093.900239] Call Trace:<br /> [ 4093.900244] dump_stack+0x71/0xab<br /> [ 4093.900249] print_address_description+0x6b/0x290<br /> [ 4093.900251] ? free_netdev+0x308/0x390<br /> [ 4093.900252] kasan_report+0x14a/0x2b0<br /> [ 4093.900254] free_netdev+0x308/0x390<br /> [ 4093.900261] iavf_remove+0x825/0xd20 [iavf]<br /> [ 4093.900265] pci_device_remove+0xa8/0x1f0<br /> [ 4093.900268] device_release_driver_internal+0x1c6/0x460<br /> [ 4093.900271] pci_stop_bus_device+0x101/0x150<br /> [ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 4093.900275] pci_iov_remove_virtfn+0x187/0x420<br /> [ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10<br /> [ 4093.900278] ? pci_get_subsys+0x90/0x90<br /> [ 4093.900280] sriov_disable+0xed/0x3e0<br /> [ 4093.900282] ? bus_find_device+0x12d/0x1a0<br /> [ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e]<br /> [ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e]<br /> [ 4093.900299] ? pci_get_device+0x7c/0x90<br /> [ 4093.900300] ? pci_get_subsys+0x90/0x90<br /> [ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210<br /> [ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]<br /> [ 4093.900318] sriov_numvfs_store+0x214/0x290<br /> [ 4093.900320] ? sriov_totalvfs_show+0x30/0x30<br /> [ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 4093.900323] ? __check_object_size+0x15a/0x350<br /> [ 4093.900326] kernfs_fop_write+0x280/0x3f0<br /> [ 4093.900329] vfs_write+0x145/0x440<br /> [ 4093.900330] ksys_write+0xab/0x160<br /> [ 4093.900332] ? __ia32_sys_read+0xb0/0xb0<br /> [ 4093.900334] ? fput_many+0x1a/0x120<br /> [ 4093.900335] ? filp_close+0xf0/0x130<br /> [ 4093.900338] do_syscall_64+0xa0/0x370<br /> [ 4093.900339] ? page_fault+0x8/0x30<br /> [ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 4093.900357] RIP: 0033:0x7f16ad4d22c0<br /> [ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24<br /> [ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0<br /> [ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001<br /> [ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700<br /> [ 4093.9003<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: initialize damo_filter-&gt;list from damos_new_filter()<br /> <br /> damos_new_filter() is not initializing the list field of newly allocated<br /> filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not<br /> initializing it after calling damos_new_filter(). As a result, accessing<br /> uninitialized memory is possible. Actually, adding multiple DAMOS filters<br /> via DAMON sysfs interface caused NULL pointer dereferencing. Initialize<br /> the field just after the allocation from damos_new_filter().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()<br /> <br /> The "exc-&gt;key_len" is a u16 that comes from the user. If it&amp;#39;s over<br /> IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hyperv: avoid struct memcpy overrun warning<br /> <br /> A previous patch addressed the fortified memcpy warning for most<br /> builds, but I still see this one with gcc-9:<br /> <br /> In file included from include/linux/string.h:254,<br /> from drivers/hid/hid-hyperv.c:8:<br /> In function &amp;#39;fortify_memcpy_chk&amp;#39;,<br /> inlined from &amp;#39;mousevsc_on_receive&amp;#39; at drivers/hid/hid-hyperv.c:272:3:<br /> include/linux/fortify-string.h:583:4: error: call to &amp;#39;__write_overflow_field&amp;#39; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]<br /> 583 | __write_overflow_field(p_size_field, size);<br /> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> My guess is that the WARN_ON() itself is what confuses gcc, so it no<br /> longer sees that there is a correct range check. Rework the code in a<br /> way that helps readability and avoids the warning.