OESA-2025-2885

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001chipsetdevstatereq(), pm8001chipfwflashupdatereq(),pm80xxchipphyctlreq() and pm8001chipregdevreq() add missing callsto pm8001tagfree() to free the allocated tag when pm8001mpibuildcmd()fails.Similarly, in pm8001execinternaltaskabort(), if the chip ->taskabortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001tagfree().(CVE-2022-49121)

In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fcremoteportdelete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: <IRQ>kernel: dumpstack+0x66/0x81kernel: _schedulebug.cold.90+0x5/0x1dkernel: _schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: scheduletimeout+0x26d/0x3b0kernel: waitforcompletion+0xb4/0x140kernel: ? wakeupq+0x70/0x70kernel: _waitrcugp+0x12c/0x160kernel: ? sdevevtalloc+0xc0/0x180 [scsimod]kernel: synchronizesched+0x6c/0x80kernel: ? callrcubh+0x20/0x20kernel: ? _bpftracercuinvokecallback+0x10/0x10kernel: sdevevtalloc+0xfd/0x180 [scsimod]kernel: stargetforeachdevice+0x85/0xb0 [scsimod]kernel: ? scsiinitio+0x360/0x3d0 [scsimod]kernel: scsiinitio+0x388/0x3d0 [scsimod]kernel: deviceforeachchild+0x54/0x90kernel: fcremoteportdelete+0x70/0xe0 [scsitransportfc]kernel: qla2x00schedulerportdel+0x62/0xf0 [qla2xxx]kernel: qla2x00markdevicelost+0x9c/0xd0 [qla2xxx]kernel: qla24xxhandleplogidoneevent+0x55f/0x570 [qla2xxx]kernel: qla2x00asyncloginspdone+0xd2/0x100 [qla2xxx]kernel: qla24xxlogioentry+0x13a/0x3c0 [qla2xxx]kernel: qla24xxprocessresponsequeue+0x306/0x400 [qla2xxx]kernel: qla24xxmsixrspq+0x3f/0xb0 [qla2xxx]kernel: _handleirqeventpercpu+0x40/0x180kernel: handleirqeventpercpu+0x30/0x80kernel: handleirqevent+0x36/0x60(CVE-2022-49156)

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

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inlinedots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/showbug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfoliomarkdirty+0x33/0x50f2fsaddregularentry+0x541/0xad0 [f2fs]f2fsadddentry+0x6c/0xb0 [f2fs]f2fsdoaddlink+0x182/0x230 [f2fs]recoverdotdentries+0x2d6/0x470 [f2fs]f2fslookup+0x5af/0x6a0 [f2fs]lookupslow+0xac/0x200lookupslow+0x45/0x70walkcomponent+0x16c/0x250pathlookupat+0x8b/0x1f0filenamelookup+0xef/0x250userpathatempty+0x46/0x70vfsstatx+0x98/0x190dosysnewlstat+0x41/0x90x64sysnewlstat+0x1a/0x30dosyscall64+0x37/0xb0entrySYSCALL64afterhwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping->aops field, so, in a fuzzed image, if inlinedots flag wastagged in special file, during lookup(), when f2fs runs into_recoverdotdentries(), it will cause NULL pointer access oncef2fsaddregularentry() calls aops->setdirty_page().(CVE-2022-49428)

