In the Linux kernel, the following vulnerability has been resolved:

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

In the Linux kernel, the following vulnerability has been resolved:

iommufd: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

In the Linux kernel, the following vulnerability has been resolved:

iommufd: Set upper bounds on cache invalidation entrynum and entrylen

iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.

A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.

Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.

In the Linux kernel, the following vulnerability has been resolved:

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.

In the Linux kernel, the following vulnerability has been resolved:

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

In the Linux kernel, the following vulnerability has been resolved:

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

In the Linux kernel, the following vulnerability has been resolved:

kernel/fork: clear PFBLOCKTS in copyprocess()

PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.

Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.

In the Linux kernel, the following vulnerability has been resolved:

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

drivers/base/memory: set mem->altmap after successful device registration

In the Linux kernel, the following vulnerability has been resolved:

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]

In the Linux kernel, the following vulnerability has been resolved:

tty: serial: pchuart: add check for dmaalloccoherent()

Add a check for dmaalloccoherent() failure to prevent a potential NULL pointer dereference in dmahandlerx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: hold opts->lock across XU walks in uvcfunctionbind

uvcfunctionbind() walks &opts->extensionunits twice without holding opts->lock:

- directly, for the iExtension string-descriptor fixup loop; - indirectly, four times via uvccopydescriptors() (once per speed), where the helper iterates uvc->desc.extensionunits (which aliases &opts->extensionunits) to size and emit XU descriptors.

The configfs side (uvcgextensionmake / uvcgextensiondrop, in drivers/usb/gadget/function/uvcconfigfs.c) takes opts->lock around its listaddtail / listdel operations. A privileged userspace process that holds the configfs subtree open and writes the gadget UDC name to bind the function while concurrently rmdir()'ing an extensions subdir can race uvcgextensiondrop() against the bind-time list walks and dereference a freed struct uvcgextension.

Hold opts->lock from the start of the XU string-descriptor fixup through the last uvccopydescriptors() call, releasing on the descriptor-error path via a new errorunlock label that drops the lock before falling through to the existing error label. This matches the locking discipline of the configfs callbacks and removes the only remaining unsynchronised reader of the XU list during bind.

Reachability: only privileged processes that can mount configfs and write to gadget UDC files can trigger the race, so this is a correctness fix rather than a security boundary.

In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dsi: don't dump registers past the mapped region

On DSI 6G platforms the IO address space is internally adjusted by iooffset. Later this adjusted address might be used for memory dumping. However the size that is used for memory dumping isn't adjusted to account for the iooffset, leading to the potential access to the unmapped region. Lower ctrlsize by the iooffset value to prevent access past the mapped area.

msmdispsnapshotaddblock+0x1d4/0x3c8 [msm] (P) msmdsihostsnapshot+0x4c/0x78 [msm] msmdsisnapshot+0x28/0x50 [msm] msmdispsnapshotcapturestate+0x74/0x140 [msm] msmdispsnapshotstatesync+0x60/0x90 [msm] msmdispsnapshotwork+0x30/0x90 [msm] kthreadworkerfn+0xdc/0x460 kthread+0x120/0x140

Patchwork: https://patchwork.freedesktop.org/patch/721747/

In the Linux kernel, the following vulnerability has been resolved:

ACPI: driver: Check ACPICOMPANION() against NULL during probe

Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of devicematchdriveroverride(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence.

Accordingly, add requisite ACPICOMPANION() or ACPIHANDLE() checks against NULL to 13 platform drivers handling core ACPI devices.

Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers.

In the Linux kernel, the following vulnerability has been resolved:

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

In the Linux kernel, the following vulnerability has been resolved:

powerpc/time: Remove redundant preemptdisable|enable() calls from archirqworkraise()

A kernel panic is observed when handling machine check exceptions from real mode.

BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] archirqworkraise+0x10/0x70 LR [c00000000003ffc8] machinecheckqueueevent+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machinecheckqueueevent+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machinecheckearlycommon+0x1f0/0x2c0

The crash occurs because archirqworkraise() calls preemptdisable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preemptcount can fault, leading to the panic.

The preemptdisable()/preemptenable() pair in archirqworkraise() was originally added by commit 0fe1ac48bef0 ("powerpc/perfevent: Fix oops due to perfeventdopending call") to avoid races while raising irq work from exception context.

