Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: ipu7: fix double-free and use-after-free in error paths<br /> <br /> In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and<br /> then passed to ipu7_bus_initialize_device(), which stores it in<br /> adev-&gt;pdata. The ipu7_bus_release() function frees adev-&gt;pdata when the<br /> device&amp;#39;s reference count drops to zero.<br /> <br /> Two error paths incorrectly call kfree(pdata) after the device teardown<br /> has already freed it:<br /> <br /> 1. When ipu7_mmu_init() fails: put_device() is called, which drops the<br /> reference count to zero and triggers ipu7_bus_release() -&gt;<br /> kfree(pdata). The subsequent kfree(pdata) is a double-free.<br /> <br /> 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit()<br /> internally, which calls put_device() -&gt; ipu7_bus_release() -&gt;<br /> kfree(pdata). The subsequent kfree(pdata) is again a double-free.<br /> <br /> Note that the kfree(pdata) when ipu7_bus_initialize_device() itself<br /> fails is correct, because in that case auxiliary_device_init() failed<br /> and the release function was never set up, so pdata must be freed<br /> manually.<br /> <br /> Additionally, the error code was not saved before calling put_device(),<br /> causing ERR_CAST() to dereference the already-freed adev pointer when<br /> constructing the return value. Fix this by saving the error from<br /> dev_err_probe() before put_device() and returning ERR_PTR() instead.<br /> <br /> Remove the redundant kfree(pdata) calls and fix the use-after-free in<br /> the return values of the two affected error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: restrict implied bcc[0] exemption to responses without data area<br /> <br /> smb2_check_message() has a long-standing quirk that accepts a response<br /> whose calculated length is one byte larger than the bytes actually<br /> received ("server can return one byte more due to implied bcc[0]").<br /> This was introduced to accommodate servers that omit the trailing bcc[0]<br /> overlap byte when no data area is present.<br /> <br /> However, the exemption is applied unconditionally, regardless of whether<br /> the command actually carries a data area (has_smb2_data_area[]). When a<br /> response with a data area is subject to the +1 exemption, the reported<br /> data can extend one byte beyond the bytes actually received, yet<br /> smb2_check_message() still accepts it. The subsequent decoder then reads<br /> past the end of the receive buffer. This is reachable during NEGOTIATE<br /> and SESSION_SETUP, before the session is established.<br /> <br /> The resulting out-of-bounds reads are visible under KASAN when mounting<br /> against a non-conforming server; both the SPNEGO/negTokenInit and the<br /> NTLMSSP challenge decoders are affected:<br /> <br /> BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00<br /> Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81<br /> CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4e/0x70<br /> print_report+0x157/0x4c9<br /> kasan_report+0xce/0x100<br /> asn1_ber_decoder+0x16a7/0x1b00<br /> decode_negTokenInit+0x19/0x30<br /> SMB2_negotiate+0x31d9/0x4c90<br /> cifs_negotiate_protocol+0x1f2/0x3f0<br /> cifs_get_smb_ses+0x93f/0x17e0<br /> cifs_mount_get_session+0x7f/0x3a0<br /> cifs_mount+0xb4/0xcf0<br /> cifs_smb3_do_mount+0x23a/0x1500<br /> smb3_get_tree+0x3b0/0x630<br /> vfs_get_tree+0x82/0x2d0<br /> fc_mount+0x10/0x1b0<br /> path_mount+0x50d/0x1de0<br /> __x64_sys_mount+0x20b/0x270<br /> do_syscall_64+0xee/0x590<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Allocated by task 85:<br /> kmem_cache_alloc_noprof+0x106/0x380<br /> mempool_alloc_noprof+0x116/0x1e0<br /> cifs_small_buf_get+0x31/0x80<br /> allocate_buffers+0x10d/0x2b0<br /> cifs_demultiplex_thread+0x1d5/0x1d50<br /> kthread+0x2c6/0x390<br /> ret_from_fork+0x36e/0x5a0<br /> ret_from_fork_asm+0x1a/0x30<br /> The buggy address is located 0 bytes to the right of<br /> allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0)<br /> which belongs to the cache cifs_small_rq of size 448<br /> <br /> BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50<br /> Read of size 329 at addr ffff88800726c678 by task mount.cifs/89<br /> CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4e/0x70<br /> print_report+0x157/0x4c9<br /> kasan_report+0xce/0x100<br /> kasan_check_range+0x10f/0x1e0<br /> __asan_memcpy+0x23/0x60<br /> kmemdup_noprof+0x36/0x50<br /> decode_ntlmssp_challenge+0x457/0x680<br /> SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0<br /> SMB2_sess_setup+0x219/0x4f0<br /> cifs_setup_session+0x248/0xaf0<br /> cifs_get_smb_ses+0xf79/0x17e0<br /> cifs_mount_get_session+0x7f/0x3a0<br /> cifs_mount+0xb4/0xcf0<br /> cifs_smb3_do_mount+0x23a/0x1500<br /> smb3_get_tree+0x3b0/0x630<br /> vfs_get_tree+0x82/0x2d0<br /> fc_mount+0x10/0x1b0<br /> path_mount+0x50d/0x1de0<br /> __x64_sys_mount+0x20b/0x270<br /> do_syscall_64+0xee/0x590<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Allocated by task 93:<br /> kmem_cache_alloc_noprof+0x106/0x380<br /> mempool_alloc_noprof+0x116/0x1e0<br /> cifs_small_buf_get+0x31/0x80<br /> allocate_buffers+0x10d/0x2b0<br /> cifs_demultiplex_thread+0x1d5/0x1d50<br /> kthread+0x2c6/0x390<br /> ret_from_fork+0x36e/0x5a0<br /> ret_from_fork_asm+0x1a/0x30<br /> The buggy address is located 120 bytes inside of<br /> allocated 448-byte region [ffff88800726c600, ffff88800726c7c0)<br /> which belongs to the cache cifs_small_rq of size 448<br /> <br /> Restrict the +1 exemption to responses that have no data area, so that<br /> it still covers the bcc[0] omission it was meant for. When a data area<br /> is present, the +1 discrepancy instead means the reported data length<br /> overruns the<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vme_user: bound slave read/write to the kern_buf size<br /> <br /> The SLAVE-path helpers buffer_to_user() and buffer_from_user() copy<br /> &amp;#39;count&amp;#39; bytes into/out of the fixed-size kern_buf (size_buf ==<br /> PCI_BUF_SIZE == 0x20000, 128 KiB) using *ppos as the offset, without<br /> bounding *ppos + count against size_buf.<br /> <br /> vme_user_write()/vme_user_read() only clamp count to the VME window size<br /> (image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the<br /> user-supplied slave.size -- validated against the VME address space (up<br /> to VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE. When the window<br /> exceeds 128 KiB, a write()/read() copies past the kern_buf allocation.<br /> <br /> Clamp count against size_buf in both helpers, with an early return when<br /> *ppos is already at/after the buffer end. *ppos is &gt;= 0 here (the caller<br /> rejects negative offsets), so size_buf - *ppos cannot wrap. This mirrors<br /> the existing clamp in the MASTER-path helpers resource_to_user() /<br /> resource_from_user(), and matches the read()/write() convention of a<br /> short transfer at end-of-buffer.<br /> <br /> Found by static analysis (CodeQL taint tracking + CBMC bounded model<br /> checking) and confirmed dynamically under KASAN with the vme_fake bridge:<br /> <br /> BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80<br /> Write of size 262144 at addr ffff888004100000 by task trigger/68<br /> _copy_from_user+0x2d/0x80<br /> vme_user_write+0x13e/0x240 [vme_user]<br /> vfs_write+0x1b8/0x7a0<br /> ksys_write+0xb8/0x150

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix out-of-bounds read in broadcast Gap ACK blocks<br /> <br /> A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its<br /> data area. tipc_get_gap_ack_blks() only verifies that the record&amp;#39;s len<br /> field is self-consistent with its ugack_cnt/bgack_cnt counts<br /> (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check<br /> that the record actually fits in the message data area, msg_data_sz().<br /> <br /> The unicast caller tipc_link_proto_rcv() bounds it ("if (glen &gt; dlen)<br /> break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the<br /> returned size, so tipc_link_advance_transmq() copies the record off the<br /> receive skb with an attacker-controlled count:<br /> <br /> this_ga = kmemdup(ga, struct_size(ga, gacks, ga-&gt;bgack_cnt),<br /> GFP_ATOMIC);<br /> <br /> A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one<br /> ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its<br /> data area is short, carrying a Gap ACK record with len = 0x400,<br /> bgack_cnt = 0xff and ugack_cnt = 0. len then equals<br /> struct_size(p, gacks, 255), so the consistency check passes and ga is<br /> non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out<br /> of the much smaller skb:<br /> <br /> BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60<br /> Read of size 1024 at addr ffff0000c7030d38 by task poc864/69<br /> Call trace:<br /> kmemdup_noprof+0x48/0x60<br /> tipc_link_advance_transmq+0x86c/0xb80<br /> tipc_link_bc_ack_rcv+0x19c/0x1e0<br /> tipc_bcast_sync_rcv+0x1c4/0x2c4<br /> tipc_rcv+0x85c/0x1340<br /> tipc_l2_rcv_msg+0xac/0x104<br /> The buggy address belongs to the object at ffff0000c7030d00<br /> which belongs to the cache skbuff_small_head of size 704<br /> The buggy address is located 56 bytes inside of<br /> allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0)<br /> <br /> The copied-out bytes are subsequently consumed as gap/ack values, but<br /> the read is already out of bounds at the kmemdup() regardless of how<br /> they are used.<br /> <br /> The unicast STATE path drops such a message: "if (glen &gt; dlen) break;"<br /> skips the rest of STATE_MSG handling and the skb is freed. Make the<br /> broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record<br /> against msg_data_sz() and, when it does not fit, reports it back through<br /> tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than<br /> processed. ga is not cleared on this path: ga == NULL already means<br /> "legacy peer without Selective ACK", a distinct legitimate state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_key: initialize alg_key_len for IPComp states<br /> <br /> pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by<br /> allocating x-&gt;calg and copying only the algorithm name:<br /> <br /> x-&gt;calg = kmalloc_obj(*x-&gt;calg);<br /> if (!x-&gt;calg) {<br /> err = -ENOMEM;<br /> goto out;<br /> }<br /> strcpy(x-&gt;calg-&gt;alg_name, a-&gt;name);<br /> x-&gt;props.calgo = sa-&gt;sadb_sa_encrypt;<br /> <br /> Unlike the authentication (x-&gt;aalg) and encryption (x-&gt;ealg) branches of<br /> the same function, the compression branch never initializes<br /> calg-&gt;alg_key_len. IPComp carries no key and the allocation only<br /> reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field<br /> is left containing uninitialized slab data.<br /> <br /> calg-&gt;alg_key_len is later used as a length by xfrm_algo_clone() when an<br /> IPComp state is cloned during XFRM_MSG_MIGRATE:<br /> <br /> xfrm_state_migrate()<br /> xfrm_state_clone_and_setup()<br /> x-&gt;calg = xfrm_algo_clone(orig-&gt;calg);<br /> kmemdup(orig, xfrm_alg_len(orig));<br /> <br /> where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With<br /> a non-zero garbage alg_key_len, kmemdup() reads past the end of the<br /> 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating<br /> it triggers (net-next, KASAN, init_on_alloc=0):<br /> <br /> BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60<br /> Read of size 4164 at addr ff11000025a74980 by task diag2/9287<br /> CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x10e/0x1f0<br /> print_report+0xf7/0x600<br /> kasan_report+0xe4/0x120<br /> kasan_check_range+0x105/0x1b0<br /> __asan_memcpy+0x23/0x60<br /> kmemdup_noprof+0x44/0x60<br /> xfrm_state_migrate+0x70a/0x1da0<br /> xfrm_migrate+0x753/0x18a0<br /> xfrm_do_migrate+0xb47/0xf10<br /> xfrm_user_rcv_msg+0x411/0xb50<br /> netlink_rcv_skb+0x158/0x420<br /> xfrm_netlink_rcv+0x71/0x90<br /> netlink_unicast+0x584/0x850<br /> netlink_sendmsg+0x8b0/0xdc0<br /> ____sys_sendmsg+0x9f7/0xb90<br /> ___sys_sendmsg+0x134/0x1d0<br /> __sys_sendmsg+0x16d/0x220<br /> do_syscall_64+0x116/0x7d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Allocated by task 9287:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> pfkey_add+0x2652/0x2ea0<br /> pfkey_process+0x6d0/0x830<br /> pfkey_sendmsg+0x42c/0x850<br /> __sys_sendto+0x461/0x4b0<br /> __x64_sys_sendto+0xe0/0x1c0<br /> do_syscall_64+0x116/0x7d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The buggy address belongs to the object at ff11000025a74980<br /> which belongs to the cache kmalloc-96 of size 96<br /> The buggy address is located 0 bytes inside of<br /> allocated 68-byte region [ff11000025a74980, ff11000025a749c4)<br /> <br /> Depending on the uninitialized value the same field can instead request<br /> an oversized kmemdup() allocation and make the migration clone fail.<br /> <br /> The XFRM netlink path is not affected: verify_one_alg() rejects an<br /> XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via<br /> XFRM_MSG_NEWSA is always self-consistent.<br /> <br /> Initialize calg-&gt;alg_key_len to 0, matching the aalg/ealg branches.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL<br /> <br /> Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on<br /> double SMB2_CANCEL") made smb2_cancel() skip a work whose state is<br /> KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But<br /> KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same<br /> freeing producer path is reached for CLOSED too:<br /> <br /> SMB2_CLOSE on the locking handle -&gt; set_close_state_blocked_works() sets<br /> the deferred work&amp;#39;s state to KSMBD_WORK_CLOSED and wakes the smb2_lock()<br /> worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s<br /> the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes<br /> the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the<br /> cancelled branch, skips release_async_work(). The work stays on<br /> conn-&gt;async_requests with a live cancel_fn = smb2_remove_blocked_lock<br /> pointing at the freed file_lock.<br /> <br /> A subsequent SMB2_CANCEL for the same AsyncId then passes the<br /> KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so<br /> smb2_cancel() fires cancel_fn again over the freed file_lock -- the same<br /> use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL:<br /> <br /> BUG: KASAN: slab-use-after-free in __locks_delete_block<br /> __locks_delete_block<br /> locks_delete_block<br /> ksmbd_vfs_posix_lock_unblock<br /> smb2_remove_blocked_lock<br /> smb2_cancel

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()<br /> <br /> The VF2PF interrupt handler queues PF-side response work that stores a<br /> raw pointer to per-VF state (struct adf_accel_vf_info). Currently,<br /> adf_disable_sriov() destroys per-VF mutexes and frees vf_info without<br /> stopping new VF2PF work or waiting for in-flight workers to complete. A<br /> concurrently scheduled or already queued worker can then dereference<br /> freed memory.<br /> <br /> This manifests as a use-after-free when KASAN is enabled:<br /> <br /> BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0<br /> Write of size 8 at addr 0000000000000260 by task kworker/24:2/...<br /> Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat]<br /> Call Trace:<br /> kasan_report+0x119/0x140<br /> mutex_lock+0x76/0xe0<br /> adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat]<br /> adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat]<br /> adf_iov_send_resp+0x8c/0xe0 [intel_qat]<br /> process_one_work+0x6ac/0xfd0<br /> worker_thread+0x4dd/0xd30<br /> kthread+0x326/0x410<br /> ret_from_fork+0x33b/0x670<br /> <br /> Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker<br /> processing, and interrupt re-enabling during teardown. Set this flag<br /> atomically with the hardware interrupt mask inside<br /> adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE<br /> cluster MSI-X interrupt and flush the PF response workqueue before<br /> tearing down per-VF locks and state so all in-flight work completes<br /> before vf_info is destroyed.<br /> <br /> Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and<br /> unmask all VF2PF interrupts under the same lock when SR-IOV is<br /> re-enabled. This ensures the software flag and hardware state transition<br /> atomically on both the enable and disable paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: krb5 - filter out async aead implementations at alloc<br /> <br /> krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and<br /> rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL<br /> completion callback and treat any negative return from<br /> crypto_aead_{encrypt,decrypt}() as terminal, falling through to<br /> kfree_sensitive(buffer). When the encrypt_name resolves to an<br /> async AEAD instance the request returns -EINPROGRESS, the buffer<br /> is freed while the backend&amp;#39;s worker still holds a pointer, and the<br /> worker dereferences the freed slab on completion.<br /> <br /> KASAN report under UML+SLUB with a synthetic async aead backend<br /> bound to krb5-&gt;encrypt_name:<br /> <br /> BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7<br /> <br /> The helpers were written synchronously, so filter the async<br /> instances out at allocation time instead of plumbing<br /> crypto_wait_req() through every call site.<br /> <br /> Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and<br /> net/ceph/crypto.c on systems with an async AEAD provider bound to<br /> the krb5 enctype name.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB write in HT_caps_handler()<br /> <br /> HT_caps_handler() iterates pIE-&gt;length bytes and writes into<br /> HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct<br /> HT_caps_element). Because pIE-&gt;length is a raw u8 from an over-the-air<br /> 802.11 AssocResponse frame and is never validated, a malicious AP can<br /> set it up to 255, causing up to 229 bytes of out-of-bounds writes into<br /> adjacent fields of struct mlme_ext_info.<br /> <br /> Truncate the iteration count to the size of HT_caps.u.HT_cap using<br /> umin() so that data from a longer-than-expected IE is silently ignored<br /> rather than written out of bounds, preserving interoperability with APs<br /> that pad the element. An early return on oversized IEs was considered<br /> but rejected: it would bypass the pmlmeinfo-&gt;HT_caps_enable = 1<br /> assignment that precedes the loop, silently disabling HT mode for APs<br /> that append extra bytes to the HT Capabilities IE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()<br /> <br /> Three IE/attribute parsing functions have missing bounds checks.<br /> <br /> rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer<br /> without verifying that the header bytes (tag + length) are within the<br /> remaining buffer before reading them. Additionally, rtw_get_sec_ie()<br /> compares the 4-byte WPA OUI at cnt+2 without checking that at least<br /> 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at<br /> cnt+6 without checking that at least 10 bytes remain.<br /> <br /> rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at<br /> entry, before verifying that wps_ielen is large enough to contain<br /> the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside<br /> the attribute loop, get_unaligned_be16() is called on attr_ptr and<br /> attr_ptr+2 without checking that 4 bytes remain in the buffer.<br /> <br /> Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie()<br /> and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum<br /> IE length requirement, add a wps_ielen

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()<br /> <br /> Two IE parsing loops are missing the header bounds checks before they<br /> dereference pIE-&gt;length:<br /> <br /> - issue_assocreq() walks pmlmeinfo-&gt;network.ies to build the<br /> association request. If the stored IE data ends with only an<br /> element_id byte and no length byte, pIE-&gt;length is read one byte<br /> past the end of the buffer.<br /> <br /> - join_cmd_hdl() walks pnetwork-&gt;ies during station join and has<br /> the same problem under the same conditions.<br /> <br /> Both buffers are filled from AP beacon and probe-response frames, so a<br /> malicious AP that sends a truncated final IE can trigger the issue.<br /> <br /> Apply the two-guard pattern established in update_beacon_info():<br /> 1. Break if fewer than sizeof(*pIE) bytes remain.<br /> 2. Break if the IE&amp;#39;s declared data extends past the buffer end.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop<br /> <br /> The IE parsing loop in update_beacon_info() advances by<br /> (pIE-&gt;length + 2) each iteration but only guards on i length from 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 len, passing a truncated IE<br /> 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 len.<br /> <br /> Also replace i += (pIE-&gt;length + 2) with i += sizeof(*pIE) + pIE-&gt;length<br /> for consistency with the sizeof(*pIE) guards added above.