Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix uninit-value by validating catalog record size<br /> <br /> Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The<br /> root cause is that hfs_brec_read() doesn&amp;#39;t validate that the on-disk<br /> record size matches the expected size for the record type being read.<br /> <br /> When mounting a corrupted filesystem, hfs_brec_read() may read less data<br /> than expected. For example, when reading a catalog thread record, the<br /> debug output showed:<br /> <br /> HFSPLUS_BREC_READ: rec_len=520, fd-&gt;entrylength=26<br /> HFSPLUS_BREC_READ: WARNING - entrylength (26)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: free sk if last<br /> <br /> When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(),<br /> and released at the end.<br /> <br /> If at that moment, it was the last reference being held, the sk would<br /> not be freed. sock_put() should then be called instead of __sock_put().<br /> <br /> But that&amp;#39;s not enough: if it is the last reference, sock_put() will call<br /> sk_free(), which will end up calling sk_stop_timer_sync() on the same<br /> timer, and waiting indefinitely to finish. So it is needed to mark that<br /> the timer is done at the end of the timer handler when it has not been<br /> rescheduled, not to call sk_stop_timer_sync() on "itself".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kvm: fix vector context allocation leak<br /> <br /> When the second kzalloc (host_context.vector.datap) fails in<br /> kvm_riscv_vcpu_alloc_vector_context, the first allocation<br /> (guest_context.vector.datap) is leaked. Free it before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()<br /> <br /> xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not<br /> already have a dst attached. ip6_route_input_lookup() returns a<br /> referenced dst entry even when the lookup resolves to an error route.<br /> <br /> If dst-&gt;error is set, xfrm6_rcv_encap() drops the skb without attaching<br /> the dst to the skb and without releasing the reference returned by the<br /> lookup. Repeated packets hitting this path therefore leak dst entries.<br /> <br /> Release the dst before jumping to the drop path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exit: prevent preemption of oopsing TASK_DEAD task<br /> <br /> When an already-exiting task oopses, make_task_dead() currently calls<br /> do_task_dead() with preemption enabled. That is forbidden:<br /> do_task_dead() calls __schedule(), which has a comment saying "WARNING:<br /> must be called with preemption disabled!".<br /> <br /> If an oopsing task is preempted in do_task_dead(), between becoming<br /> TASK_DEAD and entering the scheduler explicitly, bad things happen:<br /> finish_task_switch() assumes that once the scheduler has switched away<br /> from a TASK_DEAD task, the task can never run again and its stack is no<br /> longer needed; but that assumption apparently doesn&amp;#39;t hold if the dead<br /> task was preempted (the SM_PREEMPT case).<br /> <br /> This means that the scheduler ends up repeatedly dropping references on<br /> the dead task&amp;#39;s stack, which can lead to use-after-free or double-free<br /> of the entire task stack; in other words, two tasks can end up running<br /> on the same stack, resulting in various kinds of memory corruption.<br /> <br /> (This does not just affect "recursively oopsing" tasks; it is enough to<br /> oops once during task exit, for example in a file_operations::release<br /> handler)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters<br /> <br /> scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring<br /> scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs.<br /> If the loaded scheduler is disabled and freed (via RCU work) and another is<br /> enabled between the naked load and the rwsem acquire, the reader sees<br /> scx_cgroup_enabled=true (the new scheduler&amp;#39;s) but dereferences the freed one<br /> - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...).<br /> <br /> scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write<br /> (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section<br /> correlates @sch with the enabled snapshot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix out-of-bounds read in smb2_compound_op()<br /> <br /> If a server sends a truncated response but a large OutputBufferLength, and<br /> terminates the EA list early, check_wsl_eas() returns success without<br /> validating that the entire OutputBufferLength fits within iov_len.<br /> <br /> Then smb2_compound_op() does:<br /> memcpy(idata-&gt;wsl.eas, data[0], size[0]);<br /> <br /> Where size[0] is OutputBufferLength. If iov_len is smaller than size[0],<br /> memcpy can read beyond the end of the rsp_iov allocation and leak adjacent<br /> kernel heap memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()<br /> <br /> The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and<br /> readl(crtc_reg) will access with random address, because the "device" is<br /> from "base+PCI_DEVICE_ID", "base" is from "pdev-&gt;devfn+1". This is wrong<br /> when my platform inserts a discrete GPU:<br /> <br /> lspci -tv<br /> -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller<br /> ...<br /> +-06.0 Loongson Technology LLC LG100 GPU<br /> +-06.2 Loongson Technology LLC Device 7a37<br /> ...<br /> <br /> Add a default switch case to fix the panic as below:<br /> <br /> Kernel ade access[#1]:<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4<br /> pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0<br /> a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002<br /> a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001<br /> t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000<br /> t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0<br /> t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8<br /> s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000<br /> s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000<br /> ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210<br /> ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)<br /> BADV: 7fffffffffffff00<br /> PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)<br /> Modules linked in:<br /> Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))<br /> Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007<br /> 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff<br /> 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08<br /> 0000000000000000 0000000000000000 0000000000000006 90000001002fb778<br /> 90000001000530b8 90000000027af000 0000000000000000 9000000100054000<br /> 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001<br /> 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000<br /> 0000000000000006 90000000027af000 0000000000000030 90000000027af000<br /> 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560<br /> 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030<br /> ...<br /> Call Trace:<br /> [] loongson_gpu_fixup_dma_hang+0xb4/0x210<br /> [] pci_fixup_device+0x108/0x280<br /> [] pci_setup_device+0x24c/0x690<br /> [] pci_scan_single_device+0xe0/0x140<br /> [] pci_scan_slot+0xc4/0x280<br /> [] pci_scan_child_bus_extend+0x60/0x3f0<br /> [] acpi_pci_root_create+0x2b4/0x420<br /> [] pci_acpi_scan_root+0x2d4/0x440<br /> [] acpi_pci_root_add+0x21c/0x3a0<br /> [] acpi_bus_attach+0x1a4/0x3c0<br /> [] device_for_each_child+0x6c/0xe0<br /> [] acpi_dev_for_each_child+0x44/0x70<br /> [] acpi_bus_attach+0x290/0x3c0<br /> [] device_for_each_child+0x6c/0xe0<br /> [] acpi_dev_for_each_child+0x44/0x70<br /> [] acpi_bus_attach+0x290/0x3c0<br /> [] acpi_bus_scan+0x6c/0x280<br /> [] acpi_scan_init+0x194/0x310<br /> [] acpi_init+0xcc/0x140<br /> [] do_one_initcall+0x4c/0x310<br /> [] kernel_init_freeable+0x258/0x2d4<br /> [] kernel_init+0x28/0x13c<br /> [] ret_from_kernel_thread+0xc/0xa4

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger<br /> <br /> Currently the runtime.oss.trigger field may be accessed concurrently<br /> without protection, which may lead to the data race. And, in this<br /> case, it may lead to more severe problem because it&amp;#39;s a bit field; as<br /> writing the data, it may overwrite other bit fields as well, which<br /> confuses the operation completely, as spotted by fuzzing.<br /> <br /> Fix it by covering runtime.oss.trigger bit fled also with the existing<br /> params_lock mutex in both snd_pcm_oss_get_trigger() and<br /> snd_pcm_oss_poll().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: always decrease sk refcount<br /> <br /> When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer().<br /> It should then be released in all cases at the end.<br /> <br /> Some (unlikely) checks were returning directly instead of calling<br /> sock_put() to decrease the refcount. Jump to a new &amp;#39;exit&amp;#39; label to call<br /> __sock_put() (which will become sock_put() in the next commit) to fix<br /> this potential leak.<br /> <br /> While at it, drop the &amp;#39;!msk&amp;#39; check which cannot happen because it is<br /> never reset, and explicitly mark the remaining one as "unlikely".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak<br /> <br /> btrfs_ioctl_space_info() has a TOCTOU race between two passes over the<br /> block group RAID type lists. The first pass counts entries to determine<br /> the allocation size, then the second pass fills the buffer. The<br /> groups_sem rwlock is released between passes, allowing concurrent block<br /> group removal to reduce the entry count.<br /> <br /> When the second pass fills fewer entries than the first pass counted,<br /> copy_to_user() copies the full alloc_size bytes including trailing<br /> uninitialized kmalloc bytes to userspace.<br /> <br /> Fix by copying only total_spaces entries (the actually-filled count from<br /> the second pass) instead of alloc_size bytes, and switch to kzalloc so<br /> any future copy size mismatch cannot leak heap data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix missing last_unlink_trans update when removing a directory<br /> <br /> When removing a directory we are not updating its last_unlink_trans field,<br /> which can result in incorrect fsync behaviour in case some one fsyncs the<br /> directory after it was removed because it&amp;#39;s holding a file descriptor on<br /> it.<br /> <br /> Example scenario:<br /> <br /> mkdir /mnt/dir1<br /> mkdir /mnt/dir1/dir2<br /> mkdir /mnt/dir3<br /> <br /> sync -f /mnt<br /> <br /> # Do some change to the directory and fsync it.<br /> chmod 700 /mnt/dir1<br /> xfs_io -c fsync /mnt/dir1<br /> <br /> # Move dir2 out of dir1 so that dir1 becomes empty.<br /> mv /mnt/dir1/dir2 /mnt/dir3/<br /> <br /> open fd on /mnt/dir1<br /> call rmdir(2) on path "/mnt/dir1"<br /> fsync fd<br /> <br /> <br /> <br /> When attempting to mount the filesystem, the log replay will fail with<br /> an -EIO error and dmesg/syslog has the following:<br /> <br /> [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650<br /> [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm<br /> [445771.627912] BTRFS info (device dm-0): start tree-log replay<br /> [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5<br /> [445771.629453] memcg:ffff89f400351b00<br /> [445771.629892] aops:btree_aops [btrfs] ino:1<br /> [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8<br /> [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00<br /> [445771.635029] page dumped because: eb page dump<br /> [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir<br /> [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5<br /> [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087<br /> [445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [445771.638097] inode generation 3 transid 9 size 16 nbytes 16384<br /> [445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [445771.638100] rdev 0 sequence 2 flags 0x0<br /> [445771.638102] atime 1775744884.0<br /> [445771.660056] ctime 1775744885.645502983<br /> [445771.660058] mtime 1775744885.645502983<br /> [445771.660060] otime 1775744884.0<br /> [445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [445771.660064] index 0 name_len 2<br /> [445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34<br /> [445771.660068] location key (259 1 0) type 2<br /> [445771.660070] transid 9 data_len 0 name_len 4<br /> [445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34<br /> [445771.660076] location key (257 1 0) type 2<br /> [445771.660077] transid 9 data_len 0 name_len 4<br /> [445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [445771.660079] location key (257 1 0) type 2<br /> [445771.660080] transid 9 data_len 0 name_len 4<br /> [445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34<br /> [445771.660082] location key (259 1 0) type 2<br /> [445771.660083] transid 9 data_len 0 name_len 4<br /> [445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160<br /> [445771.660086] inode generation 9 transid 9 size 8 nbytes 0<br /> [445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0<br /> [445771.660088] rdev 0 sequence 2 flags 0x0<br /> [445771.660089] atime 1775744885.641174097<br /> [445771.660090] ctime 1775744885.645502983<br /> [445771.660091] mtime 1775744885.645502983<br /> [445771.660105] otime 1775744885.641174097<br /> [445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14<br /> [445771.660107] index 2 name_len 4<br /> [445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34<br /> [445771.660109] location key (2<br /> ---truncated---