Later, commit 471ba0e686cb ("irqwork: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irqworkqueue() path, while commit 20b876918c06 ("irqwork: Use per cpu atomics instead of regular atomics") added equivalent protection in irqworkqueueon() before reaching archirqworkraise():

irqworkqueue() / irqworkqueueon() -> preemptdisable() -> irqworkqueuelocal() -> irqworkraise() -> archirqworkraise()

As a result, callers other than mceirqworkraise() already execute with preemption disabled, making the additional preemptdisable()/preemptenable() pair in archirqworkraise() redundant.

The archirqworkraise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preemptdisable()/preemptenable() calls from here.

Remove it to avoid accessing preemptcount from real mode context.

[Maddy: Fixed the commit title]

i2c: i801: fix hardware state machine corruption in error path

In the Linux kernel, the following vulnerability has been resolved:

xfs: fail recovery on a committed log item with no regions

If the first op of a transaction is a bare transaction header (len == sizeof(struct xfstransheader)), xlogrecoveraddtotrans() adds an item but no region, leaving it on ritemq with ricnt == 0 and ribuf == NULL.

The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.

xlogrecoverreordertrans() calls ITEMTYPE() on the item, which reads (unsigned short )item->ribuf[0].iovbase and faults on the NULL ribuf. Reject it there, before the commit handlers that also read ribuf[0].

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlogrecoverreordertrans (fs/xfs/xfslogrecover.c:1836) xlogrecovercommittrans (fs/xfs/xfslogrecover.c:2043) xlogrecoverprocessdata (fs/xfs/xfslogrecover.c:2501) xlogdorecoverypass (fs/xfs/xfslogrecover.c:3244) xlogrecover (fs/xfs/xfslogrecover.c:3493) xfslogmount (fs/xfs/xfslog.c:618) xfsmountfs (fs/xfs/xfsmount.c:1034) xfsfsfillsuper (fs/xfs/xfssuper.c:1938) vfsgettree (fs/super.c:1695) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367)

In the Linux kernel, the following vulnerability has been resolved:

sysfs: don't remove existing directory on update failure

When sysfsupdategroup() is called for a named group and createfiles() fails (e.g. -ENOMEM), internalcreategroup() calls kernfsremove(kn) on the group directory. In the update path, kn was obtained via kernfsfindandget() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create.

Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by removefiles() inside createfiles(), but can be repopulated by a retry.

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs-schemes: call missing memcgroupiterbreak()

damonsysfsmemcgpathtoid() breaks memcgroupiter() loop without calling memcgroupiterbreak(). This leaks the cgroup reference. Fix the issue by calling memcgroupiterbreak() before the break.

The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved:

drivers/base/memory: fix memory block reference leak in poison accounting

memblknrpoisoninc() and memblknrpoisonsub() look up a memory block via findmemoryblockbyid(), which acquires a reference to the memory block device.

Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nrhwpoison.

In the Linux kernel, the following vulnerability has been resolved:

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

In the Linux kernel, the following vulnerability has been resolved:

mm/memoryhotplug: fix memory block reference leak on remove

Patch series "mm: Fix memory block leaks and locking", v2.

This series fixes two memory block device reference leaks and one locking issue around the per-memoryblock hwpoison counter.

This patch (of 2):

removememoryblocksandaltmaps() looks up each memory block with findmemoryblock(), which acquires a reference to the memory block device.

That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.

In the Linux kernel, the following vulnerability has been resolved:

net: wwan: iosm: fix potential memory leaks in ipcimeminit()

The memory allocated in ipcprotocolinit() is not freed on the error paths that follow in ipcimeminit(). Fix that by calling the corresponding release function ipcprotocoldeinit() in the error path.

In the Linux kernel, the following vulnerability has been resolved:

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR

In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: advance loop vars in cfg80211mergeprofile()

cfg80211mergeprofile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls

cfg80211getprofilecontinuation(ie, ielen, mbssidelem, subelem)

but never advances mbssidelem or subelem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same nextmbssid; and the same nextsub bytes are memcpy()'d into mergedie at a growing offset until the buffer fills.

Advance both mbssidelem and subelem to the just-consumed continuation so the next call to cfg80211getprofilecontinuation() searches for a further continuation beyond it (or returns NULL when none exists).

A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211mergeprofile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.

In the Linux kernel, the following vulnerability has been resolved:

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

In the Linux kernel, the following vulnerability has been resolved:

spi: ep93xx: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

In the Linux kernel, the following vulnerability has been resolved:

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

In the Linux kernel, the following vulnerability has been resolved:

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.