IBM Security Verify Governance 10.0.2 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

Versions of the package markdown-to-jsx before 7.4.0 are vulnerable to Cross-site Scripting (XSS) via the src property due to improper input sanitization. An attacker can execute arbitrary code by injecting a malicious iframe element in the markdown.

devres: Fix memory leakage caused by driver API devmfreepercpu()

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

protect the fetch of ->fd[fd] in dodup2() from mispredictions

both callers have verified that fd is not greater than ->maxfds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in closefd()/fileclosefdlocked(); the same solution applies - arrayindexnospec(fd, fdt->maxfds) could differ from fd only in case of speculative execution on mispredicted path.

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

net, sunrpc: Remap EPERM in case of connection failure in xstcpsetupsocket

When using a BPF program on kernelconnect(), the call can return -EPERM. This causes xstcpsetupsocket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.

Neil suggested:

This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.

ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPFPROGRUNARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xsudpsendrequest().

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

x86/bhi: Avoid warning in #DB handler due to BHI mitigation

When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entrySYSENTERcompat() uses CLEARBRANCHHISTORY and calls the clearbhbloop() before the TF flag is cleared. This causes the #DB handler (excdebugkernel()) to issue a warning because single-step is used outside the entrySYSENTERcompat() function.

To address this issue, entrySYSENTERcompat() should use CLEARBRANCHHISTORY after making sure the TF flag is cleared.

The problem can be reproduced with the following sequence:

$ cat sysenterstep.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }

$ gcc -o sysenterstep sysenterstep.c

$ ./sysenterstep Segmentation fault (core dumped)

The program is expected to crash, and the #DB handler will issue a warning.

Kernel log:

WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 excdebugkernel+0xd2/0x160 ... RIP: 0010:excdebugkernel+0xd2/0x160 ... Call Trace: <#DB> ? showregs+0x68/0x80 ? warn+0x8c/0x140 ? excdebugkernel+0xd2/0x160 ? reportbug+0x175/0x1a0 ? handlebug+0x44/0x90 ? excinvalidop+0x1c/0x70 ? asmexcinvalidop+0x1f/0x30 ? excdebugkernel+0xd2/0x160 excdebug+0x43/0x50 asmexcdebug+0x1e/0x40 RIP: 0010:clearbhbloop+0x0/0xb0 ... </#DB> <TASK> ? entrySYSENTERcompatafterhwframe+0x6e/0x8d </TASK>

[ bp: Massage commit message. ]

firmware: csdsp: Return error if block header overflows file

firmware: csdsp: Validate payload length before processing block

drm/amdgpu: Using uninitialized value size when calling amdgpuvcecsreloc

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

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty limits in PAGESIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirtybytes / dirtybackgroundbytes interfaces we can just refuse to set so large limits. For dirtyratio / dirtybackgroundratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINTMAX.

This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.

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

wifi: cfg80211: restrict NL80211ATTRTXQQUANTUM values

syzbot is able to trigger softlockups, setting NL80211ATTRTXQQUANTUM to 2^31.

We had a similar issue in schfq, fixed with commit d9e15a273306 ("pktsched: fq: do not accept silly TCAFQQUANTUM")

watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] exittokernelmode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exittokernelmode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] el1irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neighhhinit net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neighresolveoutput+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] localbhdisable+0x10/0x34 include/linux/bottomhalf.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mldifcwork pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : listdel include/linux/list.h:195 [inline] pc : listdelentry include/linux/list.h:218 [inline] pc : listmovetail include/linux/list.h:310 [inline] pc : fqtindequeue include/net/fqimpl.h:112 [inline] pc : ieee80211txdequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : listdelentry include/linux/list.h:218 [inline] lr : listmovetail include/linux/list.h:310 [inline] lr : fqtindequeue include/net/fqimpl.h:112 [inline] lr : ieee80211txdequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: listdel include/linux/list.h:195 [inline] listdelentry include/linux/list.h:218 [inline] listmovetail include/linux/list.h:310 [inline] fqtindequeue include/net/fqimpl.h:112 [inline] ieee80211txdequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 waketxpushqueue net/mac80211/util.c:294 [inline] ieee80211handlewaketxqueue+0x118/0x274 net/mac80211/util.c:315 drvwaketxqueue net/mac80211/driver-ops.h:1350 [inline] scheduleandwaketxq net/mac80211/driver-ops.h:1357 [inline] ieee80211queueskb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211xmit+0x278/0x354 net/mac80211/tx.c:2062 ieee80211subifstartxmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211subifstartxmit+0xe0/0x438 net/mac80211/tx.c:4532 netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x27c/0x938 net/core/dev.c:3547 devqueuexmit+0x1678/0x33fc net/core/dev.c:4341 devqueuexmit include/linux/netdevice.h:3091 [inline] neighresolveoutput+0x558/0x658 net/core/neighbour.c:1563 neighoutput include/net/neighbour.h:542 [inline] ip6fini ---truncated---

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

scsi: qedf: Make qedfexecutetmf() non-preemptible

Stop calling smpprocessorid() from preemptible code in qedfexecutetmf90. This results in BUGON() when running an RT kernel.

[ 659.343280] BUG: using smpprocessorid() in preemptible [00000000] code: sgreset/3646 [ 659.343282] caller is qedfexecutetmf+0x8b/0x360 [qedf]

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmetsqdestroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmetsqdestroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before killandconfirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmetsqdestroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

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

