Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: pn533: bound the UART receive buffer<br /> <br /> pn532_receive_buf() appends every incoming byte to dev-&gt;recv_skb and<br /> only resets the buffer after pn532_uart_rx_is_frame() recognizes a<br /> complete frame. A continuous stream of bytes without a valid PN532 frame<br /> header therefore keeps growing the skb until skb_put_u8() hits the tail<br /> limit.<br /> <br /> Drop the accumulated partial frame once the fixed receive buffer is full<br /> so malformed UART traffic cannot grow the skb past<br /> PN532_UART_SKB_BUFF_LEN.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption<br /> <br /> When decrypting data that is not in-place (src != dst), there is<br /> no need to save the high-order sequence bits in dst as it could<br /> simply be re-copied from the source.<br /> <br /> However, the data to be hashed need to be rearranged accordingly.<br /> <br /> <br /> Thanks,

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync<br /> <br /> hci_conn lookup and field access must be covered by hdev lock in<br /> set_cig_params_sync, otherwise it&amp;#39;s possible it is freed concurrently.<br /> <br /> Take hdev lock to prevent hci_conn from being deleted or modified<br /> concurrently. Just RCU lock is not suitable here, as we also want to<br /> avoid "tearing" in the configuration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: validate LTK enc_size on load<br /> <br /> Load Long Term Keys stores the user-provided enc_size and later uses<br /> it to size fixed-size stack operations when replying to LE LTK<br /> requests. An enc_size larger than the 16-byte key buffer can therefore<br /> overflow the reply stack buffer.<br /> <br /> Reject oversized enc_size values while validating the management LTK<br /> record so invalid keys never reach the stored key state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix leaks when hci_cmd_sync_queue_once fails<br /> <br /> When hci_cmd_sync_queue_once() returns with error, the destroy callback<br /> will not be called.<br /> <br /> Fix leaking references / memory on these failures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists<br /> <br /> hci_cmd_sync_queue_once() needs to indicate whether a queue item was<br /> added, so caller can know if callbacks are called, so it can avoid<br /> leaking resources.<br /> <br /> Change the function to return -EEXIST if queue item already exists.<br /> <br /> Modify all callsites to handle that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: fix race conditions in sco_sock_connect()<br /> <br /> sco_sock_connect() checks sk_state and sk_type without holding<br /> the socket lock. Two concurrent connect() syscalls on the same<br /> socket can both pass the check and enter sco_connect(), leading<br /> to use-after-free.<br /> <br /> The buggy scenario involves three participants and was confirmed<br /> with additional logging instrumentation:<br /> <br /> Thread A (connect): HCI disconnect: Thread B (connect):<br /> <br /> sco_sock_connect(sk) sco_sock_connect(sk)<br /> sk_state==BT_OPEN sk_state==BT_OPEN<br /> (pass, no lock) (pass, no lock)<br /> sco_connect(sk): sco_connect(sk):<br /> hci_dev_lock hci_dev_lock<br /> hci_connect_sco hcon1<br /> sco_conn_add-&gt;conn1<br /> lock_sock(sk)<br /> sco_chan_add:<br /> conn1-&gt;sk = sk<br /> sk-&gt;conn = conn1<br /> sk_state=BT_CONNECT<br /> release_sock<br /> hci_dev_unlock<br /> hci_dev_lock<br /> sco_conn_del:<br /> lock_sock(sk)<br /> sco_chan_del:<br /> sk-&gt;conn=NULL<br /> conn1-&gt;sk=NULL<br /> sk_state=<br /> BT_CLOSED<br /> SOCK_ZAPPED<br /> release_sock<br /> hci_dev_unlock<br /> (unblocked)<br /> hci_connect_sco<br /> -&gt; hcon2<br /> sco_conn_add<br /> -&gt; conn2<br /> lock_sock(sk)<br /> sco_chan_add:<br /> sk-&gt;conn=conn2<br /> sk_state=<br /> BT_CONNECT<br /> // zombie sk!<br /> release_sock<br /> hci_dev_unlock<br /> <br /> Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to<br /> BT_CONNECT. Subsequent cleanup triggers double sock_put() and<br /> use-after-free. Meanwhile conn1 is leaked as it was orphaned<br /> when sco_conn_del() cleared the association.<br /> <br /> Fix this by:<br /> - Moving lock_sock() before the sk_state/sk_type checks in<br /> sco_sock_connect() to serialize concurrent connect attempts<br /> - Fixing the sk_type != SOCK_SEQPACKET check to actually<br /> return the error instead of just assigning it<br /> - Adding a state re-check in sco_connect() after lock_sock()<br /> to catch state changes during the window between the locks<br /> - Adding sco_pi(sk)-&gt;conn check in sco_chan_add() to prevent<br /> double-attach of a socket to multiple connections<br /> - Adding hci_conn_drop() on sco_chan_add failure to prevent<br /> HCI connection leaks

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: reject immediate NF_QUEUE verdict<br /> <br /> nft_queue is always used from userspace nftables to deliver the NF_QUEUE<br /> verdict. Immediately emitting an NF_QUEUE verdict is never used by the<br /> userspace nft tools, so reject immediate NF_QUEUE verdicts.<br /> <br /> The arp family does not provide queue support, but such an immediate<br /> verdict is still reachable. Globally reject NF_QUEUE immediate verdicts<br /> to address this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: ignore explicit helper on new expectations<br /> <br /> Use the existing master conntrack helper, anything else is not really<br /> supported and it just makes validation more complicated, so just ignore<br /> what helper userspace suggests for this expectation.<br /> <br /> This was uncovered when validating CTA_EXPECT_CLASS via different helper<br /> provided by userspace than the existing master conntrack helper:<br /> <br /> BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0<br /> Read of size 4 at addr ffff8880043fe408 by task poc/102<br /> Call Trace:<br /> nf_ct_expect_related_report+0x2479/0x27c0<br /> ctnetlink_create_expect+0x22b/0x3b0<br /> ctnetlink_new_expect+0x4bd/0x5c0<br /> nfnetlink_rcv_msg+0x67a/0x950<br /> netlink_rcv_skb+0x120/0x350<br /> <br /> Allowing to read kernel memory bytes off the expectation boundary.<br /> <br /> CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace<br /> via netlink dump.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix switchdev mode rollback in case of failure<br /> <br /> If for some internal reason switchdev mode fails, we rollback to legacy<br /> mode, before this patch, rollback will unregister the uplink netdev and<br /> leave it unregistered causing the below kernel bug.<br /> <br /> To fix this, we need to avoid netdev unregister by setting the proper<br /> rollback flag &amp;#39;MLX5_PRIV_FLAGS_SWITCH_LEGACY&amp;#39; to indicate legacy mode.<br /> <br /> devlink (431) used greatest stack depth: 11048 bytes left<br /> mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \<br /> necvfs(0), active vports(0)<br /> mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload<br /> mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535<br /> mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \<br /> QUERY_HCA_CAP(0x100) op_mod(0x0) failed, \<br /> status bad parameter(0x3), syndrome (0x3a3846), err(-22)<br /> mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \<br /> representor for vport 65535<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/dev.c:12070!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \<br /> #9 PREEMPT(voluntary)<br /> RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0<br /> ...<br /> Call Trace:<br /> [ 90.923094] unregister_netdevice_queue+0xad/0xf0<br /> [ 90.923323] unregister_netdev+0x1c/0x40<br /> [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6<br /> [ 90.923736] esw_offloads_enable+0x8e6/0x920<br /> [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430<br /> [ 90.924182] ? is_mp_supported+0x57/0xb0<br /> [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350<br /> [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0<br /> [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140<br /> [ 90.925088] genl_rcv_msg+0x18b/0x290<br /> [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10<br /> [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10<br /> [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10<br /> [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [ 90.926206] netlink_rcv_skb+0x52/0x100<br /> [ 90.926393] genl_rcv+0x28/0x40<br /> [ 90.926557] netlink_unicast+0x27d/0x3d0<br /> [ 90.926749] netlink_sendmsg+0x1f7/0x430<br /> [ 90.926942] __sys_sendto+0x213/0x220<br /> [ 90.927127] ? __sys_recvmsg+0x6a/0xd0<br /> [ 90.927312] __x64_sys_sendto+0x24/0x30<br /> [ 90.927504] do_syscall_64+0x50/0x1c0<br /> [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 90.927929] RIP: 0033:0x7f7d0363e047

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: lag: Check for LAG device before creating debugfs<br /> <br /> __mlx5_lag_dev_add_mdev() may return 0 (success) even when an error<br /> occurs that is handled gracefully. Consequently, the initialization<br /> flow proceeds to call mlx5_ldev_add_debugfs() even when there is no<br /> valid LAG context.<br /> <br /> mlx5_ldev_add_debugfs() blindly created the debugfs directory and<br /> attributes. This exposed interfaces (like the members file) that rely on<br /> a valid ldev pointer, leading to potential NULL pointer dereferences if<br /> accessed when ldev is NULL.<br /> <br /> Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer<br /> before attempting to create the debugfs entries.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: properly unregister fixed rate clocks<br /> <br /> The additional resources allocated with clk_register_fixed_rate() need<br /> to be released with clk_unregister_fixed_rate(), otherwise they are lost.