Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Explicitly check accesses to bpf_sock_addr<br /> <br /> Syzkaller found a kernel warning on the following sock_addr program:<br /> <br /> 0: r0 = 0<br /> 1: r2 = *(u32 *)(r1 +60)<br /> 2: exit<br /> <br /> which triggers:<br /> <br /> verifier bug: error during ctx access conversion (0)<br /> <br /> This is happening because offset 60 in bpf_sock_addr corresponds to an<br /> implicit padding of 4 bytes, right after msg_src_ip4. Access to this<br /> padding isn&amp;#39;t rejected in sock_addr_is_valid_access and it thus later<br /> fails to convert the access.<br /> <br /> This patch fixes it by explicitly checking the various fields of<br /> bpf_sock_addr in sock_addr_is_valid_access.<br /> <br /> I checked the other ctx structures and is_valid_access functions and<br /> didn&amp;#39;t find any other similar cases. Other cases of (properly handled)<br /> padding are covered in new tests in a subsequent patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv, bpf: Sign extend struct ops return values properly<br /> <br /> The ns_bpf_qdisc selftest triggers a kernel panic:<br /> <br /> Unable to handle kernel paging request at virtual address ffffffffa38dbf58<br /> Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000<br /> [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000<br /> Oops [#1]<br /> Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)]<br /> CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE<br /> Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024<br /> epc : __qdisc_run+0x82/0x6f0<br /> ra : __qdisc_run+0x6e/0x6f0<br /> epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550<br /> gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180<br /> t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0<br /> s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001<br /> a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000<br /> a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049<br /> s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000<br /> s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0<br /> s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000<br /> s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000<br /> t5 : 0000000000000000 t6 : ff60000093a6a8b6<br /> status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d<br /> [] __qdisc_run+0x82/0x6f0<br /> [] __dev_queue_xmit+0x4c0/0x1128<br /> [] neigh_resolve_output+0xd0/0x170<br /> [] ip6_finish_output2+0x226/0x6c8<br /> [] ip6_finish_output+0x10c/0x2a0<br /> [] ip6_output+0x5e/0x178<br /> [] ip6_xmit+0x29a/0x608<br /> [] inet6_csk_xmit+0xe6/0x140<br /> [] __tcp_transmit_skb+0x45c/0xaa8<br /> [] tcp_connect+0x9ce/0xd10<br /> [] tcp_v6_connect+0x4ac/0x5e8<br /> [] __inet_stream_connect+0xd8/0x318<br /> [] inet_stream_connect+0x3e/0x68<br /> [] __sys_connect_file+0x50/0x88<br /> [] __sys_connect+0x96/0xc8<br /> [] __riscv_sys_connect+0x20/0x30<br /> [] do_trap_ecall_u+0x256/0x378<br /> [] handle_exception+0x14a/0x156<br /> Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer<br /> is treated as a 32bit value and sign extend to 64bit in epilogue. This<br /> behavior is right for most bpf prog types but wrong for struct ops which<br /> requires RISC-V ABI.<br /> <br /> So let&amp;#39;s sign extend struct ops return values according to the function<br /> model and RISC-V ABI([0]).<br /> <br /> [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: restrict sockets to TCP and UDP<br /> <br /> Recently, syzbot started to abuse NBD with all kinds of sockets.<br /> <br /> Commit cf1b2326b734 ("nbd: verify socket is supported during setup")<br /> made sure the socket supported a shutdown() method.<br /> <br /> Explicitely accept TCP and UNIX stream sockets.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm_spe: Prevent overflow in PERF_IDX2OFF()<br /> <br /> Cast nr_pages to unsigned long to avoid overflow when handling large<br /> AUX buffer sizes (&gt;= 2 GiB).

