Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: clear freeze listener on node removal<br /> <br /> Generally userspace is supposed to explicitly clear freeze listeners<br /> before they drop the refcount on the node ref to zero, but there&amp;#39;s<br /> nothing forcing that. Currently, in this scenario the freeze listener<br /> remains in the freeze_listeners rbtree and in the remote node&amp;#39;s freeze<br /> listener list, even though the ref for which the listener is registered<br /> is gone. This could potentially lead to a memory leak due to a refcount<br /> cycle. Thus, remove the freeze listener in this scenario.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix NULL pointer dereference in func_set_flag()<br /> <br /> func_set_flag() dereferences tr-&gt;current_trace_flags before verifying<br /> that the current tracer is actually the function tracer. When the active<br /> tracer has been switched away from "function" (e.g., to "wakeup_rt"),<br /> tr-&gt;current_trace_flags can be NULL, leading to a NULL pointer<br /> dereference and kernel crash.<br /> <br /> The call chain that triggers this is:<br /> <br /> trace_options_write()<br /> -&gt; __set_tracer_option()<br /> -&gt; trace-&gt;set_flag() /* func_set_flag */<br /> <br /> In func_set_flag(), the first operation is:<br /> <br /> if (!!set == !!(tr-&gt;current_trace_flags-&gt;val &amp; bit))<br /> <br /> This dereferences tr-&gt;current_trace_flags unconditionally. The safety<br /> check that guards against a non-function tracer:<br /> <br /> if (tr-&gt;current_trace != &amp;function_trace)<br /> return 0;<br /> <br /> is placed *after* the dereference, which is too late.<br /> <br /> This was observed with the following crash dump:<br /> <br /> BUG: unable to handle page fault at 0000000000000000<br /> RIP: func_set_flag+0xd<br /> <br /> Call Trace:<br /> __set_tracer_option+0x27<br /> trace_options_write+0x75<br /> vfs_write+0x12a<br /> ksys_write+0x66<br /> do_syscall_64+0x5b<br /> <br /> RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080<br /> <br /> The disassembly confirms the fault:<br /> <br /> func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr-&gt;current_trace_flags = NULL<br /> func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL<br /> <br /> At the time of the crash:<br /> tr-&gt;current_trace_flags = 0x0 (NULL)<br /> tr-&gt;current_trace = wakeup_rt_tracer (not function_trace)<br /> <br /> The scenario is that a process opens a function tracer option file (such<br /> as "func_stack_trace"), then the current tracer is switched to another<br /> tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When<br /> the process subsequently writes to the option file, func_set_flag() is<br /> invoked and crashes on the NULL dereference.<br /> <br /> Fix this by moving the current_trace check before the<br /> current_trace_flags dereference, so that func_set_flag() returns early<br /> when the function tracer is not active.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 6lowpan: fix NHC entry use-after-free on error path<br /> <br /> lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding<br /> lowpan_nhc_lock. If the descriptor has no uncompress callback, the error<br /> path drops the lock before printing nhc-&gt;name.<br /> <br /> lowpan_nhc_del() removes descriptors under the same lock and then relies<br /> on synchronize_net() before the owning module can be unloaded. That only<br /> waits for net RX RCU readers. lowpan_header_decompress() is also exported<br /> and can be reached from callers that are not necessarily covered by the net<br /> core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive<br /> path.<br /> <br /> This leaves a race where one task drops lowpan_nhc_lock in the error path,<br /> another task unregisters and frees the matching descriptor after<br /> synchronize_net() returns, and the first task then dereferences nhc-&gt;name<br /> for the warning.<br /> <br /> With the post-unlock window widened, KASAN reports:<br /> <br /> BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220<br /> Read of size 8<br /> lowpan_nhc_do_uncompression<br /> lowpan_header_decompress<br /> <br /> Fix this by printing the warning before dropping lowpan_nhc_lock, so the<br /> descriptor name is read while unregister is still excluded. The malformed<br /> packet is still rejected with -ENOTSUPP.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: fix disconnect UAF in client teardown<br /> <br /> usbio_disconnect() walks usbio-&gt;cli_list in reverse and uninitializes each<br /> auxiliary device. auxiliary_device_uninit() drops the device reference, and<br /> for an unbound child that can run usbio_auxdev_release() and free the<br /> containing struct usbio_client.<br /> <br /> list_for_each_entry_reverse() advances after the loop body by reading<br /> client-&gt;link.prev. If the current client is freed by<br /> auxiliary_device_uninit(), the iterator dereferences freed memory.<br /> <br /> Use list_for_each_entry_safe_reverse() so the previous client is<br /> cached before the body can drop the final reference. This preserves<br /> reverse teardown order while keeping the next iterator cursor independent<br /> of the current client&amp;#39;s lifetime.<br /> <br /> Validation reproduced this kernel report:<br /> BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x66/0xa0<br /> print_report+0xce/0x630<br /> ? usbio_disconnect+0x12e/0x150<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __virt_addr_valid+0x188/0x320<br /> ? usbio_disconnect+0x12e/0x150<br /> kasan_report+0xe0/0x110<br /> ? usbio_disconnect+0x12e/0x150<br /> usbio_disconnect+0x12e/0x150<br /> usb_unbind_interface+0xf3/0x400<br /> really_probe+0x316/0x660<br /> __driver_probe_device+0x106/0x240<br /> driver_probe_device+0x4a/0x110<br /> __device_attach_driver+0xf1/0x1a0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> bus_for_each_drv+0xf9/0x160<br /> ? __pfx_bus_for_each_drv+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? trace_hardirqs_on+0x18/0x130<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> __device_attach+0x133/0x2a0<br /> ? __pfx___device_attach+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_raw_spin_unlock+0x9a/0x100<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> device_initial_probe+0x55/0x70<br /> bus_probe_device+0x4a/0xd0<br /> device_add+0x9b9/0xc10<br /> ? __pfx_device_add+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lockdep_hardirqs_on_prepare+0xea/0x1a0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? usb_enable_lpm+0x3c/0x260<br /> usb_set_configuration+0xb64/0xf20<br /> usb_generic_driver_probe+0x5f/0x90<br /> usb_probe_device+0x71/0x1b0<br /> really_probe+0x46b/0x660<br /> __driver_probe_device+0x106/0x240<br /> driver_probe_device+0x4a/0x110<br /> __device_attach_driver+0xf1/0x1a0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> bus_for_each_drv+0xf9/0x160<br /> ? __pfx_bus_for_each_drv+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? trace_hardirqs_on+0x18/0x130<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? _raw_spin_unlock_irqrestore+0x44/0x60<br /> __device_attach+0x133/0x2a0<br /> ? __pfx___device_attach+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_raw_spin_unlock+0x9a/0x100<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> device_initial_probe+0x55/0x70<br /> bus_probe_device+0x4a/0xd0<br /> device_add+0x9b9/0xc10<br /> ? __pfx_device_add+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? add_device_randomness+0xb7/0xf0<br /> usb_new_device+0x492/0x870<br /> hub_event+0x1b10/0x29c0<br /> ? __pfx_hub_event+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lock_acquire+0x187/0x300<br /> ? process_one_work+0x475/0xb90<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? lock_release+0xc8/0x290<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> process_one_work+0x4d7/0xb90<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __list_add_valid_or_report+0x37/0xf0<br /> ? __pfx_hub_event+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> worker_thread+0x2d8/0x570<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1ad/0x1f0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x3c9/0x540<br /> ? __pfx_ret_from_fork+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __switch_to+0x2e9/0x730<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: run gadget disconnect from sleepable suspend context<br /> <br /> dwc3_gadget_suspend() takes dwc-&gt;lock with IRQs disabled and then calls<br /> dwc3_disconnect_gadget(). For async callbacks that helper only uses<br /> plain spin_unlock()/spin_lock(), so the gadget -&gt;disconnect() callback<br /> still runs with IRQs disabled and any sleepable callback trips Lockdep.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the dwc3_gadget_suspend() -&gt;<br /> dwc3_disconnect_gadget() -&gt; gadget_driver-&gt;disconnect() chain, and<br /> Lockdep reported:<br /> <br /> BUG: sleeping function called from invalid context<br /> gadget_disconnect+0x21/0x39 [vuln_msv]<br /> dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv]<br /> <br /> Keep the disconnect callback selection in one common helper, but add a<br /> sleepable suspend-side wrapper which snapshots the callback under<br /> dwc-&gt;lock and then runs it after spin_unlock_irqrestore(). The regular<br /> event path still uses the existing spin_unlock()/spin_lock() window.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: chaoskey: Fix slab-use-after-free in chaoskey_release()<br /> <br /> The chaoskey driver has a use-after-free bug in its release routine.<br /> If the user closes the device file after the USB device has been<br /> unplugged, a debugging log statement will try to access the<br /> usb_interface structure after it has been deallocated:<br /> <br /> BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406)<br /> Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106<br /> <br /> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)<br /> print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)<br /> kasan_report (mm/kasan/report.c:595)<br /> dev_driver_string (drivers/base/core.c:2406)<br /> __dynamic_dev_dbg (lib/dynamic_debug.c:906)<br /> chaoskey_release (drivers/usb/misc/chaoskey.c:323)<br /> __fput (fs/file_table.c:510)<br /> fput_close_sync (fs/file_table.c:615)<br /> __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> The driver&amp;#39;s last reference to the interface structure is dropped in<br /> the chaoskey_free() routine, so the code must not use the interface --<br /> even in a debugging statement -- after that routine returns.<br /> (Exception: If we know that another reference is held by someone else,<br /> such as the device core while the disconnect routine runs, there&amp;#39;s no<br /> problem. Thanks to Johan Hovold for pointing this out.)<br /> <br /> Since the bad access is part of an unimportant debugging statement,<br /> we can fix the problem simply by removing the whole statement.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: virtio: clamp device-reported used.len at copy_data()<br /> <br /> random_recv_done() stores the device-reported used.len directly into<br /> vi-&gt;data_avail. copy_data() then indexes vi-&gt;data[] using<br /> vi-&gt;data_idx (advanced by previous copy_data() calls) and issues a<br /> memcpy() without re-validating either value against the posted<br /> buffer size sizeof(vi-&gt;data) (SMP_CACHE_BYTES bytes, typically 32<br /> or 64).<br /> <br /> A malicious or buggy virtio-rng backend can set used.len beyond<br /> sizeof(vi-&gt;data), steering the memcpy() past the end of the inline<br /> array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes<br /> those bytes into the guest RNG, and guest root can also observe<br /> them directly via /dev/hwrng.<br /> <br /> Concrete impact is inside the guest:<br /> <br /> - Memory-safety / hardening: any virtio-rng backend that<br /> over-reports used.len causes the driver to read past vi-&gt;data<br /> into unrelated slab contents. hwrng_fillfn() is a kernel thread<br /> that runs as soon as the device is probed; no guest userspace<br /> interaction is required to first-trigger the OOB.<br /> <br /> - Cross-boundary leak (confidential-compute threat model): a<br /> malicious hypervisor cooperating with a malicious or compromised<br /> guest root userspace can use /dev/hwrng as a leak channel for<br /> guest-kernel heap data. The host sets a large used.len, guest<br /> root reads /dev/hwrng, and the returned bytes contain guest<br /> kernel slab contents that were adjacent to vi-&gt;data. In<br /> practice, confidential-compute guests (SEV-SNP, TDX) usually<br /> disable virtio-rng entirely, so this path is narrow, but the<br /> fix is still worth carrying because the underlying<br /> memory-safety bug contaminates the guest RNG on any host.<br /> <br /> KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend<br /> has been patched to report used.len = 0x10000:<br /> <br /> BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0<br /> Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52<br /> Call Trace:<br /> __asan_memcpy+0x23/0x60<br /> virtio_read+0x394/0x5d0<br /> hwrng_fillfn+0xb2/0x470<br /> kthread+0x2cc/0x3a0<br /> Allocated by task 1:<br /> probe_common+0xa5/0x660<br /> virtio_dev_probe+0x549/0xbc0<br /> The buggy address belongs to the object at ffff88800ae0b800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 0 bytes to the right of<br /> allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)<br /> <br /> Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer<br /> overflow in USB transport layer"), which hardened<br /> usb9pfs_rx_complete() against unchecked device-reported length in<br /> the USB 9p transport.<br /> <br /> With the clamp at point of use and array_index_nospec() in place,<br /> the same harness boots cleanly: copy_data() returns zero for the<br /> bogus report, the device-supplied bytes after data_idx are<br /> discarded, and the driver issues a fresh request.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pci: fix vq info pointer lookup via wrong index<br /> <br /> Unbinding a virtio balloon device:<br /> <br /> echo virtio0 &gt; /sys/bus/virtio/drivers/virtio_balloon/unbind<br /> <br /> triggers a NULL pointer dereference. The dmesg says:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [...]<br /> RIP: 0010:__list_del_entry_valid_or_report+0x5/0xf0<br /> Call Trace:<br /> <br /> vp_del_vqs+0x121/0x230<br /> remove_common+0x135/0x150<br /> virtballoon_remove+0xee/0x100<br /> virtio_dev_remove+0x3b/0x80<br /> device_release_driver_internal+0x187/0x2c0<br /> unbind_store+0xb9/0xe0<br /> kernfs_fop_write_iter.llvm.11660790530567441834+0xf6/0x180<br /> vfs_write+0x2a9/0x3b0<br /> ksys_write+0x5c/0xd0<br /> do_syscall_64+0x54/0x230<br /> entry_SYSCALL_64_after_hwframe+0x29/0x31<br /> [...]<br /> <br /> <br /> The virtio_balloon device registers 5 queues (inflate, deflate, stats,<br /> free_page, reporting) but only the first two are unconditional. The<br /> stats, free_page and reporting queues are each conditional on their<br /> respective feature bits. When any of these features are absent, the<br /> corresponding vqs_info entry has name == NULL, creating holes in the<br /> array.<br /> <br /> The root cause is an indexing mismatch introduced when vq info storage<br /> was changed to be passed as an argument. vp_find_vqs_msix() and<br /> vp_find_vqs_intx() store the info pointer at vp_dev-&gt;vqs[i], where &amp;#39;i&amp;#39;<br /> is the caller&amp;#39;s sparse array index. However, the virtqueue itself gets<br /> vq-&gt;index assigned from queue_idx, a dense index that skips NULL<br /> entries. When holes exist, &amp;#39;i&amp;#39; and queue_idx diverge. Later,<br /> vp_del_vqs() looks up info via vp_dev-&gt;vqs[vq-&gt;index] using the dense<br /> index into the sparsely-populated array, and hits NULL.<br /> <br /> Fix this by storing info at vp_dev-&gt;vqs[queue_idx] instead of<br /> vp_dev-&gt;vqs[i], so the store index matches the lookup index<br /> (vq-&gt;index). Apply the fix to both the MSIX and INTX paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/ops-common: handle extreme intervals in damon_hot_score()<br /> <br /> Fix three issues in damon_hot_score() that comes from wrong handling of<br /> extreme (zero or too high) monitoring intervals user setup.<br /> <br /> When the user sets sampling interval zero, damon_max_nr_accesses(), which<br /> is called from damon_hot_score(), causes a divide-by-zero. Needless to<br /> say, it is a problem.<br /> <br /> When the user sets the aggregation interval zero, the function returns<br /> zero. It is wrong, since the real maximum nr_acceses in the setup should<br /> be one. Worse yet, it can cause another divide-by-zero from its caller,<br /> damon_hot_score(), since it uses damon_max_nr_accesses() return value as a<br /> denominator.<br /> <br /> When the user sets the aggregation interval very high, damon_hot_score()<br /> could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return<br /> value is used as an index to the regions_score_histogram array, which is<br /> DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.<br /> <br /> The issues can be relatively easily reproduced like below. The sysfs<br /> write permission is required, though.<br /> <br /> # ./damo start --damos_action lru_prio --damos_quota_space 100M \<br /> --damos_quota_interval 1s<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0<br /> # echo 0 &gt; contexts/0/monitoring_attrs/intervals/sample_us<br /> # echo 0 &gt; contexts/0/monitoring_attrs/intervals/aggr_us<br /> # echo commit &gt; state<br /> # dmesg<br /> [...]<br /> [ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI<br /> [...]<br /> [ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0<br /> [...]<br /> <br /> Fix the divide-by-zero intervals problems by explicitly handling the zero<br /> intervals in damon_max_nr_accesses(). Fix the out-of-bound array access<br /> by applying [0, DAMOS_MAX_SCORE] bounds before returning from<br /> damon_hot_score().<br /> <br /> The issue was discovered [1] by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop<br /> <br /> The IE parsing loop in OnAssocRsp() advances by (pIE-&gt;length + 2) each<br /> iteration but only guards on i length<br /> from pframe[pkt_len], which is one byte past the allocated receive buffer.<br /> <br /> Additionally, even when the header bytes are in bounds, pIE-&gt;length<br /> itself can extend the data window beyond pkt_len, silently passing a<br /> truncated IE to the handler functions.<br /> <br /> Add two guards at the top of the loop body:<br /> 1. Break if fewer than sizeof(*pIE) bytes remain (can&amp;#39;t read header).<br /> 2. Break if the IE&amp;#39;s declared data extends past pkt_len.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()<br /> <br /> OnAuth() has two bugs in the shared-key authentication path.<br /> <br /> When the Privacy bit is set, rtw_wep_decrypt() is called without<br /> verifying that the frame is long enough to contain a valid WEP IV and<br /> ICV. Inside rtw_wep_decrypt(), length is computed as:<br /> <br /> length = len - WLAN_HDR_A3_LEN - iv_len<br /> <br /> and then passed as (length - 4) to crc32_le(). If len is less than<br /> WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative<br /> and, after the implicit cast to size_t, causes crc32_le() to read far<br /> beyond the frame buffer. Add a minimum length check before accessing<br /> the IV field and calling the decryption path.<br /> <br /> When processing a seq=3 response, rtw_get_ie() stores the Challenge<br /> Text IE length in ie_len, but the subsequent memcmp() always reads 128<br /> bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of<br /> exactly 128 bytes; reject any IE whose length field differs, matching<br /> the check already applied to OnAuthClient().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie()<br /> <br /> supplicant_ie is a 256-byte array in struct security_priv. The WPA and<br /> WPA2 IE copy paths use:<br /> <br /> memcpy(padapter-&gt;securitypriv.supplicant_ie, &amp;pwpa[0], wpa_ielen + 2);<br /> <br /> where wpa_ielen is the raw IE length field (u8, 0-255). When a local user<br /> supplies a connect request via nl80211 with a crafted WPA IE of length 255,<br /> wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into<br /> the adjacent last_mic_err_time field.<br /> <br /> rtw_parse_wpa_ie() does not prevent this: its length consistency check<br /> compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255<br /> when wpa_ie_len = 257, so the check passes silently.<br /> <br /> Add explicit bounds checks for both the WPA and WPA2 paths before the<br /> memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the<br /> supplicant_ie buffer.