Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()<br /> <br /> The function mpt3sas_transport_port_remove() called in<br /> _scsih_expander_node_remove() frees the port field of the sas_expander<br /> structure, leading to the following use-after-free splat from KASAN when<br /> the ioc_info() call following that function is executed (e.g. when doing<br /> rmmod of the driver module):<br /> <br /> [ 3479.371167] ==================================================================<br /> [ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531<br /> [ 3479.393524]<br /> [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436<br /> [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021<br /> [ 3479.409263] Call Trace:<br /> [ 3479.411743] <br /> [ 3479.413875] dump_stack_lvl+0x45/0x59<br /> [ 3479.417582] print_address_description.constprop.0+0x1f/0x120<br /> [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.429469] kasan_report.cold+0x83/0xdf<br /> [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40<br /> [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas]<br /> [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]<br /> [ 3479.465529] ? down_write+0xde/0x150<br /> [ 3479.470746] ? up_write+0x14d/0x460<br /> [ 3479.475840] ? kernfs_find_ns+0x137/0x310<br /> [ 3479.481438] pci_device_remove+0x65/0x110<br /> [ 3479.487013] __device_release_driver+0x316/0x680<br /> [ 3479.493180] driver_detach+0x1ec/0x2d0<br /> [ 3479.498499] bus_remove_driver+0xe7/0x2d0<br /> [ 3479.504081] pci_unregister_driver+0x26/0x250<br /> [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas]<br /> [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510<br /> [ 3479.522315] ? free_module+0xaa0/0xaa0<br /> [ 3479.527593] ? __cond_resched+0x1c/0x90<br /> [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70<br /> [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110<br /> [ 3479.551828] do_syscall_64+0x35/0x80<br /> [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 3479.563402] RIP: 0033:0x7f1fc482483b<br /> ...<br /> [ 3479.943087] ==================================================================<br /> <br /> Fix this by introducing the local variable port_id to store the port ID<br /> value before executing mpt3sas_transport_port_remove(). This local variable<br /> is then used in the call to ioc_info() instead of dereferencing the freed<br /> port structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/omap: Fix regression in probe for NULL pointer dereference<br /> <br /> Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started<br /> triggering a NULL pointer dereference for some omap variants:<br /> <br /> __iommu_probe_device from probe_iommu_group+0x2c/0x38<br /> probe_iommu_group from bus_for_each_dev+0x74/0xbc<br /> bus_for_each_dev from bus_iommu_probe+0x34/0x2e8<br /> bus_iommu_probe from bus_set_iommu+0x80/0xc8<br /> bus_set_iommu from omap_iommu_init+0x88/0xcc<br /> omap_iommu_init from do_one_initcall+0x44/0x24<br /> <br /> This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV)<br /> as noted by Jason Gunthorpe .<br /> <br /> Looks like the regression already happened with an earlier commit<br /> 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs")<br /> that changed the function return type and missed converting one place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qede: confirm skb is allocated before using<br /> <br /> qede_build_skb() assumes build_skb() always works and goes straight<br /> to skb_reserve(). However, build_skb() can fail under memory pressure.<br /> This results in a kernel panic because the skb to reserve is NULL.<br /> <br /> Add a check in case build_skb() failed to allocate and return NULL.<br /> <br /> The NULL return is handled correctly in callers to qede_build_skb().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: Fix five use after free bugs in get_initial_state<br /> <br /> In get_initial_state, it calls notify_initial_state_done(skb,..) if<br /> cb-&gt;args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),<br /> the skb will be freed by nlmsg_free(skb).<br /> Then get_initial_state will goto out and the freed skb will be used by<br /> return value skb-&gt;len, which is a uaf bug.<br /> <br /> What&amp;#39;s worse, the same problem goes even further: skb can also be<br /> freed in the notify_*_state_change -&gt; notify_*_state calls below.<br /> Thus 4 additional uaf bugs happened.<br /> <br /> My patch lets the problem callee functions: notify_initial_state_done<br /> and notify_*_state_change return an error code if errors happen.<br /> So that the error codes could be propagated and the uaf bugs can be avoid.<br /> <br /> v2 reports a compilation warning. This v3 fixed this warning and built<br /> successfully in my local environment with no additional warnings.<br /> v2: https://lore.kernel.org/patchwork/patch/1435218/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix leak of nested actions<br /> <br /> While parsing user-provided actions, openvswitch module may dynamically<br /> allocate memory and store pointers in the internal copy of the actions.<br /> So this memory has to be freed while destroying the actions.<br /> <br /> Currently there are only two such actions: ct() and set(). However,<br /> there are many actions that can hold nested lists of actions and<br /> ovs_nla_free_flow_actions() just jumps over them leaking the memory.<br /> <br /> For example, removal of the flow with the following actions will lead<br /> to a leak of the memory allocated by nf_ct_tmpl_alloc():<br /> <br /> actions:clone(ct(commit),0)<br /> <br /> Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the<br /> tunnel info including device references.<br /> <br /> Under certain conditions with a high rate of flow rotation that may<br /> cause significant memory leak problem (2MB per second in reporter&amp;#39;s<br /> case). The problem is also hard to mitigate, because the user doesn&amp;#39;t<br /> have direct control over the datapath flows generated by OVS.<br /> <br /> Fix that by iterating over all the nested actions and freeing<br /> everything that needs to be freed recursively.<br /> <br /> New build time assertion should protect us from this problem if new<br /> actions will be added in the future.<br /> <br /> Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all<br /> attributes has to be explicitly checked. sample() and clone() actions<br /> are mixing extra attributes into the user-provided action list. That<br /> prevents some code generalization too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lz4: fix LZ4_decompress_safe_partial read out of bound<br /> <br /> When partialDecoding, it is EOF if we&amp;#39;ve either filled the output buffer<br /> or can&amp;#39;t proceed with reading an offset for following match.<br /> <br /> In some extreme corner cases when compressed data is suitably corrupted,<br /> UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial<br /> may lead to read out of bound problem during decoding. lz4 upstream has<br /> fixed it [2] and this issue has been disscussed here [3] before.<br /> <br /> current decompression routine was ported from lz4 v1.8.3, bumping<br /> lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we&amp;#39;d<br /> better fix it first.<br /> <br /> [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/<br /> [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#<br /> [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release correct delalloc amount in direct IO write path<br /> <br /> Running generic/406 causes the following WARNING in btrfs_destroy_inode()<br /> which tells there are outstanding extents left.<br /> <br /> In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding<br /> extents with btrfs_delalloc_reserve_metadata() (or indirectly from<br /> btrfs_delalloc_reserve_space(()). We then release the outstanding extents<br /> with btrfs_delalloc_release_extents(). However, the "len" can be modified<br /> in the COW case, which releases fewer outstanding extents than expected.<br /> <br /> Fix it by calling btrfs_delalloc_release_extents() for the original length.<br /> <br /> To reproduce the warning, the filesystem should be 1 GiB. It&amp;#39;s<br /> triggering a short-write, due to not being able to allocate a large<br /> extent and instead allocating a smaller one.<br /> <br /> WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> Modules linked in: btrfs blake2b_generic xor lzo_compress<br /> lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram<br /> zsmalloc<br /> CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014<br /> RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206<br /> RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000<br /> RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78<br /> RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8<br /> R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800<br /> R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68<br /> FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> destroy_inode+0x33/0x70<br /> dispose_list+0x43/0x60<br /> evict_inodes+0x161/0x1b0<br /> generic_shutdown_super+0x2d/0x110<br /> kill_anon_super+0xf/0x20<br /> btrfs_kill_super+0xd/0x20 [btrfs]<br /> deactivate_locked_super+0x27/0x90<br /> cleanup_mnt+0x12c/0x180<br /> task_work_run+0x54/0x80<br /> exit_to_user_mode_prepare+0x152/0x160<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x42/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f854a000fb7

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix by adding FPU protection for dcn30_internal_validate_bw<br /> <br /> [Why]<br /> Below general protection fault observed when WebGL Aquarium is run for<br /> longer duration. If drm debug logs are enabled and set to 0x1f then the<br /> issue is observed within 10 minutes of run.<br /> <br /> [ 100.717056] general protection fault, probably for non-canonical address 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: G W 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b<br /> [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f<br /> [ 100.767109] Code: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b<br /> [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246<br /> [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500 RCX: 0000000000000000<br /> [ 100.819656] RDX: 0000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000<br /> [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c<br /> [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44<br /> [ 100.841033] R13: 0000000000000001 R14: 0000000000000000 R15: ffffa9230079f0a0<br /> [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000<br /> [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0<br /> [ 100.869106] Call Trace:<br /> [ 100.871555] <br /> [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20<br /> [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd<br /> [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da<br /> [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.899874] ? __sprint_symbol+0x80/0x135<br /> [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2<br /> [ 100.908500] ? symbol_string+0xb7/0xde<br /> [ 100.912250] ? number+0x145/0x29b<br /> [ 100.915566] ? vsnprintf+0x341/0x5ff<br /> [ 100.919141] ? desc_read_finalized_seq+0x39/0x87<br /> [ 100.923755] ? update_load_avg+0x1b9/0x607<br /> [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b<br /> [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c<br /> [ 100.937686] ? dc_fpu_end+0x3d/0xa8<br /> [ 100.941175] dml_get_voltage_level+0x16b/0x180<br /> [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b<br /> [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c<br /> [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc<br /> [ 100.970001] dc_validate_global_state+0x238/0x295<br /> [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce<br /> [ 100.979235] ? _printk+0x59/0x73<br /> [ 100.982467] drm_atomic_check_only+0x403/0x78b<br /> [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546<br /> [ 100.991358] ? drm_ioctl+0x1c1/0x3b3<br /> [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 100.999725] drm_ioctl_kernel+0xdc/0x149<br /> [ 101.003648] drm_ioctl+0x27f/0x3b3<br /> [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d<br /> [ 101.015679] __se_sys_ioctl+0x7c/0xb8<br /> [ 101.015685] do_syscall_64+0x5f/0xb8<br /> [ 101.015690] ? __irq_exit_rcu+0x34/0x96<br /> <br /> [How]<br /> It calles populate_dml_pipes which uses doubles to initialize.<br /> Adding FPU protection avoids context switch and probable loss of vba context<br /> as there is potential contention while drm debug logs are enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix unregistering of framebuffers without device<br /> <br /> OF framebuffers do not have an underlying device in the Linux<br /> device hierarchy. Do a regular unregister call instead of hot<br /> unplugging such a non-existing device. Fixes a NULL dereference.<br /> An example error message on ppc64le is shown below.<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000060<br /> Faulting instruction address: 0xc00000000080dfa4<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> [...]<br /> CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1<br /> NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430<br /> REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365)<br /> MSR: 8000000002009033 CR: 28228282 XER: 20000000<br /> CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0<br /> GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029<br /> GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000<br /> GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283<br /> GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000<br /> GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80<br /> GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0<br /> GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0<br /> GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0<br /> NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0<br /> [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)<br /> [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150<br /> [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0<br /> [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]<br /> [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]<br /> [...]<br /> [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0<br /> [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250<br /> <br /> The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug<br /> firmware fb devices on forced removal"). Most firmware framebuffers<br /> have an underlying platform device, which can be hot-unplugged<br /> before loading the native graphics driver. OF framebuffers do not<br /> (yet) have that device. Fix the code by unregistering the framebuffer<br /> as before without a hot unplug.<br /> <br /> Tested with 5.17 on qemu ppc64le emulation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: ili9341: fix optional regulator handling<br /> <br /> If the optional regulator lookup fails, reset the pointer to NULL.<br /> Other functions such as mipi_dbi_poweron_reset_conditional() only do<br /> a NULL pointer check and will otherwise dereference the error pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: Restrict usage of GPIO chip irq members before initialization<br /> <br /> GPIO chip irq members are exposed before they could be completely<br /> initialized and this leads to race conditions.<br /> <br /> One such issue was observed for the gc-&gt;irq.domain variable which<br /> was accessed through the I2C interface in gpiochip_to_irq() before<br /> it could be initialized by gpiochip_add_irqchip(). This resulted in<br /> Kernel NULL pointer dereference.<br /> <br /> Following are the logs for reference :-<br /> <br /> kernel: Call Trace:<br /> kernel: gpiod_to_irq+0x53/0x70<br /> kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0<br /> kernel: i2c_acpi_get_irq+0xc0/0xd0<br /> kernel: i2c_device_probe+0x28a/0x2a0<br /> kernel: really_probe+0xf2/0x460<br /> kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0<br /> <br /> To avoid such scenarios, restrict usage of GPIO chip irq members before<br /> they are completely initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: sata_dwc_460ex: Fix crash due to OOB write<br /> <br /> the driver uses libata&amp;#39;s "tag" values from in various arrays.<br /> Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,<br /> the value of the SATA_DWC_QCMD_MAX needs to account for that.<br /> <br /> Otherwise ATA_TAG_INTERNAL usage cause similar crashes like<br /> this as reported by Tice Rex on the OpenWrt Forum and<br /> reproduced (with symbols) here:<br /> <br /> | BUG: Kernel NULL pointer dereference at 0x00000000<br /> | Faulting instruction address: 0xc03ed4b8<br /> | Oops: Kernel access of bad area, sig: 11 [#1]<br /> | BE PAGE_SIZE=4K PowerPC 44x Platform<br /> | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0<br /> | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c<br /> | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)<br /> | MSR: 00021000 CR: 42000222 XER: 00000000<br /> | DEAR: 00000000 ESR: 00000000<br /> | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]<br /> | [..]<br /> | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254<br /> | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc<br /> | Call Trace:<br /> | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)<br /> | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc<br /> | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524<br /> | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0<br /> | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204<br /> | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130<br /> | [...]<br /> <br /> This is because sata_dwc_dma_xfer_complete() NULLs the<br /> dma_pending&amp;#39;s next neighbour "chan" (a *dma_chan struct) in<br /> this &amp;#39;32&amp;#39; case right here (line ~735):<br /> &gt; hsdevp-&gt;dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;<br /> <br /> Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes<br /> the NULL&amp;#39;d hsdevp-&gt;chan to the dmaengine_slave_config() which then<br /> causes the crash.<br /> <br /> With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.<br /> This avoids the OOB. But please note, there was a worthwhile discussion<br /> on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not<br /> be a "fake" 33 command-long queue size.<br /> <br /> Ideally, the dw driver should account for the ATA_TAG_INTERNAL.<br /> In Damien Le Moal&amp;#39;s words: "... having looked at the driver, it<br /> is a bigger change than just faking a 33rd "tag" that is in fact<br /> not a command tag at all."<br /> <br /> BugLink: https://github.com/openwrt/openwrt/issues/9505