In the Linux kernel, the following vulnerability has been resolved:arm64: compat: Do not treat syscall number as ESRELx for a bad syscallIf a compat process tries to execute an unknown system call above theARMNRCOMPATEND number, the kernel sends a SIGILL signal to theoffending process. Information about the error is printed to dmesg incompatarmsyscall() -> arm64notifydie() -> arm64forcesigfault() ->arm64showsignal().arm64showsignal() interprets a non-zero value forcurrent->thread.faultcode as an exception syndrome and displays themessage associated with the ESRELx.EC field (bits 31:26).current->thread.faultcode is set in compatarmsyscall() ->arm64notifydie() with the bad syscall number instead of a valid ESRELxvalue. This means that the ESRELx.EC field has the value that the user setfor the syscall number and the kernel can end up printing bogus exceptionmessages. For example, for the syscall number 0x68000000, which evaluatesto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000][ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79[ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which is misleading, as the bad compat syscall has nothing to do withpointer authentication.Stop arm64_show_signal() from printing exception syndrome information byhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has nomeaning for an invalid system call number. The example above now becomes:[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000][ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80[ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which although shows less information because the syscall number,wrongfully advertised as the ESR value, is missing, it is better thanshowing plainly wrong information. The syscall number can be easilyobtained with strace.A 32-bit value above or equal to 0x80000000 is interpreted as a negativeinteger in compatarmsyscal() and the condition scno < _ARMNRCOMPATENDevaluates to true; the syscall will exit to userspace in this case with theENOSYS error code instead of arm64notify_die() being called.(CVE-2022-49520)

In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctltcpprobethreshold.While reading sysctltcpprobethreshold, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.(CVE-2022-49595)

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

mmc: core: Fix kernel panic when remove non-standard SDIO card

SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdioinitfunc(), but all SDIO card device reference counter gets decreased at sdioreleasefunc().(CVE-2022-50640)

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

scsi: qla2xxx: Perform lockless command completion in abort path

While adding and removing the controller, the following call trace was observed:

WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dmafreeattrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x8664 #1 RIP: 0010:dmafree_attrs+0x33/0x50

Call Trace: qla2x00asyncsnsspdone+0x107/0x1b0 [qla2xxx] qla2x00abortsrb+0x8e/0x250 [qla2xxx] ? qldbg+0x70/0x100 [qla2xxx] _qla2x00abortallcmds+0x108/0x190 [qla2xxx] qla2x00abortallcmds+0x24/0x70 [qla2xxx] qla2x00abortispcleanup+0x305/0x3e0 [qla2xxx] qla2x00removeone+0x364/0x400 [qla2xxx] pcideviceremove+0x36/0xa0 _devicereleasedriver+0x17a/0x230 devicereleasedriver+0x24/0x30 pcistopbusdevice+0x68/0x90 pcistopandremovebusdevicelocked+0x16/0x30 removestore+0x75/0x90 kernfsfopwriteiter+0x11c/0x1b0 newsyncwrite+0x11f/0x1b0 vfswrite+0x1eb/0x280 ksyswrite+0x5f/0xe0 dosyscall64+0x5c/0x80 ? douseraddrfault+0x1d8/0x680 ? dosyscall64+0x69/0x80 ? excpagefault+0x62/0x140 ? asmexcpagefault+0x8/0x30 entrySYSCALL64after_hwframe+0x44/0xae

The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held.(CVE-2023-53041)

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

drm/amdgpu: install stub fence into potential unused fence pointers

When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dmafencewait() on them.(CVE-2023-53248)

In the Linux kernel, the following vulnerability has been resolved:virtionet: Fix napiskbcacheput warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapialloccache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napiskbcacheput+0x82/0x4b0 warn+0x12f/0x340 napiskbcacheput+0x82/0x4b0 napiskbcacheput+0x82/0x4b0 reportbug+0x165/0x370 handlebug+0x3d/0x80 excinvalidop+0x1a/0x50 asmexcinvalidop+0x1a/0x20 _freeoldxmit+0x1c8/0x510 napiskbcacheput+0x82/0x4b0 _freeoldxmit+0x1c8/0x510 _freeoldxmit+0x1c8/0x510 _pfxfreeoldxmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnetpolltx() to only set NAPI when budgetis available. Same for virtnetpollcleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow assignment in linkdpctssamplingrate is an uint8t but is assigned an unsigned int, and thus itcan overflow. As a result, samplingrate is changed to uint32t.Similarly, LINKQUALPATTERNSET has a size of 2 bits, and it shouldonly be assigned to a value less or equal than 4.This fixes 2 INTEGEROVERFLOW issues reported by Coverity.(CVE-2024-50016)

In the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn t being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here s a debug log of the indicent:[ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio.[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload[ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[ 12.052207] ieee80211 phy0: il4965macstart enter[ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[ 12.052244] ieee80211 phy0: il4965sethwready hardware ready[ 12.052324] ieee80211 phy0: ilapminit Init card s basic functions[ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S[ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm[ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm[ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK[ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations[ 12.058734] ieee80211 phy0: _il4965up iwl4965 is coming up[ 12.058737] ieee80211 phy0: il4965macstart Start UP work done.[ 12.058757] ieee80211 phy0: _il4965down iwl4965 is going down[ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout[ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort[ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver[ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared[ 12.058819] ieee80211 phy0: _ilapmstop Stop card, put in low power state[ 12.058827] ieee80211 phy0: _ilapmstopmaster stop master[ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear.[ 12.058869] ieee80211 phy0: Hardware restart was requested[ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms.[ 16.132303] ------------[ cut here ]------------[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211][ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[ 16.132463] Workqueue: async asyncrunentryfn[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132501] Code: da 02 00 0---truncated---(CVE-2024-50234)

In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmftxfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmfdetach() brcmfremoveinterface() brcmfdelif()Inside the brcmfdelif() function the drvr->if2bss[ifidx] is updated toBRCMFBSSIDXINVALID (-1) if the bsscfgidx matches.After brcmfremoveinterface() call the brcmfprotodetach() function iscalled providing the following sequence: brcmfdetach() brcmfprotodetach() brcmfprotomsgbufdetach() brcmfflowringdetach() brcmfmsgbufdeleteflowring() brcmfmsgbufremoveflowring() brcmfflowringdelete() brcmfgetifp() brcmftxfinalize()Since brcmfgetip() can and actually will return NULL in this case thecall to brcmftxfinalize() will result in a NULL pointer dereference insidebrcmftxfinalize() when trying to update ifp->ndev->stats.txerrors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)

In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusbhubtostructhub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUGPAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usbhubwq hubeventRIP: 0010:usbhubadjustdeviceremovable+0x78/0x110...Call Trace: <TASK> ? dieaddr+0x31/0x80 ? excgeneralprotection+0x1b4/0x3c0 ? asmexcgeneralprotection+0x26/0x30 ? usbhubadjustdeviceremovable+0x78/0x110 hubprobe+0x7c7/0xab0 usbprobeinterface+0x14b/0x350 reallyprobe+0xd0/0x2d0 ? pfxdeviceattachdriver+0x10/0x10 _driverprobedevice+0x6e/0x110 driverprobedevice+0x1a/0x90 _deviceattachdriver+0x7e/0xc0 busforeachdrv+0x7f/0xd0 _deviceattach+0xaa/0x1a0 busprobedevice+0x8b/0xa0 deviceadd+0x62e/0x810 usbsetconfiguration+0x65d/0x990 usbgenericdriverprobe+0x4b/0x70 usbprobedevice+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusbhubtostructhub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.(CVE-2025-21776)

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

pinctrl: qcom: msm: mark certain pins as invalid for interrupts

On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: gpiomon -c 0 113 on RB2.

The exact culprit is requesting pins whose intrdetectionwidth setting is not 1 or 2 for interrupts. This hits a BUG() in msmgpioirqsettype(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs.

This function can be extended if we determine that there are more corner-cases like this.(CVE-2025-38516)