Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: upper bound check of tree index in dbAllocAG<br /> <br /> When computing the tree index in dbAllocAG, we never check if we are<br /> out of bounds realative to the size of the stree.<br /> This could happen in a scenario where the filesystem metadata are<br /> corrupted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Regular file corruption check<br /> <br /> The reproducer builds a corrupted file on disk with a negative i_size value.<br /> Add a check when opening this file to avoid subsequent operation failures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure<br /> <br /> If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the<br /> resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may<br /> occur before sli4_hba.hdwqs are allocated. This may result in a null<br /> pointer dereference when attempting to take the abts_io_buf_list_lock for<br /> the first hardware queue. Fix by adding a null ptr check on<br /> phba-&gt;sli4_hba.hdwq and early return because this situation means there<br /> must have been an error during port initialization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar<br /> <br /> In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add<br /> check on msg[0].len to prevent crash.<br /> <br /> Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pNFS: Fix uninited ptr deref in block/scsi layout<br /> <br /> The error occurs on the third attempt to encode extents. When function<br /> ext_tree_prepare_commit() reallocates a larger buffer to retry encoding<br /> extents, the "layoutupdate_pages" page array is initialized only after the<br /> retry loop. But ext_tree_free_commitdata() is called on every iteration<br /> and tries to put pages in the array, thus dereferencing uninitialized<br /> pointers.<br /> <br /> An additional problem is that there is no limit on the maximum possible<br /> buffer_size. When there are too many extents, the client may create a<br /> layoutcommit that is larger than the maximum possible RPC size accepted<br /> by the server.<br /> <br /> During testing, we observed two typical scenarios. First, one memory page<br /> for extents is enough when we work with small files, append data to the<br /> end of the file, or preallocate extents before writing. But when we fill<br /> a new large file without preallocating, the number of extents can be huge,<br /> and counting the number of written extents in ext_tree_encode_commit()<br /> does not help much. Since this number increases even more between<br /> unlocking and locking of ext_tree, the reallocated buffer may not be<br /> large enough again and again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: add cluster chain loop check for dir<br /> <br /> An infinite loop may occur if the following conditions occur due to<br /> file system corruption.<br /> <br /> (1) Condition for exfat_count_dir_entries() to loop infinitely.<br /> - The cluster chain includes a loop.<br /> - There is no UNUSED entry in the cluster chain.<br /> <br /> (2) Condition for exfat_create_upcase_table() to loop infinitely.<br /> - The cluster chain of the root directory includes a loop.<br /> - There are no UNUSED entry and up-case table entry in the cluster<br /> chain of the root directory.<br /> <br /> (3) Condition for exfat_load_bitmap() to loop infinitely.<br /> - The cluster chain of the root directory includes a loop.<br /> - There are no UNUSED entry and bitmap entry in the cluster chain<br /> of the root directory.<br /> <br /> (4) Condition for exfat_find_dir_entry() to loop infinitely.<br /> - The cluster chain includes a loop.<br /> - The unused directory entries were exhausted by some operation.<br /> <br /> (5) Condition for exfat_check_dir_empty() to loop infinitely.<br /> - The cluster chain includes a loop.<br /> - The unused directory entries were exhausted by some operation.<br /> - All files and sub-directories under the directory are deleted.<br /> <br /> This commit adds checks to break the above infinite loop.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/migrate: prevent infinite recursion<br /> <br /> If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to<br /> using a bounce buffer. However the bounce buffer here is allocated on<br /> the stack, and the only alignment requirement here is that it&amp;#39;s<br /> naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce<br /> buffer is also misaligned we then recurse back into the function again,<br /> however the new bounce buffer might also not be aligned, and might never<br /> be until we eventually blow through the stack, as we keep recursing.<br /> <br /> Instead of using the stack use kmalloc, which should respect the<br /> power-of-two alignment request here. Fixes a kernel panic when<br /> triggering this path through eudebug.<br /> <br /> v2 (Stuart):<br /> - Add build bug check for power-of-two restriction<br /> - s/EINVAL/ENOMEM/<br /> <br /> (cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Fix NULL dereference in avx512_status()<br /> <br /> Problem<br /> -------<br /> With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status<br /> causes a warning and a NULL pointer dereference.<br /> <br /> This is because the AVX-512 timestamp code uses x86_task_fpu() but<br /> doesn&amp;#39;t check it for NULL. CONFIG_X86_DEBUG_FPU addles that function<br /> for kernel threads (PF_KTHREAD specifically), making it return NULL.<br /> <br /> The point of the warning was to ensure that kernel threads only access<br /> task-&gt;fpu after going through kernel_fpu_begin()/_end(). Note: all<br /> kernel tasks exposed in /proc have a valid task-&gt;fpu.<br /> <br /> Solution<br /> --------<br /> One option is to silence the warning and check for NULL from<br /> x86_task_fpu(). However, that warning is fairly fresh and seems like a<br /> defense against misuse of the FPU state in kernel threads.<br /> <br /> Instead, stop outputting AVX-512_elapsed_ms for kernel threads<br /> altogether. The data was garbage anyway because avx512_timestamp is<br /> only updated for user threads, not kernel threads.<br /> <br /> If anyone ever wants to track kernel thread AVX-512 use, they can come<br /> back later and do it properly, separate from this bug fix.<br /> <br /> [ dhansen: mostly rewrite changelog ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()<br /> <br /> In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and<br /> msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing<br /> msg[0].buf[2] without sanity check, null pointer deref would happen. We add<br /> check on msg[0].len to prevent crash. Similar issue occurs when access<br /> msg[1].buf[0] and msg[1].buf[1].<br /> <br /> Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix vmalloc out-of-bounds write in fast_imageblit<br /> <br /> This issue triggers when a userspace program does an ioctl<br /> FBIOPUT_CON2FBMAP by passing console number and frame buffer number.<br /> Ideally this maps console to frame buffer and updates the screen if<br /> console is visible.<br /> <br /> As part of mapping it has to do resize of console according to frame<br /> buffer info. if this resize fails and returns from vc_do_resize() and<br /> continues further. At this point console and new frame buffer are mapped<br /> and sets display vars. Despite failure still it continue to proceed<br /> updating the screen at later stages where vc_data is related to previous<br /> frame buffer and frame buffer info and display vars are mapped to new<br /> frame buffer and eventully leading to out-of-bounds write in<br /> fast_imageblit(). This bheviour is excepted only when fg_console is<br /> equal to requested console which is a visible console and updates screen<br /> with invalid struct references in fbcon_putcs().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: ets: use old &amp;#39;nbands&amp;#39; while purging unused classes<br /> <br /> Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()<br /> after recent changes from Lion [2]. The problem is: in ets_qdisc_change()<br /> we purge unused DWRR queues; the value of &amp;#39;q-&gt;nbands&amp;#39; is the new one, and<br /> the cleanup should be done with the old one. The problem is here since my<br /> first attempts to fix ets_qdisc_change(), but it surfaced again after the<br /> recent qdisc len accounting fixes. Fix it purging idle DWRR queues before<br /> assigning a new value of &amp;#39;q-&gt;nbands&amp;#39;, so that all purge operations find a<br /> consistent configuration:<br /> <br /> - old &amp;#39;q-&gt;nbands&amp;#39; because it&amp;#39;s needed by ets_class_find()<br /> - old &amp;#39;q-&gt;nstrict&amp;#39; because it&amp;#39;s needed by ets_class_is_strict()<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary)<br /> Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021<br /> RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80<br /> Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab<br /> RSP: 0018:ffffba186009f400 EFLAGS: 00010202<br /> RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004<br /> RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004<br /> R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000<br /> R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000<br /> FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ets_class_qlen_notify+0x65/0x90 [sch_ets]<br /> qdisc_tree_reduce_backlog+0x74/0x110<br /> ets_qdisc_change+0x630/0xa40 [sch_ets]<br /> __tc_modify_qdisc.constprop.0+0x216/0x7f0<br /> tc_modify_qdisc+0x7c/0x120<br /> rtnetlink_rcv_msg+0x145/0x3f0<br /> netlink_rcv_skb+0x53/0x100<br /> netlink_unicast+0x245/0x390<br /> netlink_sendmsg+0x21b/0x470<br /> ____sys_sendmsg+0x39d/0x3d0<br /> ___sys_sendmsg+0x9a/0xe0<br /> __sys_sendmsg+0x7a/0xd0<br /> do_syscall_64+0x7d/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f2155114084<br /> Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89<br /> RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084<br /> RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003<br /> RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f<br /> R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0<br /> R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0<br /> <br /> <br /> [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/<br /> [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hv_netvsc: Fix panic during namespace deletion with VF<br /> <br /> The existing code move the VF NIC to new namespace when NETDEV_REGISTER is<br /> received on netvsc NIC. During deletion of the namespace,<br /> default_device_exit_batch() &gt;&gt; default_device_exit_net() is called. When<br /> netvsc NIC is moved back and registered to the default namespace, it<br /> automatically brings VF NIC back to the default namespace. This will cause<br /> the default_device_exit_net() &gt;&gt; for_each_netdev_safe loop unable to detect<br /> the list end, and hit NULL ptr:<br /> <br /> [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0<br /> [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> [ 231.450246] #PF: supervisor read access in kernel mode<br /> [ 231.450579] #PF: error_code(0x0000) - not-present page<br /> [ 231.450916] PGD 17b8a8067 P4D 0<br /> [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY<br /> [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024<br /> [ 231.452692] Workqueue: netns cleanup_net<br /> [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0<br /> [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00<br /> [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246<br /> [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb<br /> [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564<br /> [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000<br /> [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340<br /> [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340<br /> [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000<br /> [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0<br /> [ 231.458434] Call Trace:<br /> [ 231.458600] <br /> [ 231.458777] ops_undo_list+0x100/0x220<br /> [ 231.459015] cleanup_net+0x1b8/0x300<br /> [ 231.459285] process_one_work+0x184/0x340<br /> <br /> To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid<br /> changing the netdev list when default_device_exit_net() is using it.