Vulnerabilidades

*** Pendiente de traducción *** Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse functions, via untrusted PEM input.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Fix race in push_rt_task<br /> <br /> Overview<br /> ========<br /> When a CPU chooses to call push_rt_task and picks a task to push to<br /> another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method<br /> which would take a double lock on both CPUs&amp;#39; runqueues. If one of the<br /> locks aren&amp;#39;t readily available, it may lead to dropping the current<br /> runqueue lock and reacquiring both the locks at once. During this window<br /> it is possible that the task is already migrated and is running on some<br /> other CPU. These cases are already handled. However, if the task is<br /> migrated and has already been executed and another CPU is now trying to<br /> wake it up (ttwu) such that it is queued again on the runqeue<br /> (on_rq is 1) and also if the task was run by the same CPU, then the<br /> current checks will pass even though the task was migrated out and is no<br /> longer in the pushable tasks list.<br /> <br /> Crashes<br /> =======<br /> This bug resulted in quite a few flavors of crashes triggering kernel<br /> panics with various crash signatures such as assert failures, page<br /> faults, null pointer dereferences, and queue corruption errors all<br /> coming from scheduler itself.<br /> <br /> Some of the crashes:<br /> -&gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &gt;= MAX_RT_PRIO)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? do_error_trap+0x64/0xa0<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> __schedule+0x5cb/0x790<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? __warn+0x8a/0xe0<br /> ? exc_page_fault+0x3d6/0x520<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? pick_next_task_rt+0xb5/0x1d0<br /> ? pick_next_task_rt+0x8c/0x1d0<br /> __schedule+0x583/0x7e0<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff9464daea5900<br /> kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq-&gt;cpu != task_cpu(p))<br /> <br /> -&gt; kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq-&gt;nr_running)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? do_error_trap+0x64/0xa0<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> dequeue_rt_entity+0x1f/0x70<br /> dequeue_task_rt+0x2d/0x70<br /> __schedule+0x1a8/0x7e0<br /> ? blk_finish_plug+0x25/0x40<br /> schedule+0x3c/0xb0<br /> futex_wait_queue_me+0xb6/0x120<br /> futex_wait+0xd9/0x240<br /> do_futex+0x344/0xa90<br /> ? get_mm_exe_file+0x30/0x60<br /> ? audit_exe_compare+0x58/0x70<br /> ? audit_filter_rules.constprop.26+0x65e/0x1220<br /> __x64_sys_futex+0x148/0x1f0<br /> do_syscall_64+0x30/0x80<br /> entry_SYSCALL_64_after_hwframe+0x62/0xc7<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff8cf3608bc2c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? spurious_kernel_fault+0x171/0x1c0<br /> ? exc_page_fault+0x3b6/0x520<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? _cond_resched+0x15/0x30<br /> ? futex_wait_queue_me+0xc8/0x120<br /> ? futex_wait+0xd9/0x240<br /> ? try_to_wake_up+0x1b8/0x490<br /> ? futex_wake+0x78/0x160<br /> ? do_futex+0xcd/0xa90<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? plist_del+0x6a/0xd0<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? dequeue_pushable_task+0x20/0x70<br /> ? __schedule+0x382/0x7e0<br /> ? asm_sysvec_reschedule_i<br /> ---truncated---

*** Pendiente de traducción *** OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Terminating the subsequent process of initialization failure<br /> <br /> syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]<br /> <br /> After PSI initialization fails, the si member is accessed again, resulting<br /> in this uaf.<br /> <br /> After si initialization fails, the subsequent process needs to be exited.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline]<br /> BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524<br /> Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059<br /> <br /> CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0<br /> Hardware name: Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:634<br /> vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78<br /> vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194<br /> vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239<br /> dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973<br /> dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]<br /> dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537<br /> dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3ff/0xb70 fs/file_table.c:464<br /> task_work_run+0x14e/0x250 kernel/task_work.c:227<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0xad8/0x2d70 kernel/exit.c:938<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1087<br /> __do_sys_exit_group kernel/exit.c:1098 [inline]<br /> __se_sys_exit_group kernel/exit.c:1096 [inline]<br /> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096<br /> x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f871d58d169<br /> Code: Unable to access opcode bytes at 0x7f871d58d13f.<br /> RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169<br /> RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840<br /> <br /> <br /> Allocated by task 6059:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> kzalloc_noprof include/linux/slab.h:1037 [inline]<br /> vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970<br /> vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423<br /> vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194<br /> vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239<br /> dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973<br /> dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]<br /> dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537<br /> dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3ff/0xb70 fs/file_tabl<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imagination: fix a potential memory leak in e5010_probe()<br /> <br /> Add video_device_release() to release the memory allocated by<br /> video_device_alloc() if something goes wrong.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cxusb: no longer judge rbuf when the write fails<br /> <br /> syzbot reported a uninit-value in cxusb_i2c_xfer. [1]<br /> <br /> Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()<br /> succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()<br /> will be executed to read rlen bytes of data from the dvb device into the<br /> rbuf.<br /> <br /> In this case, although rlen is 1, the write operation failed which resulted<br /> in the dvb read operation not being executed, and ultimately variable i was<br /> not initialized.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]<br /> BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196<br /> cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]<br /> cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196<br /> __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1<br /> i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315<br /> i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343<br /> i2c_master_send include/linux/i2c.h:109 [inline]<br /> i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183<br /> do_loop_readv_writev fs/read_write.c:848 [inline]<br /> vfs_writev+0x963/0x14e0 fs/read_write.c:1057<br /> do_writev+0x247/0x5c0 fs/read_write.c:1101<br /> __do_sys_writev fs/read_write.c:1169 [inline]<br /> __se_sys_writev fs/read_write.c:1166 [inline]<br /> __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166<br /> x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: validate AG parameters in dbMount() to prevent crashes<br /> <br /> Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch<br /> corrupted metadata early and avoid undefined behavior in dbAllocAG.<br /> Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:<br /> <br /> - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift<br /> (L2LPERCTL - 2*agheight) &gt;= 0.<br /> - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight))<br /> ensures agperlev &gt;= 1.<br /> - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5).<br /> - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG;<br /> 2^(10 - 2*agheight) prevents division to 0.<br /> - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within<br /> stree (size 1365).<br /> - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).<br /> <br /> UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9<br /> shift exponent -335544310 is negative<br /> CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468<br /> dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400<br /> dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613<br /> jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105<br /> jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: Initialize ssc before laundromat_work to prevent NULL dereference<br /> <br /> In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through<br /> nfs4_laundromat -&gt; nfsd4_ssc_expire_umount. If nfsd_ssc isn&amp;#39;t initialized,<br /> this can cause NULL pointer dereference.<br /> <br /> Normally the delayed start of laundromat_work allows sufficient time for<br /> nfsd_ssc initialization to complete. However, when the kernel waits too<br /> long for userspace responses (e.g. in nfs4_state_start_net -&gt;<br /> nfsd4_end_grace -&gt; nfsd4_record_grace_done -&gt; nfsd4_cld_grace_done -&gt;<br /> cld_pipe_upcall -&gt; __cld_pipe_upcall -&gt; wait_for_completion path), the<br /> delayed work may start before nfsd_ssc initialization finishes.<br /> <br /> Fix this by moving nfsd_ssc initialization before starting laundromat_work.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix race between nfsd registration and exports_proc<br /> <br /> As of now nfsd calls create_proc_exports_entry() at start of init_nfsd<br /> and cleanup by remove_proc_entry() at last of exit_nfsd.<br /> <br /> Which causes kernel OOPs if there is race between below 2 operations:<br /> (i) exportfs -r<br /> (ii) mount -t nfsd none /proc/fs/nfsd<br /> <br /> for 5.4 kernel ARM64:<br /> <br /> CPU 1:<br /> el1_irq+0xbc/0x180<br /> arch_counter_get_cntvct+0x14/0x18<br /> running_clock+0xc/0x18<br /> preempt_count_add+0x88/0x110<br /> prep_new_page+0xb0/0x220<br /> get_page_from_freelist+0x2d8/0x1778<br /> __alloc_pages_nodemask+0x15c/0xef0<br /> __vmalloc_node_range+0x28c/0x478<br /> __vmalloc_node_flags_caller+0x8c/0xb0<br /> kvmalloc_node+0x88/0xe0<br /> nfsd_init_net+0x6c/0x108 [nfsd]<br /> ops_init+0x44/0x170<br /> register_pernet_operations+0x114/0x270<br /> register_pernet_subsys+0x34/0x50<br /> init_nfsd+0xa8/0x718 [nfsd]<br /> do_one_initcall+0x54/0x2e0<br /> <br /> CPU 2 :<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> <br /> PC is at : exports_net_open+0x50/0x68 [nfsd]<br /> <br /> Call trace:<br /> exports_net_open+0x50/0x68 [nfsd]<br /> exports_proc_open+0x2c/0x38 [nfsd]<br /> proc_reg_open+0xb8/0x198<br /> do_dentry_open+0x1c4/0x418<br /> vfs_open+0x38/0x48<br /> path_openat+0x28c/0xf18<br /> do_filp_open+0x70/0xe8<br /> do_sys_open+0x154/0x248<br /> <br /> Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().<br /> <br /> and same is happening on latest 6.14 kernel as well:<br /> <br /> [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty<br /> ...<br /> [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48<br /> ...<br /> [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4<br /> ...<br /> [ 285.469695] Call trace:<br /> [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)<br /> [ 285.470488] seq_read+0xe0/0x11c<br /> [ 285.470675] proc_reg_read+0x9c/0xf0<br /> [ 285.470874] vfs_read+0xc4/0x2fc<br /> [ 285.471057] ksys_read+0x6c/0xf4<br /> [ 285.471231] __arm64_sys_read+0x1c/0x28<br /> [ 285.471428] invoke_syscall+0x44/0x100<br /> [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 285.471870] do_el0_svc_compat+0x1c/0x34<br /> [ 285.472073] el0_svc_compat+0x2c/0x80<br /> [ 285.472265] el0t_32_sync_handler+0x90/0x140<br /> [ 285.472473] el0t_32_sync+0x19c/0x1a0<br /> [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)<br /> [ 285.473422] ---[ end trace 0000000000000000 ]---<br /> <br /> It reproduced simply with below script:<br /> while [ 1 ]<br /> do<br /> /exportfs -r<br /> done &amp;<br /> <br /> while [ 1 ]<br /> do<br /> insmod /nfsd.ko<br /> mount -t nfsd none /proc/fs/nfsd<br /> umount /proc/fs/nfsd<br /> rmmod nfsd<br /> done &amp;<br /> <br /> So exporting interfaces to user space shall be done at last and<br /> cleanup at first place.<br /> <br /> With change there is no Kernel OOPs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc64/ftrace: fix clobbered r15 during livepatching<br /> <br /> While r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it is<br /> not restored in livepatch sequence leading to not so obvious fails<br /> like below:<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc0000000000f9078<br /> Faulting instruction address: 0xc0000000018ff958<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790<br /> REGS: c00000005f2e7790 TRAP: 0300 Tainted: G K (6.14.0+)<br /> MSR: 8000000000009033 CR: 2822880b XER: 20040000<br /> CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1<br /> GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488<br /> GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d<br /> GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000<br /> GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070<br /> GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88<br /> GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000<br /> GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078<br /> ...<br /> Call Trace:<br /> check_heap_object+0x34/0x390 (unreliable)<br /> __mutex_unlock_slowpath.isra.0+0xe4/0x230<br /> seq_read_iter+0x430/0xa90<br /> proc_reg_read_iter+0xa4/0x200<br /> vfs_read+0x41c/0x510<br /> ksys_read+0xa4/0x190<br /> system_call_exception+0x1d0/0x440<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Fix it by restoring r15 always.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_pciefd: refine error prone echo_skb_max handling logic<br /> <br /> echo_skb_max should define the supported upper limit of echo_skb[]<br /> allocated inside the netdevice&amp;#39;s priv. The corresponding size value<br /> provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT<br /> which is 17.<br /> <br /> But later echo_skb_max is rounded up to the nearest power of two (for the<br /> max case, that would be 32) and the tx/ack indices calculated further<br /> during tx/rx may exceed the upper array boundary. Kasan reported this for<br /> the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit<br /> function has actually caught the same thing earlier.<br /> <br /> BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528<br /> Read of size 8 at addr ffff888105e4f078 by task swapper/4/0<br /> <br /> CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary)<br /> Call Trace:<br /> <br /> dump_stack_lvl lib/dump_stack.c:122<br /> print_report mm/kasan/report.c:521<br /> kasan_report mm/kasan/report.c:634<br /> kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528<br /> kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605<br /> kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656<br /> kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684<br /> kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733<br /> __handle_irq_event_percpu kernel/irq/handle.c:158<br /> handle_irq_event kernel/irq/handle.c:210<br /> handle_edge_irq kernel/irq/chip.c:833<br /> __common_interrupt arch/x86/kernel/irq.c:296<br /> common_interrupt arch/x86/kernel/irq.c:286<br /> <br /> <br /> Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq<br /> numbers&amp;#39; generation that&amp;#39;s not the case - we&amp;#39;re free to calculate them as<br /> would be more convenient, not taking tx max count into account. The only<br /> downside is that the size of echo_skb[] should correspond to the max seq<br /> number (not tx max count), so in some situations a bit more memory would<br /> be consumed than could be.<br /> <br /> Thus make the size of the underlying echo_skb[] sufficient for the rounded<br /> max tx value.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Cleanup after an allocation error<br /> <br /> When allocation failures are not cleaned up by the driver, further<br /> allocation errors will be false-positives, which will cause buffers to<br /> remain uninitialized and cause NULL pointer dereferences.<br /> Ensure proper cleanup of failed allocations to prevent these issues.