*** Pendiente de traducción *** An unauthenticated user can connect to a publicly accessible database using arbitrary credentials. The system grants full access to the database by leveraging a previously authenticated connection through a "mmBackup" application. This flaw allows attackers to bypass authentication mechanisms and gain unauthorized access to database with sensitive data.<br /> <br /> This issue affects Asseco mMedica in versions before 11.9.5.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links()<br /> <br /> In order to avoid a possible NULL pointer dereference in<br /> mt7996_mac_sta_init_link routine, move the phy pointer check before<br /> running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist<br /> <br /> Index allocation requires at least one bit in the $BITMAP attribute to<br /> track usage of index entries. If the bitmap is empty while index blocks<br /> are already present, this reflects on-disk corruption.<br /> <br /> syzbot triggered this condition using a malformed NTFS image. During a<br /> rename() operation involving a long filename (which spans multiple<br /> index entries), the empty bitmap allowed the name to be added without<br /> valid tracking. Subsequent deletion of the original entry failed with<br /> -ENOENT, due to unexpected index state.<br /> <br /> Reject such cases by verifying that the bitmap is not empty when index<br /> blocks exist.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ntfs3: Fix integer overflow in run_unpack()<br /> <br /> The MFT record relative to the file being opened contains its runlist,<br /> an array containing information about the file&amp;#39;s location on the physical<br /> disk. Analysis of all Call Stack paths showed that the values of the<br /> runlist array, from which LCNs are calculated, are not validated before<br /> run_unpack function.<br /> <br /> The run_unpack function decodes the compressed runlist data format<br /> from MFT attributes (for example, $DATA), converting them into a runs_tree<br /> structure, which describes the mapping of virtual clusters (VCN) to<br /> logical clusters (LCN). The NTFS3 subsystem also has a shortcut for<br /> deleting files from MFT records - in this case, the RUN_DEALLOCATE<br /> command is sent to the run_unpack input, and the function logic<br /> provides that all data transferred to the runlist about file or<br /> directory is deleted without creating a runs_tree structure.<br /> <br /> Substituting the runlist in the $DATA attribute of the MFT record for an<br /> arbitrary file can lead either to access to arbitrary data on the disk<br /> bypassing access checks to them (since the inode access check<br /> occurs above) or to destruction of arbitrary data on the disk.<br /> <br /> Add overflow check for addition operation.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix obj leak in VM_BIND error path<br /> <br /> If we fail a handle-lookup part way thru, we need to drop the already<br /> obtained obj references.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/669784/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pps: fix warning in pps_register_cdev when register device fail<br /> <br /> Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error<br /> handling in __video_register_device()"), the release hook should be set<br /> before device_register(). Otherwise, when device_register() return error<br /> and put_device() try to callback the release function, the below warning<br /> may happen.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE<br /> RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567<br /> Call Trace:<br /> <br /> kobject_cleanup+0x136/0x410 lib/kobject.c:689<br /> kobject_release lib/kobject.c:720 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0xe9/0x130 lib/kobject.c:737<br /> put_device+0x24/0x30 drivers/base/core.c:3797<br /> pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402<br /> pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108<br /> pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57<br /> tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432<br /> tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563<br /> tiocsetd drivers/tty/tty_io.c:2429 [inline]<br /> tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:598 [inline]<br /> __se_sys_ioctl fs/ioctl.c:584 [inline]<br /> __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),<br /> pps_register_cdev() call device_create() to create pps-&gt;dev, which will<br /> init dev-&gt;release to device_create_release(). Now the comment is outdated,<br /> just remove it.<br /> <br /> Thanks for the reminder from Calvin Owens, &amp;#39;kfree_pps&amp;#39; should be removed<br /> in pps_register_source() to avoid a double free in the failure case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: Don&amp;#39;t block input queue by waiting MSC<br /> <br /> Currently gsm_queue() processes incoming frames and when opening<br /> a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().<br /> If basic mode is used it calls gsm_modem_upd_via_msc() and it<br /> cannot block the input queue by waiting the response to come<br /> into the same input queue.<br /> <br /> Instead allow sending Modem Status Command without waiting for remote<br /> end to respond. Define a new function gsm_modem_send_initial_msc()<br /> for this purpose. As MSC is only valid for basic encoding, it does<br /> not do anything for advanced or when convergence layer type 2 is used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing<br /> <br /> The function do_fanotify_mark() does not validate if<br /> mnt_ns_from_dentry() returns NULL before dereferencing mntns-&gt;user_ns.<br /> This causes a NULL pointer dereference in do_fanotify_mark() if the<br /> path is not a mount namespace object.<br /> <br /> Fix this by checking mnt_ns_from_dentry()&amp;#39;s return value before<br /> dereferencing it.<br /> <br /> Before the patch<br /> <br /> $ gcc fanotify_nullptr.c -o fanotify_nullptr<br /> $ mkdir A<br /> $ ./fanotify_nullptr<br /> Fanotify fd: 3<br /> fanotify_mark: Operation not permitted<br /> $ unshare -Urm<br /> Fanotify fd: 3<br /> Killed<br /> <br /> int main(void){<br /> int ffd;<br /> ffd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_MNT, 0);<br /> if(ffd