- 20 Dec, 2013 38 commits
-
-
Paul Moore authored
commit 47180068 upstream. In selinux_ip_output() we always label packets based on the parent socket. While this approach works in almost all cases, it doesn't work in the case of TCP SYN-ACK packets when the correct label is not the label of the parent socket, but rather the label of the larval socket represented by the request_sock struct. Unfortunately, since the request_sock isn't queued on the parent socket until *after* the SYN-ACK packet is sent, we can't lookup the request_sock to determine the correct label for the packet; at this point in time the best we can do is simply pass/NF_ACCEPT the packet. It must be said that simply passing the packet without any explicit labeling action, while far from ideal, is not terrible as the SYN-ACK packet will inherit any IP option based labeling from the initial connection request so the label *should* be correct and all our access controls remain in place so we shouldn't have to worry about information leaks. Reported-by:
Janak Desai <Janak.Desai@gtri.gatech.edu> Tested-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sujith Manoharan authored
commit a1783a7b upstream. The EEPROM parameter to determine whether the bias strength values for XLNA have to be applied is part of the miscConfiguration field and not featureEnable. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Sujith Manoharan authored
commit 93c1cfbe upstream. Bit 5 in the miscConfiguration field of the base EEPROM header denotes whether QuickDrop is enabled or not. Fix the incorrect usage of BIT(1) and also make sure that this is done only for the required chips. Signed-off-by:
-
Ville Syrjälä authored
commit 32cf0cb0 upstream. We were miscalculating the pipe CSC post offset for the full->limited range conversion. The resulting post offset was double what it was supposed to be, which caused blacks to come out grey when using limited range output on HSW+. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769Tested-by:
Lauri Mylläri <lauri.myllari@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Linus Pizunski authored
commit eb3c2272 upstream. Update month and day of month to the alarm month/day instead of current day/month when setting the RTC alarm mask. Signed-off-by:
Linus Pizunski <linus@narrativeteam.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Hong H. Pham authored
commit cf77ee54 upstream. In pte_alloc_one(), pgtable_page_ctor() is passed an address that has not been converted by page_address() to the newly allocated PTE page. When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor() with an address to the PTE page that has been converted by page_address(). The mismatch in the PTE's page address causes pgtable_page_dtor() to access invalid memory, so resources for that PTE (such as the page lock) is not properly cleaned up. On PPC32, only SMP kernels are affected. On PPC64, only SMP kernels with 4K page size are affected. This bug was introduced by commit d614bb04 "powerpc: Move the pte free routines from common header". On a preempt-rt kernel, a spinlock is dynamically allocated for each PTE in pgtable_page_ctor(). When the PTE is freed, calling pgtable_page_dtor() with a mismatched page address causes a memory leak, as the pointer to the PTE's spinlock is bogus. On mainline, there isn't any immediately obvious symptoms, but the problem still exists here. Fixes: d614bb04 "powerpc: Move the pte free routes from common header" Cc: Paul Mackerras <paulus@samba.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Hong H. Pham <hong.pham@windriver.com> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Antti Palosaari authored
commit 9323297d upstream. There was three small buffer len calculation bugs which caused driver non-working. These are coming from recent commit: commit 7760e148 [media] af9035: Don't use dynamic static allocation Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Christian Engelmayer authored
commit 4ef38351 upstream. This patch supports the separate handling of the USB transfer buffer length and the length of the buffer used for multi packet support. For devices supporting multiple report or diagnostic packets, the USB transfer size is now limited to the USB endpoints wMaxPacketSize - otherwise it defaults to the configured report packet size as before. This fixes an issue where event reporting can be delayed for an arbitrary time for multi packet devices. For instance the report size for eGalax devices is defined to the 16 byte maximum diagnostic packet size as opposed to the 5 byte report packet size. In case the driver requests 16 byte from the USB interrupt endpoint, the USB host controller driver needs to split up the request into 2 accesses according to the endpoints wMaxPacketSize of 8 byte. When the first transfer is answered by the eGalax device with not less than the full 8 byte requested, the host controller has got no way of knowing whether the touch controller has got additional data queued and will issue the second transfer. If per example a liftoff event finishes at such a wMaxPacketSize boundary, the data will not be available to the usbtouch driver until a further event is triggered and transfered to the host. From user perspective the BTN_TOUCH release event in this case is stuck until the next touch down event. Signed-off-by:
Christian Engelmayer <christian.engelmayer@frequentis.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Fangxiaozhi (Franko) authored
commit 2bf308d7 upstream. Add new supporting declarations to option.c, to support Huawei new devices with new bInterfaceProtocol value. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Gustavo Zacarias authored
commit 8f173e22 upstream. Interface 1 on this device isn't for option to bind to otherwise an oops on usb_wwan with log flooding will happen when accessing the port: tty_release: ttyUSB1: read/write wait queue active! It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add it there - it's likely used by the card reader. Signed-off-by:
Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by:
-
Michael Grzeschik authored
commit 2bac51a1 upstream. The delayed_status value is used to keep track of status response packets on ep0. It needs to be reset or the set_config function would still delay the answer, if the usb device got unplugged while waiting for setup_continue to be called. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit a535d81c upstream. The dwc3 UDC driver doesn't implement endpoint wedging correctly. When an endpoint is wedged, the gadget driver should be allowed to clear the wedge by calling usb_ep_clear_halt(). Only the host is prevented from resetting the endpoint. This patch fixes the implementation. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Pratyush Anand <pratyush.anand@st.com> Signed-off-by:
-
Julius Werner authored
commit 2d51f3cd upstream. This patch adds a check for USB_STATE_NOTATTACHED to the hub_port_warm_reset_required() workaround for ports that end up in Compliance Mode in hub_events() when trying to decide which reset function to use. Trying to call usb_reset_device() with a NOTATTACHED device will just fail and leave the port broken. Signed-off-by:
Julius Werner <jwerner@chromium.org> Acked-by:
-
Jeff Layton authored
commit 781c2a5a upstream. The DRC code will attempt to reuse an existing, expired cache entry in preference to allocating a new one. It'll then search the cache, and if it gets a hit it'll then free the cache entry that it was going to reuse. The cache code doesn't unhash the entry that it's going to reuse however, so it's possible for it end up designating an entry for reuse and then subsequently freeing the same entry after it finds it. This leads it to a later use-after-free situation and usually some list corruption warnings or an oops. Fix this by simply unhashing the entry that we intend to reuse. That will mean that it's not findable via a search and should prevent this situation from occurring. Reported-by:
Christoph Hellwig <hch@infradead.org> Reported-by:
g. artim <gartim@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit f12d5bfc upstream. The hugepage code had the exact same bug that regular pages had in commit 7485d0d3 ("futexes: Remove rw parameter from get_futex_key()"). The regular page case was fixed by commit 9ea71503 ("futex: Fix regression with read only mappings"), but the transparent hugepage case (added in a5b338f2: "thp: update futex compound knowledge") case remained broken. Found by Dave Jones and his trinity tool. Reported-and-tested-by:
Dave Jones <davej@fedoraproject.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Mel Gorman <mgorman@suse.de> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Khalid Aziz authored
commit 4fc9bbf9 upstream. Add a flag to tell the PCI subsystem that kernel is shutting down in preparation to kexec a kernel. Add code in PCI subsystem to use this flag to clear Bus Master bit on PCI devices only in case of kexec reboot. This fixes a power-off problem on Acer Aspire V5-573G and likely other machines and avoids any other issues caused by clearing Bus Master bit on PCI devices in normal shutdown path. The problem was introduced by b566a22c ("PCI: disable Bus Master on PCI device shutdown"). This patch is based on discussion at http://marc.info/?l=linux-pci&m=138425645204355&w=2 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63861Reported-by:
Chang Liu <cl91tp@gmail.com> Signed-off-by:
Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit 31978b5c upstream. If we allocate less than sizeof(struct attrlist) then we end up corrupting memory or doing a ZERO_PTR_SIZE dereference. This can only be triggered with CAP_SYS_ADMIN. Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Fabian Yamaguchi <fabs@goesec.de> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Dave Chinner authored
commit f94c4457 upstream. This loop in xfs_growfs_data_private() is incorrect for V4 superblocks filesystems: for (bucket = 0; bucket < XFS_AGFL_SIZE(mp); bucket++) agfl->agfl_bno[bucket] = cpu_to_be32(NULLAGBLOCK); For V4 filesystems, we don't have a agfl header structure, and so XFS_AGFL_SIZE() returns an entire sector's worth of entries, which we then index from an offset into the sector. Hence: buffer overrun. This problem was introduced in 3.10 by commit 77c95bba ("xfs: add CRC checks to the AGFL") which changed the AGFL structure but failed to update the growfs code to handle the different structures. Fix it by using the correct offset into the buffer for both V4 and V5 filesystems. Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Signed-off-by:
-
Jean Delvare authored
commit 33a7ab91 upstream. The W83L786NG stores the fan speed on 4 bits while the sysfs interface uses a 0-255 range. Thus the driver should scale the user input down to map it to the device range, and scale up the value read from the device before presenting it to the user. The reserved register nibble should be left unchanged. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Brian Carnes authored
commit cf7559bc upstream. The wrong mask is used, which causes some fan speed control modes (pwmX_enable) to be incorrectly reported, and some modes to be impossible to set. [JD: add subject and description.] Signed-off-by:
Brian Carnes <bmcarnes@gmail.com> Signed-off-by:
-
José Miguel Gonçalves authored
commit efabcc21 upstream. Some I2C bus drivers do not allow zero-length data transfers which are required to start a measurement with the HIH6130/1 sensor. Nevertheless, we can overcome this limitation by writing a zero dummy byte. This byte is ignored by the sensor and was verified to be working with the OMAP I2C bus driver in a BeagleBone board. Signed-off-by:
José Miguel Gonçalves <jose.goncalves@inov.pt> [Guenter Roeck: Simplified complexity of write_length initialization] Signed-off-by:
-
Dan Carpenter authored
commit 3806b45b upstream. The "rpm * div" operations can overflow here, so this patch adds an upper limit to rpm to prevent that. Jean Delvare helped me with this patch. Signed-off-by:
Roger Lucas <vt8231@hiddenengine.co.uk> Signed-off-by:
-
Gleb Natapov authored
commit 17d68b76 upstream. A guest can cause a BUG_ON() leading to a host kernel crash. When the guest writes to the ICR to request an IPI, while in x2apic mode the following things happen, the destination is read from ICR2, which is a register that the guest can control. kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the cluster id. A BUG_ON is triggered, which is a protection against accessing map->logical_map with an out-of-bounds access and manages to avoid that anything really unsafe occurs. The logic in the code is correct from real HW point of view. The problem is that KVM supports only one cluster with ID 0 in clustered mode, but the code that has the bug does not take this into account. Reported-by:
Lars Bull <larsbull@google.com> Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Andy Honig authored
commit fda4e2e8 upstream. In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the potential to corrupt kernel memory if userspace provides an address that is at the end of a page. This patches concerts those functions to use kvm_write_guest_cached and kvm_read_guest_cached. It also checks the vapic_address specified by userspace during ioctl processing and returns an error to userspace if the address is not a valid GPA. This is generally not guest triggerable, because the required write is done by firmware that runs before the guest. Also, it only affects AMD processors and oldish Intel that do not have the FlexPriority feature (unless you disable FlexPriority, of course; then newer processors are also affected). Fixes: b93463aa ('KVM: Accelerated apic support') Reported-by:
Andrew Honig <ahonig@google.com> Signed-off-by:
-
Andy Honig authored
commit b963a22e upstream. Under guest controllable circumstances apic_get_tmcct will execute a divide by zero and cause a crash. If the guest cpuid support tsc deadline timers and performs the following sequence of requests the host will crash. - Set the mode to periodic - Set the TMICT to 0 - Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline) - Set the TMICT to non-zero. Then the lapic_timer.period will be 0, but the TMICT will not be. If the guest then reads from the TMCCT then the host will perform a divide by 0. This patch ensures that if the lapic_timer.period is 0, then the division does not occur. Reported-by:
-
Andy Honig authored
commit 338c7dba upstream. In multiple functions the vcpu_id is used as an offset into a bitfield. Ag malicious user could specify a vcpu_id greater than 255 in order to set or clear bits in kernel memory. This could be used to elevate priveges in the kernel. This patch verifies that the vcpu_id provided is less than 255. The api documentation already specifies that the vcpu_id must be less than max_vcpus, but this is currently not checked. Reported-by:
-
Konstantin Khlebnikov authored
commit 3abb6671 upstream. This patch fixes corner case when (fp + 4) overflows unsigned long, for example: fp = 0xFFFFFFFF -> fp + 4 == 3. Signed-off-by:
Konstantin Khlebnikov <k.khlebnikov@samsung.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 1b15ec7a upstream. get_wchan() is lockless. Task may wakeup at any time and change its own stack, thus each next stack frame may be overwritten and filled with random stuff. /proc/$pid/stack interface had been disabled for non-current tasks, see [1] But 'wchan' still allows to trigger stack frame unwinding on volatile stack. This patch fixes oops in unwind_frame() by adding stack pointer validation on each step (as x86 code do), unwind_frame() already checks frame pointer. Also I've found another report of this oops on stackoverflow (irony). Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1] Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-errorSigned-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Roger Quadros authored
commit 7f4d3641 upstream. Unlike what the comment states, errata i660 does not state that we can't RESET the USB host module. Instead it states that RESET is the only way to recover from a deadlock situation. RESET ensures that the module is in a known good state irrespective of what bootloader does with the module, so it must be done at boot. Signed-off-by:
Roger Quadros <rogerq@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3") Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Sergei Ianovich authored
commit ff88b472 upstream. Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by:
Sergei Ianovich <ynvich@gmail.com> Tested-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 506cac15 upstream. When converting from tosa-keyboard driver to matrix keyboard, tosa keys received extra 1 column shift. Replace that with correct values to make keyboard work again. Fixes: f69a6548 ('[ARM] pxa/tosa: make use of the matrix keypad driver') Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
-
Anssi Hannula authored
commit c9a6338a upstream. In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF outputs will have their IEC958 controls created starting from index 16 and the HDMI controls will be created starting from index 0. However, HDMI simple_playback_build_controls() as used by old VIA and NVIDIA codecs incorrectly requests the IEC958 controls to be created with an S/PDIF type instead of HDMI. In case the card has other codecs that have HDMI outputs, the controls will be created with wrong index=16, causing them to e.g. be unreachable by the ALSA "hdmi" alias. Fix that by making simple_playback_build_controls() request controls with HDMI indexes. Not many cards have an affected configuration, but e.g. ASUS M3N78-VM contains an integrated NVIDIA HDA "card" with: - a VIA codec that has, among others, an S/PDIF pin incorrectly labelled as an HDMI pin, and - an NVIDIA MCP7x HDMI codec. Reported-by: MysterX on #openelec Tested-by: MysterX on #openelec Signed-off-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit ebb93c05 upstream. Not all channels have been initialized, so far, especially when aamix NID itself doesn't have amps but its leaves have. This patch fixes these holes. Otherwise you might get unexpected loopback inputs, e.g. from surround channels. Signed-off-by:
-
Takashi Iwai authored
commit 3690739b upstream. AD1986A codec is a pretty old codec and has really many hidden restrictions. One of such is that each DAC is dedicated to certain pin although there are possible connections. Currently, the generic parser tries to assign individual DACs as much as possible, and this lead to two bad situations: connections where the sound actually doesn't work, and connections conflicting other channels. We may fix this by trying to find the best connections more harder, but as of now, it's easier to give some hints for paired DAC/pin connections and honor them if available, since such a hint is needed only for specific codecs (right now only AD1986A, and there will be unlikely any others in future). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621Signed-off-by:
-
Stefano Panella authored
commit 932e9dec upstream. When running a 32bit kernel the hda_intel driver is still reporting a 64bit dma_mask if the HW supports it. From sound/pci/hda/hda_intel.c: /* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))) pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64)); else { pci_set_dma_mask(pci, DMA_BIT_MASK(32)); pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32)); } which means when there is a call to dma_alloc_coherent from snd_malloc_dev_pages a machine address bigger than 32bit can be returned. This can be true in particular if running the 32bit kernel as a pv dom0 under the Xen Hypervisor or PAE on bare metal. The problem is that when calling setup_bdle to program the BLE the dma_addr_t returned from the dma_alloc_coherent is wrongly truncated from snd_sgbuf_get_addr if running a 32bit kernel: static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab, size_t offset) { struct snd_sg_buf *sgbuf = dmab->private_data; dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr; addr &= PAGE_MASK; return addr + offset % PAGE_SIZE; } where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr. Without this patch the HW will fetch the 32bit truncated address, which is not the one obtained from dma_alloc_coherent and will result to a non working audio but can corrupt host memory at a random location. The current patch apply to v3.13-rc3-74-g6c843f5 Signed-off-by:
Stefano Panella <stefano.panella@citrix.com> Reviewed-by:
Frediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by:
-
Takashi Iwai authored
commit 6733cf57 upstream. snd_pcm_uframes_t is defined as unsigned long so it would take different sizes depending on 32 or 64bit architectures. As we don't want this ABI incompatibility, and there is no real 64bit user yet, let's make it the fixed size with __u32. Also bump the protocol version number to 0.1.2. Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Mag authored
commit ed06349f upstream. Signed-off-by:
Nol "Mag" Archinova <magissia@magissia.com> Signed-off-by:
-
Jim Quinlan authored
commit f86f55d3 upstream. The BMIPS5000 (Zephyr) processor utilizes instruction speculation. A stale misprediction address in either the JTB or the CRS may trigger a prefetch inside a region that is currently being used by a DMA engine, which is not IO-coherent. This prefetch will fetch a line into the scache, and that line will soon become stale (ie wrong) during/after the DMA. Mayhem ensues. In dma-default.c, the r10000 is handled as a special case in the same way that we want to handle Zephyr. So we generalize the exception cases into a function, and include Zephyr as one of the processors that needs this special care. Signed-off-by:
Jim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/5776/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: John Ulvr <julvr@broadcom.com> Signed-off-by:
-
- 12 Dec, 2013 2 commits
-
-
Greg Kroah-Hartman authored
-
Tom Lendacky authored
commit 389a5390 upstream. Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is enabled. Use sg_chain_ptr instead of sg_page on a chain entry. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
