- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "bpf/verifier: Fix states_equal() comparison of pointer and UNKNOWN" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf/verifier: Fix states_equal() comparison of pointer and UNKNOWN to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bpf-verifier-fix-states_equal-comparison-of-pointer-and-unknown.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ben(a)decadent.org.uk Wed Dec 27 21:04:06 2017 From: Ben Hutchings <ben(a)decadent.org.uk> Date: Sat, 23 Dec 2017 02:26:17 +0000 Subject: bpf/verifier: Fix states_equal() comparison of pointer and UNKNOWN To: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: stable(a)vger.kernel.org, netdev(a)vger.kernel.org, Edward Cree <ecree(a)solarflare.com>, Jann Horn <jannh(a)google.com>, Alexei Starovoitov <ast(a)kernel.org> Message-ID: <20171223022617.GO2971(a)decadent.org.uk> Content-Disposition: inline From: Ben Hutchings <ben(a)decadent.org.uk> An UNKNOWN_VALUE is not supposed to be derived from a pointer, unless pointer leaks are allowed. Therefore, states_equal() must not treat a state with a pointer in a register as "equal" to a state with an UNKNOWN_VALUE in that register. This was fixed differently upstream, but the code around here was largely rewritten in 4.14 by commit f1174f77b50c "bpf/verifier: rework value tracking". The bug can be detected by the bpf/verifier sub-test "pointer/scalar confusion in state equality check (way 1)". Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk> Cc: Edward Cree <ecree(a)solarflare.com> Cc: Jann Horn <jannh(a)google.com> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Daniel Borkmann <daniel(a)iogearbox.net> --- kernel/bpf/verifier.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2722,11 +2722,12 @@ static bool states_equal(struct bpf_veri /* If we didn't map access then again we don't care about the * mismatched range values and it's ok if our old type was - * UNKNOWN and we didn't go to a NOT_INIT'ed reg. + * UNKNOWN and we didn't go to a NOT_INIT'ed or pointer reg. */ if (rold->type == NOT_INIT || (!varlen_map_access && rold->type == UNKNOWN_VALUE && - rcur->type != NOT_INIT)) + rcur->type != NOT_INIT && + !__is_pointer_value(env->allow_ptr_leaks, rcur))) continue; /* Don't care about the reg->id in this case. */ Patches currently in stable-queue which might be from ben(a)decadent.org.uk are queue-4.9/bpf-verifier-fix-states_equal-comparison-of-pointer-and-unknown.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH V1 0/1] Fix kernel panic caused by device ID duplication presented to the IOMMU

by Tomasz Nowicki

Here is my lspci output of ThunderX2 for which I am observing kernel panic coming from SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live): # lspci -vt -[0000:00]-+-00.0-[01-1f]--+ [...] + [...] \-00.0-[1e-1f]----00.0-[1f]----00.0 ASPEED Technology, Inc. ASPEED Graphics Family ASP device -> 1f:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family PCI-Express to PCI/PCI-X Bridge -> 1e:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge While setting up ASP device SID in IORT dirver: iort_iommu_configure() -> pci_for_each_dma_alias() we need to walk up and iterate over each device which alias transaction from downstream devices. AST device (1f:00.0) gets BDF=0x1f00 and corresponding SID=0x1f00 from IORT. Bridge (1e:00.0) is the first alias. Following PCI Express to PCI/PCI-X Bridge spec: PCIe-to-PCI/X bridges alias transactions from downstream devices using the subordinate bus number. For bridge (1e:00.0), the subordinate is equal to 0x1f. This gives BDF=0x1f00 and SID=1f00 which is the same as downstream device. So it is possible to have two identical SIDs. The question is what we should do about such case. Presented patch prevents from registering the same ID so that SMMUv3 is not complaining later on. Tomasz Nowicki (1): iommu: Make sure device's ID array elements are unique drivers/iommu/iommu.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) -- 2.7.4

7 years, 7 months

5
7
0 0