wifi: mt76: replace skbput with skbputzero

Avoid potentially reusing uninitialized data

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

tcpmetrics: validate source addr length

I don't see anything checking that TCPMETRICSATTRSADDRIPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).

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

NFSv4: Fix memory leak in nfs4setsecuritylabel

We leak nfsfattr and nfs4label every time we set a security xattr.

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

wifi: mac80211: Avoid address calculations via out of bounds array indexing

req->nchannels must be set before req->channels[] can be used.

This patch fixes one of the issues encountered in [1].

[ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type 'struct ieee80211channel []' [...] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dumpstacklvl+0x3f/0xc0 [ 83.964274] ubsanhandleoutofbounds+0xec/0x110 [ 83.964278] ieee80211prephwscan+0x2db/0x4b0 [ 83.964281] ieee80211startscan+0x601/0x990 [ 83.964291] nl80211triggerscan+0x874/0x980 [ 83.964295] genlfamilyrcvmsgdoit+0xe8/0x160 [ 83.964298] genlrcvmsg+0x240/0x270 [...]

[1] https://bugzilla.kernel.org/showbug.cgi?id=218810

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

powerpc/pseries: Whitelist dtl slub object for copying to userspace

Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu- results in a BUG() when the config CONFIGHARDENEDUSERCOPY is enabled as shown below.

kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGESIZE=64K MMU=Radix SMP NRCPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dmservicetime sdmod t10pi sg ibmvfc scsitransportfc ibmveth pserieswdt dmmultipath dmmirror dmregionhash dmlog dmmod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopyabort+0x78/0xb0 LR [c0000000005d23d0] usercopyabort+0x74/0xb0 Call Trace: usercopyabort+0x74/0xb0 (unreliable) checkheapobject+0xf8/0x120 checkheapobject+0x218/0x240 checkobjectsize+0x84/0x1a4 dtlfileread+0x17c/0x2c4 fullproxyread+0x8c/0x110 vfsread+0xdc/0x3a0 ksysread+0x84/0x144 systemcallexception+0x124/0x330 systemcallvectoredcommon+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34

Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIGHARDENEDUSERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCHLOGBYTES to whitelist the entire object.

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereportedev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.

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

drm/radeon: check bova->bo is non-NULL before using it

The call to radeonvmclearfreed might clear bova->bo, so we have to check it before dereferencing it.

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

firmware: csdsp: Use strnlen() on name fields in V1 wmfw files

Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.

In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. csdsp should protect against overrunning the array if the NUL terminator is missing.

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

mm: prevent derefencing NULL ptr in pfnsectionvalid()

Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memorysection->usage") changed pfnsectionvalid() to add a READONCE() call around "ms->usage" to fix a race with sectiondeactivate() where ms->usage can be cleared. The READONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.

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

firmware: csdsp: Fix overflow checking of wmfw header

Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer.

The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs

wmfwheader + wmfwadsp1sizes + wmfwfooter

But wmfwadsp1sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfwadsp2sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfwadsp2sizes.

This patch splits the length check into three separate parts. Each of the wmfwheader, wmfwadsp?sizes and wmfwfooter are checked separately before they are used.

firmware: csdsp: Prevent buffer overrun when processing V2 alg headers

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

sched/deadline: Fix taskstruct reference leak

During the execution of the following stress test with linux-rt:

stress-ng --cyclic 30 --timeout 30 --minimize --quiet

kmemleak frequently reported a memory leak concerning the taskstruct:

unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] duptaskstruct+0x30/0x540 [<00000000c5ca0f0b>] copyprocess+0x3d9/0x50e0 [<00000000ced59777>] kernelclone+0xb0/0x770 [<00000000a50befdc>] dosysclone+0xb6/0xf0 [<000000001dbf2008>] dosyscall64+0x5d/0xf0 [<00000000552900ff>] entrySYSCALL64afterhwframe+0x6e/0x76

The issue occurs in startdltimer(), which increments the taskstruct reference count and sets a timer. The timer callback, dltasktimer, is supposed to decrement the reference count upon expiration. However, if enqueuetaskdl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak.

This patch fixes the reference leak by ensuring the taskstruct reference count is properly decremented when the timer is canceled.

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

xfs: add bounds checking to xlogrecoverprocessdata

There is a lack of verification of the space occupied by fixed members of xlogopheader in the xlogrecoverprocessdata.

We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tailblk and headblk are the same, which will result in the inability to enter xlogrecoverprocessdata 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlogopheader entries only 1 byte away from xlogrecheader->hsize 5) xlogrecheader->hnumlogops++ 6) Modify xlogrecheader->hcrc

Fix: Add a check to make sure there is sufficient space to access fixed members of xlogopheader.

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

xfs: don't walk off the end of a directory data block

This adds sanity checks for xfsdir2dataunused and xfsdir2dataentry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfsdir2dataunused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members.

In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfsdir2dataunused and xfsdir2dataunused is XFSDIR2DATAALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfsdir2dataentry.

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

net/sched: Fix UAF when resolving a clash

KASAN reports the following UAF:

BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469

Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491 irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommoninterrupt+0x27/0x40

Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491

Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 kasanslabfree+0x180/0x1f0 kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491

The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocessconn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.

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

ppp: reject claimed-as-LCP but actually malformed packets

Since 'pppasyncencode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'pppcheckpacket()' to ensure that LCP packet has an actual body beyond PPPLCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.