Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Do not validate SSPP when it is not ready<br /> <br /> Current code will validate current plane and previous plane to<br /> confirm they can share a SSPP with multi-rect mode. The SSPP<br /> is already allocated for previous plane, while current plane<br /> is not associated with any SSPP yet. Null pointer is referenced<br /> when validating the SSPP of current plane. Skip SSPP validation<br /> for current plane.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000888ac3000<br /> [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S 6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: SM8650 EV1 rev1 4slam 2et (DT)<br /> pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : dpu_plane_is_multirect_capable+0x68/0x90<br /> lr : dpu_assign_plane_resources+0x288/0x410<br /> sp : ffff800093dcb770<br /> x29: ffff800093dcb770 x28: 0000000000002000 x27: ffff000817c6c000<br /> x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800<br /> x23: ffff000810842680 x22: ffff0008013f1080 x21: ffff00080cc86080<br /> x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff<br /> x17: 707a5f657a696c61 x16: 0000000000000003 x15: 0000000000002200<br /> x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: 0000000000000000<br /> x11: ffff000817c6e2b8 x10: 0000000000000000 x9 : ffff80008106a950<br /> x8 : ffff00080cbf48f4 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000438 x3 : 0000000000000438<br /> x2 : ffff800082e245e0 x1 : 0000000000000008 x0 : 0000000000000000<br /> Call trace:<br /> dpu_plane_is_multirect_capable+0x68/0x90 (P)<br /> dpu_crtc_atomic_check+0x5bc/0x650<br /> drm_atomic_helper_check_planes+0x13c/0x220<br /> drm_atomic_helper_check+0x58/0xb8<br /> msm_atomic_check+0xd8/0xf0<br /> drm_atomic_check_only+0x4a8/0x968<br /> drm_atomic_commit+0x50/0xd8<br /> drm_atomic_helper_update_plane+0x140/0x188<br /> __setplane_atomic+0xfc/0x148<br /> drm_mode_setplane+0x164/0x378<br /> drm_ioctl_kernel+0xc0/0x140<br /> drm_ioctl+0x20c/0x500<br /> __arm64_sys_ioctl+0xbc/0xf8<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x48/0xf8<br /> do_el0_svc+0x28/0x40<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0x144/0x168<br /> el0t_64_sync+0x198/0x1a0<br /> Code: b9402021 370fffc1 f9401441 3707ff81 (f94010a1)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/669224/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: start using dst_dev_rcu()<br /> <br /> Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.<br /> <br /> Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),<br /> ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Add a upper bound on max_vclocks<br /> <br /> syzbot reported WARNING in max_vclocks_store.<br /> <br /> This occurs when the argument max is too large for kcalloc to handle.<br /> <br /> Extend the guard to guard against values that are too large for<br /> kcalloc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Disallow dirty tracking if incoherent page walk<br /> <br /> Dirty page tracking relies on the IOMMU atomically updating the dirty bit<br /> in the paging-structure entry. For this operation to succeed, the paging-<br /> structure memory must be coherent between the IOMMU and the CPU. In<br /> another word, if the iommu page walk is incoherent, dirty page tracking<br /> doesn&amp;#39;t work.<br /> <br /> The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:<br /> <br /> "Remapping hardware encountering the need to atomically update A/EA/D bits<br /> in a paging-structure entry that is not snooped will result in a non-<br /> recoverable fault."<br /> <br /> To prevent an IOMMU from being incorrectly configured for dirty page<br /> tracking when it is operating in an incoherent mode, mark SSADS as<br /> supported only when both ecap_slads and ecap_smpwc are supported.