[Linux-stable-mirror] [PATCH 5/5] tracing: Fix possible double free on failure of allocating trace buffer

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Jing Xia and Chunyan Zhang reported that on failing to allocate part of the tracing buffer, memory is freed, but the pointers that point to them are not initialized back to NULL, and later paths may try to free the freed memory again. Jing and Chunyan fixed one of the locations that does this, but missed a spot. Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Cc: stable(a)vger.kernel.org Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") Reported-by: Jing Xia <jing.xia(a)spreadtrum.com> Reported-by: Chunyan Zhang <chunyan.zhang(a)spreadtrum.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 0e53d46544b8..2a8d8a294345 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -7580,6 +7580,7 @@ allocate_trace_buffer(struct trace_array *tr, struct trace_buffer *buf, int size buf->data = alloc_percpu(struct trace_array_cpu); if (!buf->data) { ring_buffer_free(buf->buffer); + buf->buffer = NULL; return -ENOMEM; } -- 2.13.2

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4/5] tracing: Fix crash when it fails to alloc ring buffer

by Steven Rostedt

From: Jing Xia <jing.xia(a)spreadtrum.com> Double free of the ring buffer happens when it fails to alloc new ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured. The root cause is that the pointer is not set to NULL after the buffer is freed in allocate_trace_buffers(), and the freeing of the ring buffer is invoked again later if the pointer is not equal to Null, as: instance_mkdir() |-allocate_trace_buffers() |-allocate_trace_buffer(tr, &tr->trace_buffer...) |-allocate_trace_buffer(tr, &tr->max_buffer...) // allocate fail(-ENOMEM),first free // and the buffer pointer is not set to null |-ring_buffer_free(tr->trace_buffer.buffer) // out_free_tr |-free_trace_buffers() |-free_trace_buffer(&tr->trace_buffer); //if trace_buffer is not null, free again |-ring_buffer_free(buf->buffer) |-rb_free_cpu_buffer(buffer->buffers[cpu]) // ring_buffer_per_cpu is null, and // crash in ring_buffer_per_cpu->pages Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Cc: stable(a)vger.kernel.org Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") Signed-off-by: Jing Xia <jing.xia(a)spreadtrum.com> Signed-off-by: Chunyan Zhang <chunyan.zhang(a)spreadtrum.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 73652d5318b2..0e53d46544b8 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -7603,7 +7603,9 @@ static int allocate_trace_buffers(struct trace_array *tr, int size) allocate_snapshot ? size : 1); if (WARN_ON(ret)) { ring_buffer_free(tr->trace_buffer.buffer); + tr->trace_buffer.buffer = NULL; free_percpu(tr->trace_buffer.data); + tr->trace_buffer.data = NULL; return -ENOMEM; } tr->allocated_snapshot = allocate_snapshot; -- 2.13.2

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3/5] ring-buffer: Do no reuse reader page if still in use

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> To free the reader page that is allocated with ring_buffer_alloc_read_page(), ring_buffer_free_read_page() must be called. For faster performance, this page can be reused by the ring buffer to avoid having to free and allocate new pages. The issue arises when the page is used with a splice pipe into the networking code. The networking code may up the page counter for the page, and keep it active while sending it is queued to go to the network. The incrementing of the page ref does not prevent it from being reused in the ring buffer, and this can cause the page that is being sent out to the network to be modified before it is sent by reading new data. Add a check to the page ref counter, and only reuse the page if it is not being used anywhere else. Cc: stable(a)vger.kernel.org Fixes: 73a757e63114d ("ring-buffer: Return reader page back into existing ring buffer") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index e06cde093f76..9ab18995ff1e 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -4404,8 +4404,13 @@ void ring_buffer_free_read_page(struct ring_buffer *buffer, int cpu, void *data) { struct ring_buffer_per_cpu *cpu_buffer = buffer->buffers[cpu]; struct buffer_data_page *bpage = data; + struct page *page = virt_to_page(bpage); unsigned long flags; + /* If the page is still in use someplace else, we can't reuse it */ + if (page_ref_count(page) > 1) + goto out; + local_irq_save(flags); arch_spin_lock(&cpu_buffer->lock); @@ -4417,6 +4422,7 @@ void ring_buffer_free_read_page(struct ring_buffer *buffer, int cpu, void *data) arch_spin_unlock(&cpu_buffer->lock); local_irq_restore(flags); + out: free_page((unsigned long)bpage); } EXPORT_SYMBOL_GPL(ring_buffer_free_read_page); -- 2.13.2

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 2/5] tracing: Remove extra zeroing out of the ring buffer page

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> The ring_buffer_read_page() takes care of zeroing out any extra data in the page that it returns. There's no need to zero it out again from the consumer. It was removed from one consumer of this function, but read_buffers_splice_read() did not remove it, and worse, it contained a nasty bug because of it. Cc: stable(a)vger.kernel.org Fixes: 2711ca237a084 ("ring-buffer: Move zeroing out excess in page to ring buffer code") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 59518b8126d0..73652d5318b2 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6769,7 +6769,7 @@ tracing_buffers_splice_read(struct file *file, loff_t *ppos, .spd_release = buffer_spd_release, }; struct buffer_ref *ref; - int entries, size, i; + int entries, i; ssize_t ret = 0; #ifdef CONFIG_TRACER_MAX_TRACE @@ -6823,14 +6823,6 @@ tracing_buffers_splice_read(struct file *file, loff_t *ppos, break; } - /* - * zero out any left over data, this is going to - * user land. - */ - size = ring_buffer_page_len(ref->page); - if (size < PAGE_SIZE) - memset(ref->page + size, 0, PAGE_SIZE - size); - page = virt_to_page(ref->page); spd.pages[i] = page; -- 2.13.2

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/5] ring-buffer: Mask out the info bits when returning buffer page length

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Two info bits were added to the "commit" part of the ring buffer data page when returned to be consumed. This was to inform the user space readers that events have been missed, and that the count may be stored at the end of the page. What wasn't handled, was the splice code that actually called a function to return the length of the data in order to zero out the rest of the page before sending it up to user space. These data bits were returned with the length making the value negative, and that negative value was not checked. It was compared to PAGE_SIZE, and only used if the size was less than PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an unsigned compare, meaning the negative size value did not end up causing a large portion of memory to be randomly zeroed out. Cc: stable(a)vger.kernel.org Fixes: 66a8cb95ed040 ("ring-buffer: Add place holder recording of dropped events") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index c87766c1c204..e06cde093f76 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -280,6 +280,8 @@ EXPORT_SYMBOL_GPL(ring_buffer_event_data); /* Missed count stored at end */ #define RB_MISSED_STORED (1 << 30) +#define RB_MISSED_FLAGS (RB_MISSED_EVENTS|RB_MISSED_STORED) + struct buffer_data_page { u64 time_stamp; /* page time stamp */ local_t commit; /* write committed index */ @@ -331,7 +333,9 @@ static void rb_init_page(struct buffer_data_page *bpage) */ size_t ring_buffer_page_len(void *page) { - return local_read(&((struct buffer_data_page *)page)->commit) + struct buffer_data_page *bpage = page; + + return (local_read(&bpage->commit) & ~RB_MISSED_FLAGS) + BUF_PAGE_HDR_SIZE; } -- 2.13.2

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] v4.14.9 BUG, regression

by Greg KH

On Tue, Dec 26, 2017 at 03:00:55AM +0100, Petr Janecek wrote: > Hi, > the machine started dying reliably shortly after boot after upgrading > to 4.14.9 from 4.14.8. Debian stretch, xfs on md raid10, btrfs. > > > [ 230.855352] BUG: unable to handle kernel paging request at 0000000100000001 > [ 230.862449] IP: free_block+0x135/0x1f0 > [ 230.866301] PGD 0 P4D 0 > [ 230.868939] Oops: 0002 [#1] SMP > [ 230.872178] Modules linked in: xfs x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me iTCO_wdt aes_x86_64 crypto_simd cryptd glue_helper pcspkr iTCO_vendor_support ipmi_si tpm_tis mei evdev tpm_tis_core ipmi_devintf ipmi_msghandler battery sg video tpm acpi_power_meter button ie31200_edac shpchp nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc loop ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear raid10 md_mod uas usb_storage hid_generic usbhid hid sd_mod igb ahci xhci_pci i2c_algo_bit libahci mpt3sas xhci_hcd dca raid_class ptp libata i2c_i801 scsi_transport_sas crc32c_intel usbcore > [ 230.943379] i2c_core pps_core usb_common scsi_mod fan thermal > [ 230.949317] CPU: 0 PID: 57 Comm: kworker/0:1 Not tainted 4.14.9 #23 > [ 230.955688] Hardware name: Supermicro Super Server/X11SSL-CF, BIOS 1.0a 01/29/2016 > [ 230.963357] Workqueue: events cache_reap > [ 230.967380] task: ffff8864b362c000 task.stack: ffff9f0d43380000 > [ 230.973420] RIP: 0010:free_block+0x135/0x1f0 > [ 230.977806] RSP: 0018:ffff9f0d43383d88 EFLAGS: 00010006 > [ 230.983146] RAX: ffffe8625d2e3908 RBX: 0000000080000000 RCX: 0000000000000003 > [ 230.990398] RDX: 00000000fffffffe RSI: ffff8864b7822df0 RDI: ffff8864b6c00480 > [ 230.997654] RBP: dead000000000200 R08: ffff8864b6c01558 R09: ffff8864b6c01540 > [ 231.004909] R10: 00000000006fe8f1 R11: ffff886496597e00 R12: dead000000000100 > [ 231.012162] R13: ffffffff80000000 R14: ffff8864b7822e28 R15: ffffe8625d2e3928 > [ 231.019416] FS: 0000000000000000(0000) GS:ffff8864b7800000(0000) knlGS:0000000000000000 > [ 231.027643] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 231.033509] CR2: 0000000100000001 CR3: 00000005e680b006 CR4: 00000000003606f0 > [ 231.040763] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 231.048017] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 231.055272] Call Trace: > [ 231.057840] drain_array_locked+0x5a/0x90 > [ 231.061963] drain_array+0x60/0x80 > [ 231.065484] cache_reap+0x67/0x1d0 > [ 231.069004] process_one_work+0x1c0/0x3e0 > [ 231.073128] worker_thread+0x42/0x3e0 > [ 231.076907] kthread+0xf7/0x130 > [ 231.080167] ? create_worker+0x180/0x180 > [ 231.084206] ? kthread_create_on_node+0x40/0x40 > [ 231.088850] ret_from_fork+0x1f/0x30 > [ 231.092542] Code: 4f 1c 49 c1 ea 20 44 29 d2 d3 ea 0f b6 4f 1d 41 01 d2 41 d3 ea 8b 48 18 8d 51 ff 48 8b 48 10 89 50 18 48 85 c9 0f 84 a3 00 00 00 <44> 88 14 11 8b 50 18 85 d2 0f 84 26 ff ff ff 49 8b 51 20 48 83 > [ 231.111583] RIP: free_block+0x135/0x1f0 RSP: ffff9f0d43383d88 > [ 231.117443] CR2: 0000000100000001 > [ 231.120875] ---[ end trace e4cdf71e69fa010e ]--- Any chance you can run 'git bisect' to find the offending patch here? thanks, greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] kvm: x86: fix WARN due to uninitialized guest FPU state" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 5663d8f9bbe4bf15488f7351efb61ea20fa6de06 Mon Sep 17 00:00:00 2001 From: Peter Xu <peterx(a)redhat.com> Date: Tue, 12 Dec 2017 17:15:02 +0100 Subject: [PATCH] kvm: x86: fix WARN due to uninitialized guest FPU state ------------[ cut here ]------------ Bad FPU state detected at kvm_put_guest_fpu+0xd8/0x2d0 [kvm], reinitializing FPU registers. WARNING: CPU: 1 PID: 4594 at arch/x86/mm/extable.c:103 ex_handler_fprestore+0x88/0x90 CPU: 1 PID: 4594 Comm: qemu-system-x86 Tainted: G B OE 4.15.0-rc2+ #10 RIP: 0010:ex_handler_fprestore+0x88/0x90 Call Trace: fixup_exception+0x4e/0x60 do_general_protection+0xff/0x270 general_protection+0x22/0x30 RIP: 0010:kvm_put_guest_fpu+0xd8/0x2d0 [kvm] RSP: 0018:ffff8803d5627810 EFLAGS: 00010246 kvm_vcpu_reset+0x3b4/0x3c0 [kvm] kvm_apic_accept_events+0x1c0/0x240 [kvm] kvm_arch_vcpu_ioctl_run+0x1658/0x2fb0 [kvm] kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 do_syscall_64+0x15f/0x600 where kvm_put_guest_fpu is called without a prior kvm_load_guest_fpu. To fix it, move kvm_load_guest_fpu to the very beginning of kvm_arch_vcpu_ioctl_run. Cc: stable(a)vger.kernel.org Fixes: f775b13eedee2f7f3c6fdd4e90fb79090ce5d339 Signed-off-by: Peter Xu <peterx(a)redhat.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 154ea27746e9..56d036b9ad75 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7264,13 +7264,12 @@ static int complete_emulated_mmio(struct kvm_vcpu *vcpu) int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) { - struct fpu *fpu = &current->thread.fpu; int r; - fpu__initialize(fpu); - kvm_sigset_activate(vcpu); + kvm_load_guest_fpu(vcpu); + if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) { if (kvm_run->immediate_exit) { r = -EINTR; @@ -7296,14 +7295,12 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) } } - kvm_load_guest_fpu(vcpu); - if (unlikely(vcpu->arch.complete_userspace_io)) { int (*cui)(struct kvm_vcpu *) = vcpu->arch.complete_userspace_io; vcpu->arch.complete_userspace_io = NULL; r = cui(vcpu); if (r <= 0) - goto out_fpu; + goto out; } else WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed); @@ -7312,9 +7309,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) else r = vcpu_run(vcpu); -out_fpu: - kvm_put_guest_fpu(vcpu); out: + kvm_put_guest_fpu(vcpu); post_kvm_run_save(vcpu); kvm_sigset_deactivate(vcpu);

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [PATCH] Revert "ipmi_si: fix memory leak on new_smi"

by minyard＠acm.org

From: Corey Minyard <cminyard(a)mvista.com> This reverts commit c97e41076a298dbc4e910c33048e553658388eed. A backport was requested of c0a32fe13cd32 "ipmi_si: fix memory leak on new_smi", but the backport shouldn't have been done. This change needs to be reverted, as it can result in an oops and the previous code is correct. Reverts: c97e41076a29 ("ipmi_si: fix memory leak on new_smi") Link: https://bbs.archlinux.org/viewtopic.php?pid=1757130#p1757130 Reported-by: Neil Romig <neil(a)sixtythree.me.uk> Cc: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Corey Minyard <cminyard(a)mvista.com> --- This is for 4.14 stable tree only. In hindsight, I should scrutinize stable kernel requests from others in the IPMI tree. Sorry about that. drivers/char/ipmi/ipmi_si_intf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c index e1cbb78..c04aa11 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -3469,7 +3469,6 @@ static int add_smi(struct smi_info *new_smi) ipmi_addr_src_to_str(new_smi->addr_source), si_to_str[new_smi->si_type]); rv = -EBUSY; - kfree(new_smi); goto out_err; } } -- 2.7.4

7 years, 7 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror