Vulnerabilidades

*** Pendiente de traducción *** HCL DevOps Deploy / HCL Launch is susceptible to a race condition in http-session client-IP binding enforcement which may allow a session to be briefly reused from a new IP address before it is invalidated. This could lead to unauthorized access under certain network conditions.

*** Pendiente de traducción *** InvoicePlane commit debb446c is vulnerable to Incorrect Access Control. The invoices/view handler fails to verify ownership before returning invoice data.

*** Pendiente de traducción *** When using the attachment interaction functionality, Canary Mail 5.1.40 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.

*** Pendiente de traducción *** When using the attachment interaction functionality, Blue Mail 1.140.103 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.

*** Pendiente de traducción *** An issue was discovered in Dbit N300 T1 Pro Easy Setup Wireless Wi-Fi Router on firmware version V1.0.0 does not implement rate limiting to /api/login allowing attackers to brute force password enumerations.

*** Pendiente de traducción *** Exposure of Private Personal Information to an Unauthorized Actor vulnerability in RTI Connext Professional (Core Libraries) allows Sniffing Network Traffic.This issue affects Connext Professional: from 7.4.0 before 7.*, from 7.2.0 before 7.3.1.

*** Pendiente de traducción *** In limited scenarios, sensitive data might be written to the log file if an admin uses Microsoft Teams Admin Center (TAC) to make device configuration changes. The affected log file is visible only to users with admin credentials. This is limited to Microsoft TAC and does not affect configuration changes made using the provisioning server or the device WebUI.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix admin request_queue lifetime<br /> <br /> The namespaces can access the controller&amp;#39;s admin request_queue, and<br /> stale references on the namespaces may exist after tearing down the<br /> controller. Ensure the admin request_queue is active by moving the<br /> controller&amp;#39;s &amp;#39;put&amp;#39; to after all controller references have been released<br /> to ensure no one is can access the request_queue. This fixes a reported<br /> use-after-free bug:<br /> <br /> BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0<br /> Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287<br /> CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4f/0x60<br /> print_report+0xc4/0x620<br /> ? _raw_spin_lock_irqsave+0x70/0xb0<br /> ? _raw_read_unlock_irqrestore+0x30/0x30<br /> ? blk_queue_enter+0x41c/0x4a0<br /> kasan_report+0xab/0xe0<br /> ? blk_queue_enter+0x41c/0x4a0<br /> blk_queue_enter+0x41c/0x4a0<br /> ? __irq_work_queue_local+0x75/0x1d0<br /> ? blk_queue_start_drain+0x70/0x70<br /> ? irq_work_queue+0x18/0x20<br /> ? vprintk_emit.part.0+0x1cc/0x350<br /> ? wake_up_klogd_work_func+0x60/0x60<br /> blk_mq_alloc_request+0x2b7/0x6b0<br /> ? __blk_mq_alloc_requests+0x1060/0x1060<br /> ? __switch_to+0x5b7/0x1060<br /> nvme_submit_user_cmd+0xa9/0x330<br /> nvme_user_cmd.isra.0+0x240/0x3f0<br /> ? force_sigsegv+0xe0/0xe0<br /> ? nvme_user_cmd64+0x400/0x400<br /> ? vfs_fileattr_set+0x9b0/0x9b0<br /> ? cgroup_update_frozen_flag+0x24/0x1c0<br /> ? cgroup_leave_frozen+0x204/0x330<br /> ? nvme_ioctl+0x7c/0x2c0<br /> blkdev_ioctl+0x1a8/0x4d0<br /> ? blkdev_common_ioctl+0x1930/0x1930<br /> ? fdget+0x54/0x380<br /> __x64_sys_ioctl+0x129/0x190<br /> do_syscall_64+0x5b/0x160<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f765f703b0b<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b<br /> RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000<br /> R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003<br /> R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfs: Reconstruct file type when loading from disk<br /> <br /> syzbot is reporting that S_IFMT bits of inode-&gt;i_mode can become bogus when<br /> the S_IFMT bits of the 32bits "mode" field loaded from disk are corrupted<br /> or when the 32bits "attributes" field loaded from disk are corrupted.<br /> <br /> A documentation says that BFS uses only lower 9 bits of the "mode" field.<br /> But I can&amp;#39;t find an explicit explanation that the unused upper 23 bits<br /> (especially, the S_IFMT bits) are initialized with 0.<br /> <br /> Therefore, ignore the S_IFMT bits of the "mode" field loaded from disk.<br /> Also, verify that the value of the "attributes" field loaded from disk is<br /> either BFS_VREG or BFS_VDIR (because BFS supports only regular files and<br /> the root directory).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list<br /> <br /> "struct sdca_control" declares "values" field as integer array.<br /> But the memory allocated to it is of char array. This causes<br /> crash for sdca_parse_function API. This patch addresses the<br /> issue by allocating correct data size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: check device&amp;#39;s attached status in compat ioctls<br /> <br /> Syzbot identified an issue [1] that crashes kernel, seemingly due to<br /> unexistent callback dev-&gt;get_valid_routes(). By all means, this should<br /> not occur as said callback must always be set to<br /> get_zero_valid_routes() in __comedi_device_postconfig().<br /> <br /> As the crash seems to appear exclusively in i386 kernels, at least,<br /> judging from [1] reports, the blame lies with compat versions<br /> of standard IOCTL handlers. Several of them are modified and<br /> do not use comedi_unlocked_ioctl(). While functionality of these<br /> ioctls essentially copy their original versions, they do not<br /> have required sanity check for device&amp;#39;s attached status. This,<br /> in turn, leads to a possibility of calling select IOCTLs on a<br /> device that has not been properly setup, even via COMEDI_DEVCONFIG.<br /> <br /> Doing so on unconfigured devices means that several crucial steps<br /> are missed, for instance, specifying dev-&gt;get_valid_routes()<br /> callback.<br /> <br /> Fix this somewhat crudely by ensuring device&amp;#39;s attached status before<br /> performing any ioctls, improving logic consistency between modern<br /> and compat functions.<br /> <br /> [1] Syzbot report:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]<br /> parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401<br /> do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594<br /> compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]<br /> comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273<br /> __do_compat_sys_ioctl fs/ioctl.c:695 [inline]<br /> __se_compat_sys_ioctl fs/ioctl.c:638 [inline]<br /> __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: multiq3: sanitize config options in multiq3_attach()<br /> <br /> Syzbot identified an issue [1] in multiq3_attach() that induces a<br /> task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,<br /> specifically, in the case of multiq3 driver.<br /> <br /> This problem arose when syzkaller managed to craft weird configuration<br /> options used to specify the number of channels in encoder subdevice.<br /> If a particularly great number is passed to s-&gt;n_chan in<br /> multiq3_attach() via it-&gt;options[2], then multiple calls to<br /> multiq3_encoder_reset() at the end of driver-specific attach() method<br /> will be running for minutes, thus blocking tasks and affected devices<br /> as well.<br /> <br /> While this issue is most likely not too dangerous for real-life<br /> devices, it still makes sense to sanitize configuration inputs. Enable<br /> a sensible limit on the number of encoder chips (4 chips max, each<br /> with 2 channels) to stop this behaviour from manifesting.<br /> <br /> [1] Syzbot crash:<br /> INFO: task syz.2.19:6067 blocked for more than 143 seconds.<br /> ...<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5254 [inline]<br /> __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862<br /> __schedule_loop kernel/sched/core.c:6944 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:6959<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016<br /> __mutex_lock_common kernel/locking/mutex.c:676 [inline]<br /> __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760<br /> comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868<br /> chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414<br /> do_dentry_open+0x953/0x13f0 fs/open.c:965<br /> vfs_open+0x3b/0x340 fs/open.c:1097<br /> ...