Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: validate cluster allocation bits of the allocation bitmap<br /> <br /> syzbot created an exfat image with cluster bits not set for the allocation<br /> bitmap. exfat-fs reads and uses the allocation bitmap without checking<br /> this. The problem is that if the start cluster of the allocation bitmap<br /> is 6, cluster 6 can be allocated when creating a directory with mkdir.<br /> exfat zeros out this cluster in exfat_mkdir, which can delete existing<br /> entries. This can reallocate the allocated entries. In addition,<br /> the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.<br /> This patch adds exfat_test_bitmap_range to validate that clusters used for<br /> the allocation bitmap are correctly marked as in-use.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix regbuf vector size truncation<br /> <br /> There is a report of io_estimate_bvec_size() truncating the calculated<br /> number of segments that leads to corruption issues. Check it doesn&amp;#39;t<br /> overflow "int"s used later. Rough but simple, can be improved on top.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix received length check in big packets<br /> <br /> Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length<br /> for big packets"), when guest gso is off, the allocated size for big<br /> packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on<br /> negotiated MTU. The number of allocated frags for big packets is stored<br /> in vi-&gt;big_packets_num_skbfrags.<br /> <br /> Because the host announced buffer length can be malicious (e.g. the host<br /> vhost_net driver&amp;#39;s get_rx_bufs is modified to announce incorrect<br /> length), we need a check in virtio_net receive path. Currently, the<br /> check is not adapted to the new change which can lead to NULL page<br /> pointer dereference in the below while loop when receiving length that<br /> is larger than the allocated one.<br /> <br /> This commit fixes the received length check corresponding to the new<br /> change.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Don&amp;#39;t overflow during division for dirty tracking<br /> <br /> If pgshift is 63 then BITS_PER_TYPE(*bitmap-&gt;bitmap) * pgsize will overflow<br /> to 0 and this triggers divide by 0.<br /> <br /> In this case the index should just be 0, so reorganize things to divide<br /> by shift and avoid hitting any overflows.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()<br /> <br /> In the parse_adv_monitor_pattern() function, the value of<br /> the &amp;#39;length&amp;#39; variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).<br /> The size of the &amp;#39;value&amp;#39; array in the mgmt_adv_pattern structure is 31.<br /> If the value of &amp;#39;pattern[i].length&amp;#39; is set in the user space<br /> and exceeds 31, the &amp;#39;patterns[i].value&amp;#39; array can be accessed<br /> out of bound when copied.<br /> <br /> Increasing the size of the &amp;#39;value&amp;#39; array in<br /> the &amp;#39;mgmt_adv_pattern&amp;#39; structure will break the userspace.<br /> Considering this, and to avoid OOB access revert the limits for &amp;#39;offset&amp;#39;<br /> and &amp;#39;length&amp;#39; back to the value of HCI_MAX_AD_LENGTH.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: fix left shift underflow when inode-&gt;i_blkbits &gt; PAGE_SHIFT<br /> <br /> When simulating an nvme device on qemu with both logical_block_size and<br /> physical_block_size set to 8 KiB, an error trace appears during<br /> partition table reading at boot time. The issue is caused by<br /> inode-&gt;i_blkbits being larger than PAGE_SHIFT, which leads to a left<br /> shift of -1 and triggering a UBSAN warning.<br /> <br /> [ 2.697306] ------------[ cut here ]------------<br /> [ 2.697309] UBSAN: shift-out-of-bounds in fs/crypto/inline_crypt.c:336:37<br /> [ 2.697311] shift exponent -1 is negative<br /> [ 2.697315] CPU: 3 UID: 0 PID: 274 Comm: (udev-worker) Not tainted 6.18.0-rc2+ #34 PREEMPT(voluntary)<br /> [ 2.697317] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 2.697320] Call Trace:<br /> [ 2.697324] <br /> [ 2.697325] dump_stack_lvl+0x76/0xa0<br /> [ 2.697340] dump_stack+0x10/0x20<br /> [ 2.697342] __ubsan_handle_shift_out_of_bounds+0x1e3/0x390<br /> [ 2.697351] bh_get_inode_and_lblk_num.cold+0x12/0x94<br /> [ 2.697359] fscrypt_set_bio_crypt_ctx_bh+0x44/0x90<br /> [ 2.697365] submit_bh_wbc+0xb6/0x190<br /> [ 2.697370] block_read_full_folio+0x194/0x270<br /> [ 2.697371] ? __pfx_blkdev_get_block+0x10/0x10<br /> [ 2.697375] ? __pfx_blkdev_read_folio+0x10/0x10<br /> [ 2.697377] blkdev_read_folio+0x18/0x30<br /> [ 2.697379] filemap_read_folio+0x40/0xe0<br /> [ 2.697382] filemap_get_pages+0x5ef/0x7a0<br /> [ 2.697385] ? mmap_region+0x63/0xd0<br /> [ 2.697389] filemap_read+0x11d/0x520<br /> [ 2.697392] blkdev_read_iter+0x7c/0x180<br /> [ 2.697393] vfs_read+0x261/0x390<br /> [ 2.697397] ksys_read+0x71/0xf0<br /> [ 2.697398] __x64_sys_read+0x19/0x30<br /> [ 2.697399] x64_sys_call+0x1e88/0x26a0<br /> [ 2.697405] do_syscall_64+0x80/0x670<br /> [ 2.697410] ? __x64_sys_newfstat+0x15/0x20<br /> [ 2.697414] ? x64_sys_call+0x204a/0x26a0<br /> [ 2.697415] ? do_syscall_64+0xb8/0x670<br /> [ 2.697417] ? irqentry_exit_to_user_mode+0x2e/0x2a0<br /> [ 2.697420] ? irqentry_exit+0x43/0x50<br /> [ 2.697421] ? exc_page_fault+0x90/0x1b0<br /> [ 2.697422] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 2.697425] RIP: 0033:0x75054cba4a06<br /> [ 2.697426] Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08<br /> [ 2.697427] RSP: 002b:00007fff973723a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000<br /> [ 2.697430] RAX: ffffffffffffffda RBX: 00005ea9a2c02760 RCX: 000075054cba4a06<br /> [ 2.697432] RDX: 0000000000002000 RSI: 000075054c190000 RDI: 000000000000001b<br /> [ 2.697433] RBP: 00007fff973723c0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 2.697434] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000<br /> [ 2.697434] R13: 00005ea9a2c027c0 R14: 00005ea9a2be5608 R15: 00005ea9a2be55f0<br /> [ 2.697436] <br /> [ 2.697436] ---[ end trace ]---<br /> <br /> This situation can happen for block devices because when<br /> CONFIG_TRANSPARENT_HUGEPAGE is enabled, the maximum logical_block_size<br /> is 64 KiB. set_init_blocksize() then sets the block device<br /> inode-&gt;i_blkbits to 13, which is within this limit.<br /> <br /> File I/O does not trigger this problem because for filesystems that do<br /> not support the FS_LBS feature, sb_set_blocksize() prevents<br /> sb-&gt;s_blocksize_bits from being larger than PAGE_SHIFT. During inode<br /> allocation, alloc_inode()-&gt;inode_init_always() assigns inode-&gt;i_blkbits<br /> from sb-&gt;s_blocksize_bits. Currently, only xfs_fs_type has the FS_LBS<br /> flag, and since xfs I/O paths do not reach submit_bh_wbc(), it does not<br /> hit the left-shift underflow issue.<br /> <br /> [EB: use folio_pos() and consolidate the two shifts by i_blkbits]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: int3472: Fix double free of GPIO device during unregister<br /> <br /> regulator_unregister() already frees the associated GPIO device. On<br /> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to<br /> random failures when other drivers (typically Intel THC) attempt to<br /> allocate interrupts. The root cause is that the reference count of the<br /> pinctrl_intel_platform module unexpectedly drops to zero when this<br /> driver defers its probe.<br /> <br /> This behavior can also be reproduced by unloading the module directly.<br /> <br /> Fix the issue by removing the redundant release of the GPIO device<br /> during regulator unregistration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix use-after-free due to MST port state bypass<br /> <br /> syzbot reported[1] a use-after-free when deleting an expired fdb. It is<br /> due to a race condition between learning still happening and a port being<br /> deleted, after all its fdbs have been flushed. The port&amp;#39;s state has been<br /> toggled to disabled so no learning should happen at that time, but if we<br /> have MST enabled, it will bypass the port&amp;#39;s state, that together with VLAN<br /> filtering disabled can lead to fdb learning at a time when it shouldn&amp;#39;t<br /> happen while the port is being deleted. VLAN filtering must be disabled<br /> because we flush the port VLANs when it&amp;#39;s being deleted which will stop<br /> learning. This fix adds a check for the port&amp;#39;s vlan group which is<br /> initialized to NULL when the port is getting deleted, that avoids the port<br /> state bypass. When MST is enabled there would be a minimal new overhead<br /> in the fast-path because the port&amp;#39;s vlan group pointer is cache-hot.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Implement settime64 with -EOPNOTSUPP<br /> <br /> ptp_clock_settime() assumes every ptp_clock has implemented settime64().<br /> Stub it with -EOPNOTSUPP to prevent a NULL dereference.

*** Pendiente de traducción *** A vulnerability was determined in SourceCodester Online Student Clearance System 1.0. The affected element is an unknown function of the file /Admin/delete-fee.php of the component Fee Table Handler. Executing manipulation of the argument ID can lead to improper authorization. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized.

*** Pendiente de traducción *** A vulnerability was identified in tushar-2223 Hotel-Management-System up to bb1f3b3666124b888f1e4bcf51b6fba9fbb01d15. The impacted element is an unknown function of the file /admin/invoiceprint.php. The manipulation of the argument ID leads to sql injection. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available.

*** Pendiente de traducción *** A security flaw has been discovered in D-Link DIR-823X up to 20250416. This affects the function sub_415028 of the file /goform/set_wan_settings. The manipulation of the argument ppp_username results in command injection. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited.