Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Disable AFBC support on Mediatek DRM driver<br /> <br /> Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM<br /> driver") added AFBC support to Mediatek DRM and enabled the<br /> 32x8/split/sparse modifier.<br /> <br /> However, this is currently broken on Mediatek MT8188 (Genio 700 EVK<br /> platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by<br /> default since Mesa v25.0.<br /> <br /> Kernel trace reports vblank timeouts constantly, and the render is garbled:<br /> <br /> ```<br /> [CRTC:62:crtc-0] vblank wait timed out<br /> WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> [...]<br /> Hardware name: MediaTek Genio-700 EVK (DT)<br /> Workqueue: events_unbound commit_work<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> sp : ffff80008337bca0<br /> x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000<br /> x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000<br /> x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80<br /> x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a<br /> x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b<br /> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70<br /> x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70<br /> x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480<br /> Call trace:<br /> drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)<br /> drm_atomic_helper_commit_tail_rpm+0x64/0x80<br /> commit_tail+0xa4/0x1a4<br /> commit_work+0x14/0x20<br /> process_one_work+0x150/0x290<br /> worker_thread+0x2d0/0x3ec<br /> kthread+0x12c/0x210<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> ```<br /> <br /> Until this gets fixed upstream, disable AFBC support on this platform, as<br /> it&amp;#39;s currently broken with upstream Mesa.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix streaming cleanup on release<br /> <br /> The current implementation unconditionally calls<br /> mxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This can<br /> lead to situations where any release call (like from a simple<br /> "v4l2-ctl -l") may release a currently streaming queue when called on<br /> such a device.<br /> <br /> This is reproducible on an i.MX8MP board by streaming from an ISI<br /> capture device using gstreamer:<br /> <br /> gst-launch-1.0 -v v4l2src device=/dev/videoX ! \<br /> video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \<br /> fakesink<br /> <br /> While this stream is running, querying the caps of the same device<br /> provokes the error state:<br /> <br /> v4l2-ctl -l -d /dev/videoX<br /> <br /> This results in the following trace:<br /> <br /> [ 155.452152] ------------[ cut here ]------------<br /> [ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]<br /> [ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6<br /> [ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT<br /> [ 157.064369] Hardware name: imx8mp_board_01 (DT)<br /> [ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]<br /> [ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi]<br /> [ 157.087126] sp : ffff800080003ee0<br /> [ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000<br /> [ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50<br /> [ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000<br /> [ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000<br /> [ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000<br /> [ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38<br /> [ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000<br /> [ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200<br /> [ 157.161850] Call trace:<br /> [ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)<br /> [ 157.170319] __handle_irq_event_percpu+0x58/0x218<br /> [ 157.175029] handle_irq_event+0x54/0xb8<br /> [ 157.178867] handle_fasteoi_irq+0xac/0x248<br /> [ 157.182968] handle_irq_desc+0x48/0x68<br /> [ 157.186723] generic_handle_domain_irq+0x24/0x38<br /> [ 157.191346] gic_handle_irq+0x54/0x120<br /> [ 157.195098] call_on_irq_stack+0x24/0x30<br /> [ 157.199027] do_interrupt_handler+0x88/0x98<br /> [ 157.203212] el0_interrupt+0x44/0xc0<br /> [ 157.206792] __el0_irq_handler_common+0x18/0x28<br /> [ 157.211328] el0t_64_irq_handler+0x10/0x20<br /> [ 157.215429] el0t_64_irq+0x198/0x1a0<br /> [ 157.219009] ---[ end trace 0000000000000000 ]---<br /> <br /> Address this issue by moving the streaming preparation and cleanup to<br /> the vb2 .prepare_streaming() and .unprepare_streaming() operations. This<br /> also simplifies the driver by allowing direct usage of the<br /> vb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal of<br /> the manual cleanup from mxc_isi_video_release().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: cadence: Check for the existence of cdns_pcie::ops before using it<br /> <br /> cdns_pcie::ops might not be populated by all the Cadence glue drivers. This<br /> is going to be true for the upcoming Sophgo platform which doesn&amp;#39;t set the<br /> ops.<br /> <br /> Hence, add a check to prevent NULL pointer dereference.<br /> <br /> [mani: reworded subject and description]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq/longhaul: handle NULL policy in longhaul_exit<br /> <br /> longhaul_exit() was calling cpufreq_cpu_get(0) without checking<br /> for a NULL policy pointer. On some systems, this could lead to a<br /> NULL dereference and a kernel warning or panic.<br /> <br /> This patch adds a check using unlikely() and returns early if the<br /> policy is NULL.<br /> <br /> Bugzilla: #219962

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: fix possible deadlock while configuring policy<br /> <br /> Following deadlock can be triggered easily by lockdep:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted<br /> ------------------------------------------------------<br /> check/1334 is trying to acquire lock:<br /> ff1100011d9d0678 (&amp;q-&gt;sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180<br /> <br /> but task is already holding lock:<br /> ff1100011d9d00e0 (&amp;q-&gt;q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (&amp;q-&gt;q_usage_counter(queue)#3){++++}-{0:0}:<br /> blk_queue_enter+0x40b/0x470<br /> blkg_conf_prep+0x7b/0x3c0<br /> tg_set_limit+0x10a/0x3e0<br /> cgroup_file_write+0xc6/0x420<br /> kernfs_fop_write_iter+0x189/0x280<br /> vfs_write+0x256/0x490<br /> ksys_write+0x83/0x190<br /> __x64_sys_write+0x21/0x30<br /> x64_sys_call+0x4608/0x4630<br /> do_syscall_64+0xdb/0x6b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> -&gt; #1 (&amp;q-&gt;rq_qos_mutex){+.+.}-{4:4}:<br /> __mutex_lock+0xd8/0xf50<br /> mutex_lock_nested+0x2b/0x40<br /> wbt_init+0x17e/0x280<br /> wbt_enable_default+0xe9/0x140<br /> blk_register_queue+0x1da/0x2e0<br /> __add_disk+0x38c/0x5d0<br /> add_disk_fwnode+0x89/0x250<br /> device_add_disk+0x18/0x30<br /> virtblk_probe+0x13a3/0x1800<br /> virtio_dev_probe+0x389/0x610<br /> really_probe+0x136/0x620<br /> __driver_probe_device+0xb3/0x230<br /> driver_probe_device+0x2f/0xe0<br /> __driver_attach+0x158/0x250<br /> bus_for_each_dev+0xa9/0x130<br /> driver_attach+0x26/0x40<br /> bus_add_driver+0x178/0x3d0<br /> driver_register+0x7d/0x1c0<br /> __register_virtio_driver+0x2c/0x60<br /> virtio_blk_init+0x6f/0xe0<br /> do_one_initcall+0x94/0x540<br /> kernel_init_freeable+0x56a/0x7b0<br /> kernel_init+0x2b/0x270<br /> ret_from_fork+0x268/0x4c0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> -&gt; #0 (&amp;q-&gt;sysfs_lock){+.+.}-{4:4}:<br /> __lock_acquire+0x1835/0x2940<br /> lock_acquire+0xf9/0x450<br /> __mutex_lock+0xd8/0xf50<br /> mutex_lock_nested+0x2b/0x40<br /> blk_unregister_queue+0x53/0x180<br /> __del_gendisk+0x226/0x690<br /> del_gendisk+0xba/0x110<br /> sd_remove+0x49/0xb0 [sd_mod]<br /> device_remove+0x87/0xb0<br /> device_release_driver_internal+0x11e/0x230<br /> device_release_driver+0x1a/0x30<br /> bus_remove_device+0x14d/0x220<br /> device_del+0x1e1/0x5a0<br /> __scsi_remove_device+0x1ff/0x2f0<br /> scsi_remove_device+0x37/0x60<br /> sdev_store_delete+0x77/0x100<br /> dev_attr_store+0x1f/0x40<br /> sysfs_kf_write+0x65/0x90<br /> kernfs_fop_write_iter+0x189/0x280<br /> vfs_write+0x256/0x490<br /> ksys_write+0x83/0x190<br /> __x64_sys_write+0x21/0x30<br /> x64_sys_call+0x4608/0x4630<br /> do_syscall_64+0xdb/0x6b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> other info that might help us debug this:<br /> <br /> Chain exists of:<br /> &amp;q-&gt;sysfs_lock --&gt; &amp;q-&gt;rq_qos_mutex --&gt; &amp;q-&gt;q_usage_counter(queue)#3<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;q-&gt;q_usage_counter(queue)#3);<br /> lock(&amp;q-&gt;rq_qos_mutex);<br /> lock(&amp;q-&gt;q_usage_counter(queue)#3);<br /> lock(&amp;q-&gt;sysfs_lock);<br /> <br /> Root cause is that queue_usage_counter is grabbed with rq_qos_mutex<br /> held in blkg_conf_prep(), while queue should be freezed before<br /> rq_qos_mutex from other context.<br /> <br /> The blk_queue_enter() from blkg_conf_prep() is used to protect against<br /> policy deactivation, which is already protected with blkcg_mutex, hence<br /> convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,<br /> consider that blkcg_mutex is held after queue is freezed from policy<br /> deactivation, also convert blkg_alloc() to use GFP_NOIO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP<br /> <br /> As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible<br /> crashes. The problem is that kernel page tables are modified without<br /> flushing corresponding TLB entries.<br /> <br /> Even if it looks like the empty flush_tlb_all() implementation on s390 is<br /> the problem, it is actually a different problem: on s390 it is not allowed<br /> to replace an active/valid page table entry with another valid page table<br /> entry without the detour over an invalid entry. A direct replacement may<br /> lead to random crashes and/or data corruption.<br /> <br /> In order to invalidate an entry special instructions have to be used<br /> (e.g. ipte or idte). Alternatively there are also special instructions<br /> available which allow to replace a valid entry with a different valid<br /> entry (e.g. crdte or cspg).<br /> <br /> Given that the HVO code currently does not provide the hooks to allow for<br /> an implementation which is compliant with the s390 architecture<br /> requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is<br /> basically a revert of the original patch which enabled it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aspeed - fix double free caused by devm<br /> <br /> The clock obtained via devm_clk_get_enabled() is automatically managed<br /> by devres and will be disabled and freed on driver detach. Manually<br /> calling clk_disable_unprepare() in error path and remove function<br /> causes double free.<br /> <br /> Remove the manual clock cleanup in both aspeed_acry_probe()&amp;#39;s error<br /> path and aspeed_acry_remove().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix softlockup in ftrace_module_enable<br /> <br /> A soft lockup was observed when loading amdgpu module.<br /> If a module has a lot of tracable functions, multiple calls<br /> to kallsyms_lookup can spend too much time in RCU critical<br /> section and with disabled preemption, causing kernel panic.<br /> This is the same issue that was fixed in<br /> commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY<br /> kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to<br /> ftrace_graph_set_hash()").<br /> <br /> Fix it the same way by adding cond_resched() in ftrace_module_enable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amd/amdkfd: enhance kfd process check in switch partition<br /> <br /> current switch partition only check if kfd_processes_table is empty.<br /> kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but<br /> kfd_process tear down is in kfd_process_wq_release.<br /> <br /> consider two processes:<br /> <br /> Process A (workqueue) -&gt; kfd_process_wq_release -&gt; Access kfd_node member<br /> Process B switch partition -&gt; amdgpu_xcp_pre_partition_switch -&gt; amdgpu_amdkfd_device_fini_sw<br /> -&gt; kfd_node tear down.<br /> <br /> Process A and B may trigger a race as shown in dmesg log.<br /> <br /> This patch is to resolve the race by adding an atomic kfd_process counter<br /> kfd_processes_count, it increment as create kfd process, decrement as<br /> finish kfd_process_wq_release.<br /> <br /> v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds<br /> and bug fix. (Philip Yang)<br /> <br /> [3966658.307702] divide error: 0000 [#1] SMP NOPTI<br /> [3966658.350818] i10nm_edac<br /> [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted<br /> [3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]<br /> [3966658.362839] nfit<br /> [3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]<br /> [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00<br /> [3966658.380967] x86_pkg_temp_thermal<br /> [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246<br /> [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000<br /> [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00<br /> [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4<br /> [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000<br /> [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800<br /> [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000<br /> [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0<br /> [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [3966658.391536] PKRU: 55555554<br /> [3966658.391536] Call Trace:<br /> [3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu]<br /> [3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu]<br /> [3966658.399754] intel_powerclamp<br /> [3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]<br /> [3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu]<br /> [3966658.410516] coretemp<br /> [3966658.434016] process_one_work+0x1ad/0x380<br /> [3966658.434021] worker_thread+0x49/0x310<br /> [3966658.438963] kvm_intel<br /> [3966658.446041] ? process_one_work+0x380/0x380<br /> [3966658.446045] kthread+0x118/0x140<br /> [3966658.446047] ? __kthread_bind_mask+0x60/0x60<br /> [3966658.446050] ret_from_fork+0x1f/0x30<br /> [3966658.446053] Modules linked in: kpatch_20765354(OEK)<br /> [3966658.455310] kvm<br /> [3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)<br /> [3966658.473462] idxd_mdev<br /> [3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock<br /> <br /> The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix multifs mds auth caps issue<br /> <br /> The mds auth caps check should also validate the<br /> fsname along with the associated caps. Not doing<br /> so would result in applying the mds auth caps of<br /> one fs on to the other fs in a multifs ceph cluster.<br /> The bug causes multiple issues w.r.t user<br /> authentication, following is one such example.<br /> <br /> Steps to Reproduce (on vstart cluster):<br /> 1. Create two file systems in a cluster, say &amp;#39;fsname1&amp;#39; and &amp;#39;fsname2&amp;#39;<br /> 2. Authorize read only permission to the user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname1&amp;#39;<br /> $ceph fs authorize fsname1 client.usr / r<br /> 3. Authorize read and write permission to the same user &amp;#39;client.usr&amp;#39; on fs &amp;#39;fsname2&amp;#39;<br /> $ceph fs authorize fsname2 client.usr / rw<br /> 4. Update the keyring<br /> $ceph auth get client.usr &gt;&gt; ./keyring<br /> <br /> With above permssions for the user &amp;#39;client.usr&amp;#39;, following is the<br /> expectation.<br /> a. The &amp;#39;client.usr&amp;#39; should be able to only read the contents<br /> and not allowed to create or delete files on file system &amp;#39;fsname1&amp;#39;.<br /> b. The &amp;#39;client.usr&amp;#39; should be able to read/write on file system &amp;#39;fsname2&amp;#39;.<br /> <br /> But, with this bug, the &amp;#39;client.usr&amp;#39; is allowed to read/write on file<br /> system &amp;#39;fsname1&amp;#39;. See below.<br /> <br /> 5. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.usr&amp;#39;<br /> $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/<br /> 6. Try creating a file on file system &amp;#39;fsname1&amp;#39; with user &amp;#39;client.usr&amp;#39;. This<br /> should fail but passes with this bug.<br /> $touch /kmnt_fsname1_usr/file1<br /> 7. Mount the file system &amp;#39;fsname1&amp;#39; with the user &amp;#39;client.admin&amp;#39; and create a<br /> file.<br /> $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin<br /> $echo "data" &gt; /kmnt_fsname1_admin/admin_file1<br /> 8. Try removing an existing file on file system &amp;#39;fsname1&amp;#39; with the user<br /> &amp;#39;client.usr&amp;#39;. This shoudn&amp;#39;t succeed but succeeds with the bug.<br /> $rm -f /kmnt_fsname1_usr/admin_file1<br /> <br /> For more information, please take a look at the corresponding mds/fuse patch<br /> and tests added by looking into the tracker mentioned below.<br /> <br /> v2: Fix a possible null dereference in doutc<br /> v3: Don&amp;#39;t store fsname from mdsmap, validate against<br /> ceph_mount_options&amp;#39;s fsname and use it<br /> v4: Code refactor, better warning message and<br /> fix possible compiler warning<br /> <br /> [ Slava.Dubeyko: "fsname check failed" -&gt; "fsname mismatch" ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: fix field-spanning memcpy warning in AH output<br /> <br /> Fix field-spanning memcpy warnings in ah6_output() and<br /> ah6_output_done() where extension headers are copied to/from IPv6<br /> address fields, triggering fortify-string warnings about writes beyond<br /> the 16-byte address fields.<br /> <br /> memcpy: detected field-spanning write (size 40) of single field "&amp;top_iph-&gt;saddr" at net/ipv6/ah6.c:439 (size 16)<br /> WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439<br /> <br /> The warnings are false positives as the extension headers are<br /> intentionally placed after the IPv6 header in memory. Fix by properly<br /> copying addresses and extension headers separately, and introduce<br /> helper functions to avoid code duplication.