Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent<br /> <br /> ctnetlink_alloc_expect() allocates expectations from a non-zeroing<br /> slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not<br /> present in the netlink message, saved_addr and saved_proto are<br /> never initialized. Stale data from a previous slab occupant can<br /> then be dumped to userspace by ctnetlink_exp_dump_expect(), which<br /> checks these fields to decide whether to emit CTA_EXPECT_NAT.<br /> <br /> The safe sibling nf_ct_expect_init(), used by the packet path,<br /> explicitly zeroes these fields.<br /> <br /> Zero saved_addr, saved_proto and dir in the else branch, guarded<br /> by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when<br /> NAT is enabled.<br /> <br /> Confirmed by priming the expect slab with NAT-bearing expectations,<br /> freeing them, creating a new expectation without CTA_EXPECT_NAT,<br /> and observing that the ctnetlink dump emits a spurious<br /> CTA_EXPECT_NAT containing stale data from the prior allocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_helper: pass helper to expect cleanup<br /> <br /> nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()<br /> to remove expectations belonging to the helper being unregistered.<br /> However, it passes NULL instead of the helper pointer as the data<br /> argument, so expect_iter_me() never matches any expectation and all<br /> of them survive the cleanup.<br /> <br /> After unregister returns, nfnl_cthelper_del() frees the helper<br /> object immediately. Subsequent expectation dumps or packet-driven<br /> init_conntrack() calls then dereference the freed exp-&gt;helper,<br /> causing a use-after-free.<br /> <br /> Pass the actual helper pointer so expectations referencing it are<br /> properly destroyed before the helper object is freed.<br /> <br /> BUG: KASAN: slab-use-after-free in string+0x38f/0x430<br /> Read of size 1 at addr ffff888003b14d20 by task poc/103<br /> Call Trace:<br /> string+0x38f/0x430<br /> vsnprintf+0x3cc/0x1170<br /> seq_printf+0x17a/0x240<br /> exp_seq_show+0x2e5/0x560<br /> seq_read_iter+0x419/0x1280<br /> proc_reg_read+0x1ac/0x270<br /> vfs_read+0x179/0x930<br /> ksys_read+0xef/0x1c0<br /> Freed by task 103:<br /> The buggy address is located 32 bytes inside of<br /> freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: ensure names are nul-terminated<br /> <br /> Reject names that lack a \0 character before feeding them<br /> to functions that expect c-strings.<br /> <br /> Fixes tag is the most recent commit that needs this change.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix soft lockup in mptcp_recvmsg()<br /> <br /> syzbot reported a soft lockup in mptcp_recvmsg() [0].<br /> <br /> When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not<br /> removed from the sk_receive_queue. This causes sk_wait_data() to always<br /> find available data and never perform actual waiting, leading to a soft<br /> lockup.<br /> <br /> Fix this by adding a &amp;#39;last&amp;#39; parameter to track the last peeked skb.<br /> This allows sk_wait_data() to make informed waiting decisions and prevent<br /> infinite loops when MSG_PEEK is used.<br /> <br /> [0]:<br /> watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963]<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:sk_wait_data+0x15/0x190<br /> Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b<br /> RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800<br /> RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101<br /> R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18<br /> R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000<br /> FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329<br /> inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891<br /> sock_recvmsg+0x94/0xc0 net/socket.c:1100<br /> __sys_recvfrom+0xb2/0x130 net/socket.c:2256<br /> __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267<br /> do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131<br /> RIP: 0033:0x7f6e386a4a1d<br /> Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41<br /> RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d<br /> RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d<br /> RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004<br /> RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0<br /> R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix regsafe() for pointers to packet<br /> <br /> In case rold-&gt;reg-&gt;range == BEYOND_PKT_END &amp;&amp; rcur-&gt;reg-&gt;range == N<br /> regsafe() may return true which may lead to current state with<br /> valid packet range not being explored. Fix the bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets<br /> <br /> When a TX packet spans multiple buffer descriptors (scatter-gather),<br /> axienet_free_tx_chain sums the per-BD actual length from descriptor<br /> status into a caller-provided accumulator. That sum is reset on each<br /> NAPI poll. If the BDs for a single packet complete across different<br /> polls, the earlier bytes are lost and never credited to BQL. This<br /> causes BQL to think bytes are permanently in-flight, eventually<br /> stalling the TX queue.<br /> <br /> The SKB pointer is stored only on the last BD of a packet. When that<br /> BD completes, use skb-&gt;len for the byte count instead of summing<br /> per-BD status lengths. This matches netdev_sent_queue(), which debits<br /> skb-&gt;len, and naturally survives across polls because no partial<br /> packet contributes to the accumulator.

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