Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: do not leak refcount in reorder_work<br /> <br /> A recent patch that addressed a UAF introduced a reference count leak:<br /> the parallel_data refcount is incremented unconditionally, regardless<br /> of the return value of queue_work(). If the work item is already queued,<br /> the incremented refcount is never decremented.<br /> <br /> Fix this by checking the return value of queue_work() and decrementing<br /> the refcount when necessary.<br /> <br /> Resolves:<br /> <br /> Unreferenced object 0xffff9d9f421e3d80 (size 192):<br /> comm "cryptomgr_probe", pid 157, jiffies 4294694003<br /> hex dump (first 32 bytes):<br /> 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............<br /> d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#.<br /> backtrace (crc 838fb36):<br /> __kmalloc_cache_noprof+0x284/0x320<br /> padata_alloc_pd+0x20/0x1e0<br /> padata_alloc_shell+0x3b/0xa0<br /> 0xffffffffc040a54d<br /> cryptomgr_probe+0x43/0xc0<br /> kthread+0xf6/0x1f0<br /> ret_from_fork+0x2f/0x50<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mr: consolidate the ipmr_can_free_table() checks.<br /> <br /> Guoyu Yin reported a splat in the ipmr netns cleanup path:<br /> <br /> WARNING: CPU: 2 PID: 14564 at net/ipv4/ipmr.c:440 ipmr_free_table net/ipv4/ipmr.c:440 [inline]<br /> WARNING: CPU: 2 PID: 14564 at net/ipv4/ipmr.c:440 ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 14564 Comm: syz.4.838 Not tainted 6.14.0 #1<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ipmr_free_table net/ipv4/ipmr.c:440 [inline]<br /> RIP: 0010:ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 75 7d 48 c7 83 60 05 00 00 00 00 00 00 5b 5d 41 5c 41 5d 41 5e e9 71 67 7f 00 e8 4c 2d 8a fd 90 0b 90 eb 93 e8 41 2d 8a fd 0f b6 2d 80 54 ea 01 31 ff 89 ee e8<br /> RSP: 0018:ffff888109547c58 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff888108c12dc0 RCX: ffffffff83e09868<br /> RDX: ffff8881022b3300 RSI: ffffffff83e098d4 RDI: 0000000000000005<br /> RBP: ffff888104288000 R08: 0000000000000000 R09: ffffed10211825c9<br /> R10: 0000000000000001 R11: ffff88801816c4a0 R12: 0000000000000001<br /> R13: ffff888108c13320 R14: ffff888108c12dc0 R15: fffffbfff0b74058<br /> FS: 00007f84f39316c0(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f84f3930f98 CR3: 0000000113b56000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ipmr_net_exit_batch+0x50/0x90 net/ipv4/ipmr.c:3160<br /> ops_exit_list+0x10c/0x160 net/core/net_namespace.c:177<br /> setup_net+0x47d/0x8e0 net/core/net_namespace.c:394<br /> copy_net_ns+0x25d/0x410 net/core/net_namespace.c:516<br /> create_new_namespaces+0x3f6/0xaf0 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc3/0x180 kernel/nsproxy.c:228<br /> ksys_unshare+0x78d/0x9a0 kernel/fork.c:3342<br /> __do_sys_unshare kernel/fork.c:3413 [inline]<br /> __se_sys_unshare kernel/fork.c:3411 [inline]<br /> __x64_sys_unshare+0x31/0x40 kernel/fork.c:3411<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f84f532cc29<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f84f3931038 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00007f84f5615fa0 RCX: 00007f84f532cc29<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000400<br /> RBP: 00007f84f53fba18 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f84f5615fa0 R15: 00007fff51c5f328<br /> <br /> <br /> The running kernel has CONFIG_IP_MROUTE_MULTIPLE_TABLES disabled, and<br /> the sanity check for such build is still too loose.<br /> <br /> Address the issue consolidating the relevant sanity check in a single<br /> helper regardless of the kernel configuration. Also share it between<br /> the ipv4 and ipv6 code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust &gt;= 1.88<br /> <br /> Calling core::fmt::write() from rust code while FineIBT is enabled<br /> results in a kernel panic:<br /> <br /> [ 4614.199779] kernel BUG at arch/x86/kernel/cet.c:132!<br /> [ 4614.205343] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Tainted: G U O 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599<br /> [ 4614.227832] Tainted: [U]=USER, [O]=OOT_MODULE<br /> [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0<br /> ...<br /> [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20<br /> [ 4614.407792] Code: 48 f7 df 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7<br /> [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246<br /> [ 4614.434609] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000<br /> [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88<br /> [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070<br /> [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8<br /> [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000<br /> [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10<br /> [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250<br /> <br /> This happens because core::fmt::write() calls<br /> core::fmt::rt::Argument::fmt(), which currently has CFI disabled:<br /> <br /> library/core/src/fmt/rt.rs:<br /> 171 // FIXME: Transmuting formatter in new and indirectly branching to/calling<br /> 172 // it here is an explicit CFI violation.<br /> 173 #[allow(inline_no_sanitize)]<br /> 174 #[no_sanitize(cfi, kcfi)]<br /> 175 #[inline]<br /> 176 pub(super) unsafe fn fmt(&amp;self, f: &amp;mut Formatter) -&gt; Result {<br /> <br /> This causes a Control Protection exception, because FineIBT has sealed<br /> off the original function&amp;#39;s endbr64.<br /> <br /> This makes rust currently incompatible with FineIBT. Add a Kconfig<br /> dependency that prevents FineIBT from getting turned on by default<br /> if rust is enabled.<br /> <br /> [ Rust 1.88.0 (scheduled for 2025-06-26) should have this fixed [1],<br /> and thus we relaxed the condition with Rust &gt;= 1.88.<br /> <br /> When `objtool` lands checking for this with e.g. [2], the plan is<br /> to ideally run that in upstream Rust&amp;#39;s CI to prevent regressions<br /> early [3], since we do not control `core`&amp;#39;s source code.<br /> <br /> Alice tested the Rust PR backported to an older compiler.<br /> <br /> Peter would like that Rust provides a stable `core` which can be<br /> pulled into the kernel: "Relying on that much out of tree code is<br /> &amp;#39;unfortunate&amp;#39;".<br /> <br /> - Miguel ]<br /> <br /> [ Reduced splat. - Miguel ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref<br /> <br /> btrfs_prelim_ref() calls the old and new reference variables in the<br /> incorrect order. This causes a NULL pointer dereference because oldref<br /> is passed as NULL to trace_btrfs_prelim_ref_insert().<br /> <br /> Note, trace_btrfs_prelim_ref_insert() is being called with newref as<br /> oldref (and oldref as NULL) on purpose in order to print out<br /> the values of newref.<br /> <br /> To reproduce:<br /> echo 1 &gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable<br /> <br /> Perform some writeback operations.<br /> <br /> Backtrace:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130<br /> Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88<br /> RSP: 0018:ffffce44820077a0 EFLAGS: 00010286<br /> RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b<br /> RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010<br /> RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010<br /> R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000<br /> R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540<br /> FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> prelim_ref_insert+0x1c1/0x270<br /> find_parent_nodes+0x12a6/0x1ee0<br /> ? __entry_text_end+0x101f06/0x101f09<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> btrfs_is_data_extent_shared+0x167/0x640<br /> ? fiemap_process_hole+0xd0/0x2c0<br /> extent_fiemap+0xa5c/0xbc0<br /> ? __entry_text_end+0x101f05/0x101f09<br /> btrfs_fiemap+0x7e/0xd0<br /> do_vfs_ioctl+0x425/0x9d0<br /> __x64_sys_ioctl+0x75/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: don&amp;#39;t restore null sk_state_change<br /> <br /> queue-&gt;state_change is set as part of nvmet_tcp_set_queue_sock(), but if<br /> the TCP connection isn&amp;#39;t established when nvmet_tcp_set_queue_sock() is<br /> called then queue-&gt;state_change isn&amp;#39;t set and sock-&gt;sk-&gt;sk_state_change<br /> isn&amp;#39;t replaced.<br /> <br /> As such we don&amp;#39;t need to restore sock-&gt;sk-&gt;sk_state_change if<br /> queue-&gt;state_change is NULL.<br /> <br /> This avoids NULL pointer dereferences such as this:<br /> <br /> [ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode<br /> [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page<br /> [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0<br /> [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI<br /> [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)<br /> [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> [ 286.467147][ C0] RIP: 0010:0x0<br /> [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246<br /> [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43<br /> [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100<br /> [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c<br /> [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3<br /> [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268<br /> [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000<br /> [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0<br /> [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400<br /> [ 286.475453][ C0] Call Trace:<br /> [ 286.476102][ C0] <br /> [ 286.476719][ C0] tcp_fin+0x2bb/0x440<br /> [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60<br /> [ 286.478174][ C0] ? __build_skb_around+0x234/0x330<br /> [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0<br /> [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10<br /> [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0<br /> [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90<br /> [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30<br /> [ 286.482769][ C0] ? ktime_get+0x66/0x150<br /> [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0<br /> [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050<br /> [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0<br /> [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0<br /> [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10<br /> [ 286.486917][ C0] ? lock_release+0x217/0x2c0<br /> [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0<br /> [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30<br /> [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0<br /> [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0<br /> [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10<br /> [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10<br /> [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]<br /> [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0<br /> [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370<br /> [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420<br /> [ 286.494268][ C0] ip_local_deliver+0x168/0x430<br /> [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10<br /> [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10<br /> [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20<br /> [ 286.496806][ C0] ? lock_release+0x217/0x2c0<br /> [ 286.497414][ C0] ip_rcv+0x455/0x6e0<br /> [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10<br /> [ <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Perform early GT MMIO initialization to read GMDID<br /> <br /> VFs need to communicate with the GuC to obtain the GMDID value<br /> and existing GuC functions used for that assume that the GT has<br /> it&amp;#39;s MMIO members already setup. However, due to recent refactoring<br /> the gt-&gt;mmio is initialized later, and any attempt by the VF to use<br /> xe_mmio_read|write() from GuC functions will lead to NPD crash due<br /> to unset MMIO register address:<br /> <br /> [] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode<br /> [] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507<br /> [] BUG: unable to handle page fault for address: 0000000000190240<br /> <br /> Since we are already tweaking the id and type of the primary GT to<br /> mimic it&amp;#39;s a Media GT before initializing the GuC communication,<br /> we can also call xe_gt_mmio_init() to perform early setup of the<br /> gt-&gt;mmio which will make those GuC functions work again.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: handle failure of nfs_get_lock_context in unlock path<br /> <br /> When memory is insufficient, the allocation of nfs_lock_context in<br /> nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat<br /> an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)<br /> as valid and proceed to execute rpc_run_task(), this will trigger a NULL<br /> pointer dereference in nfs4_locku_prepare. For example:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000000c<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40<br /> Workqueue: rpciod rpc_async_schedule<br /> RIP: 0010:nfs4_locku_prepare+0x35/0xc2<br /> Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3<br /> RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246<br /> RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40<br /> RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38<br /> R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030<br /> R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30<br /> FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> __rpc_execute+0xbc/0x480<br /> rpc_async_schedule+0x2f/0x40<br /> process_one_work+0x232/0x5d0<br /> worker_thread+0x1da/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10d/0x240<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Modules linked in:<br /> CR2: 000000000000000c<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and<br /> return NULL to terminate subsequent rpc_run_task, preventing NULL pointer<br /> dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xcf/0x610 mm/kasan/report.c:489<br /> kasan_report+0xb5/0xe0 mm/kasan/report.c:602<br /> rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195<br /> rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132<br /> __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232<br /> rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109<br /> create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052<br /> ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095<br /> ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679<br /> vfs_write fs/read_write.c:677 [inline]<br /> vfs_write+0x26a/0xcc0 fs/read_write.c:659<br /> ksys_write+0x1b8/0x200 fs/read_write.c:731<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> In the function rxe_create_cq, when rxe_cq_from_init fails, the function<br /> rxe_cleanup will be called to handle the allocated resources. In fact,<br /> some memory resources have already been freed in the function<br /> rxe_cq_from_init. Thus, this problem will occur.<br /> <br /> The solution is to let rxe_cleanup do all the work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7606: check for NULL before calling sw_mode_config()<br /> <br /> Check that the sw_mode_config function pointer is not NULL before<br /> calling it. Not all buses define this callback, which resulted in a NULL<br /> pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: max20086: fix invalid memory access<br /> <br /> max20086_parse_regulators_dt() calls of_regulator_match() using an<br /> array of struct of_regulator_match allocated on the stack for the<br /> matches argument.<br /> <br /> of_regulator_match() calls devm_of_regulator_put_matches(), which calls<br /> devres_alloc() to allocate a struct devm_of_regulator_matches which will<br /> be de-allocated using devm_of_regulator_put_matches().<br /> <br /> struct devm_of_regulator_matches is populated with the stack allocated<br /> matches array.<br /> <br /> If the device fails to probe, devm_of_regulator_put_matches() will be<br /> called and will try to call of_node_put() on that stack pointer,<br /> generating the following dmesg entries:<br /> <br /> max20086 6-0028: Failed to read DEVICE_ID reg: -121<br /> kobject: &amp;#39;\xc0$\xa5\x03&amp;#39; (000000002cebcb7a): is not initialized, yet<br /> kobject_put() is being called.<br /> <br /> Followed by a stack trace matching the call flow described above.<br /> <br /> Switch to allocating the matches array using devm_kcalloc() to<br /> avoid accessing the stack pointer long after it&amp;#39;s out of scope.<br /> <br /> This also has the advantage of allowing multiple max20086 to probe<br /> without overriding the data stored inside the global of_regulator_match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS/localio: Fix a race in nfs_local_open_fh()<br /> <br /> Once the clp-&gt;cl_uuid.lock has been dropped, another CPU could come in<br /> and free the struct nfsd_file that was just added. To prevent that from<br /> happening, take the RCU read lock before dropping the spin lock.