Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free if write is called after disconnect<br /> <br /> If a user writes to the chardev after disconnect has been called, the<br /> kernel panics with the following trace (with<br /> CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000218<br /> ...<br /> Call Trace:<br /> <br /> gb_operation_create_common+0x61/0x180<br /> gb_operation_create_flags+0x28/0xa0<br /> gb_operation_sync_timeout+0x6f/0x100<br /> raw_write+0x7b/0xc7 [gb_raw]<br /> vfs_write+0xcf/0x420<br /> ? task_mm_cid_work+0x136/0x220<br /> ksys_write+0x63/0xe0<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Disconnect calls gb_connection_destroy, which ends up freeing the<br /> connection object. When gb_operation_sync is called in the write file<br /> operations, its gets a freed connection as parameter and the kernel<br /> panics.<br /> <br /> The gb_connection_destroy cannot be moved out of the disconnect<br /> function, as the Greybus subsystem expect all connections belonging to a<br /> bundle to be destroyed when disconnect returns.<br /> <br /> To prevent this bug, use a rw lock to synchronize access between write<br /> and disconnect. This guarantees that the write function doesn&amp;#39;t try<br /> to use a disconnected connection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: terminate the cached volume label after UTF-8 conversion<br /> <br /> ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()<br /> and stores the result in sbi-&gt;volume.label. The converted label is later<br /> exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only<br /> returns the number of bytes written and does not add a trailing NUL.<br /> <br /> If the converted label fills the entire fixed buffer,<br /> ntfs3_label_show() can read past the end of sbi-&gt;volume.label while<br /> looking for a terminator.<br /> <br /> Terminate the cached label explicitly after a successful conversion and<br /> clamp the exact-full case to the last byte of the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: bound enumeration string aggregation<br /> <br /> populate_enum_data() aggregates firmware-provided value-modifier<br /> and possible-value strings into fixed 512-byte struct members.<br /> The current code bounds each individual source string but then<br /> appends every string and separator with raw strcat() and no<br /> remaining-space check.<br /> <br /> Switch the aggregation loops to a bounded append helper and<br /> reject enumeration packages whose combined strings do not fit<br /> in the destination buffers.<br /> <br /> [ij: add include]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix integer overflow in UNMAP bounds check<br /> <br /> sbc_execute_unmap() checks LBA + range does not exceed the device capacity,<br /> but does not guard against LBA + range wrapping around on 64-bit overflow.<br /> <br /> Add an overflow check matching the pattern already used for WRITE_SAME in<br /> the same file.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix potential race condition in TLB sync<br /> <br /> During the TLB sync, we need to traverse and modify the page table,<br /> so we should hold the page table lock. Since full SMP support for<br /> threads within the same process is still missing, let&amp;#39;s disable the<br /> split page table lock for simplicity.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free on cdev close<br /> <br /> This addresses a use-after-free bug when a raw bundle is disconnected<br /> but its chardev is still opened by an application. When the application<br /> releases the cdev, it causes the following panic when init on free is<br /> enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130<br /> ...<br /> Call Trace:<br /> <br /> cdev_put+0x18/0x30<br /> __fput+0x255/0x2a0<br /> __x64_sys_close+0x3d/0x80<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The cdev is contained in the "gb_raw" structure, which is freed in the<br /> disconnect operation. When the cdev is released at a later time,<br /> cdev_put gets an address that points to freed memory.<br /> <br /> To fix this use-after-free, convert the struct device from a pointer to<br /> being embedded, that makes the lifetime of the cdev and of this device<br /> the same. Then, use cdev_device_add, which guarantees that the device<br /> won&amp;#39;t be released until all references to the cdev have been released.<br /> Finally, delegate the freeing of the structure to the device release<br /> function, instead of freeing immediately in the disconnect callback.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg<br /> <br /> In nfsd4_add_rdaccess_to_wrdeleg, if fp-&gt;fi_fds[O_RDONLY] is already<br /> set by another thread, __nfs4_file_get_access should not be called<br /> to increment the nfs4_file access count since that was already done<br /> by the thread that added READ access to the file. The extra fi_access<br /> count in nfs4_file can prevent the corresponding nfsd_file from being<br /> freed.<br /> <br /> When stopping nfs-server service, these extra access counts trigger a<br /> BUG in kmem_cache_destroy() that shows nfsd_file object remaining on<br /> __kmem_cache_shutdown.<br /> <br /> This problem can be reproduced by running the Git project&amp;#39;s test<br /> suite over NFS.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - copy IV using skcipher ivsize<br /> <br /> AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.<br /> <br /> ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller&amp;#39;s IV<br /> buffer while RFC3686 skciphers expose an 8-byte IV, so the restore<br /> overruns the provided buffer.<br /> <br /> Use crypto_skcipher_ivsize() to copy only the algorithm&amp;#39;s IV length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: unify lcn as u64 for 32-bit platforms<br /> <br /> As sashiko reported [1], `lcn` was typed as `unsigned long` (or<br /> `unsigned int` sometimes), which is only 32 bits wide on 32-bit<br /> platforms, which causes `(lcn

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir<br /> <br /> In tcf_blockcast_redir(), when iterating block ports to redirect<br /> packets to multiple devices, the mac_header_xmit flag is queried<br /> from the wrong device. The loop sends to dev_prev but queries<br /> dev_is_mac_header_xmit(dev) — which is the NEXT device in the<br /> iteration, not the one being sent to.<br /> <br /> This causes tcf_mirred_to_dev() to make incorrect decisions about<br /> whether to push or pull the MAC header. When the block contains<br /> mixed device types (e.g., an ethernet veth and a tunnel device),<br /> intermediate devices get the wrong mac_header_xmit flag, leading to<br /> skb header corruption. In the worst case, skb_push_rcsum with an<br /> incorrect mac_len can exhaust headroom and panic.<br /> <br /> The last device in the loop is handled correctly (line 365-366 uses<br /> dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste<br /> oversight for the intermediate devices.<br /> <br /> Fix by using dev_prev instead of dev for the mac_header_xmit query,<br /> consistent with the device actually being sent to.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF<br /> <br /> macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but<br /> macvlan_fill_info() conditionally includes it when port-&gt;bc_cutoff != 1.<br /> This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb<br /> runs out of space, triggering a WARN_ON in rtnetlink and preventing the<br /> interface from being dumped.<br /> <br /> The bug can be reproduced with:<br /> <br /> ip link add macvlan0 link eth0 type macvlan mode bridge<br /> ip link set macvlan0 type macvlan bc_cutoff 0<br /> ip -d link show macvlan0 # fails with -EMSGSIZE<br /> <br /> The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add<br /> netlink attribute for broadcast cutoff"), which added the nla_put_s32()<br /> call in macvlan_fill_info() but missed adding the corresponding<br /> nla_total_size(4) in macvlan_get_size(). A follow-up commit<br /> 55cef78c244d ("macvlan: add forgotten nla_policy for<br /> IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still<br /> did not fix the size calculation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: fix IPv6 route referencing IPv4 nexthop<br /> <br /> syzbot reported a panic [1] [2].<br /> <br /> When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag<br /> of all groups containing this nexthop is not updated. This is because<br /> nh_group_v4_update is only called when replacing AF_INET to AF_INET6,<br /> but the reverse direction (AF_INET6 to AF_INET) is missed.<br /> <br /> This allows a stale has_v4=false to bypass fib6_check_nexthop, causing<br /> IPv6 routes to be attached to groups that effectively contain only AF_INET<br /> members. Subsequent route lookups then call nexthop_fib6_nh() which<br /> returns NULL for the AF_INET member, leading to a NULL pointer<br /> dereference.<br /> <br /> Fix by calling nh_group_v4_update whenever the family changes, not just<br /> AF_INET to AF_INET6.<br /> <br /> Reproducer:<br /> # AF_INET6 blackhole<br /> ip -6 nexthop add id 1 blackhole<br /> # group with has_v4=false<br /> ip nexthop add id 100 group 1<br /> # replace with AF_INET (no -6), has_v4 stays false<br /> ip nexthop replace id 1 blackhole<br /> # pass stale has_v4 check<br /> ip -6 route add 2001:db8::/64 nhid 100<br /> # panic<br /> ping -6 2001:db8::1<br /> <br /> [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0<br /> [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3