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

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:

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:

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:

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:

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:

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.

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

USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor

Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpointisduplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).

To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usbparseendpoint() and use the copy instead of the original when checking for duplicates.

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

usb: atm: cxacru: fix endpoint checking in cxacrubind()

Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usbsubmiturb().

Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.

Unfortunately, this patch has not been tested on real hardware.

[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacrucm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacrucardstatus+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacrubind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatmusbprobe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacruusbprobe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usbprobeinterface+0x315/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:517 [inline] reallyprobe+0x23c/0xcd0 drivers/base/dd.c:595 driverprobedevice+0x338/0x4d0 drivers/base/dd.c:747 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:777 deviceattachdriver+0x20b/0x2f0 drivers/base/dd.c:894 busforeachdrv+0x15f/0x1e0 drivers/base/bus.c:427 deviceattach+0x228/0x4a0 drivers/base/dd.c:965 busprobedevice+0x1e4/0x290 drivers/base/bus.c:487 deviceadd+0xc2f/0x2180 drivers/base/core.c:3354 usbsetconfiguration+0x113a/0x1910 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xba/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd9/0x2c0 drivers/usb/core/driver.c:293

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

pinctrl: fix deadlock in createpinctrl() when handling -EPROBEDEFER

In createpinctrl(), pinctrlmapsmutex is acquired before calling addsetting(). If addsetting() returns -EPROBEDEFER, createpinctrl() calls pinctrlfree(). However, pinctrlfree() attempts to acquire pinctrlmapsmutex, which is already held by createpinctrl(), leading to a potential deadlock.

This patch resolves the issue by releasing pinctrlmapsmutex before calling pinctrlfree(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

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

Input: aiptek - properly check endpoint type

Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

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

vtioctl: fix arrayindexnospec in vtsetactivate

arrayindexnospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with arrayindexnospec.

Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam.

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

USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages

The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup:

cdcwdm 1-1:1.0: nonzero urb status received: -71 cdcwdm 1-1:1.0: wdmintcallback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] consoleemitnextrecord kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] consoleflushall+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] el1irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirqhandleend kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handlesoftirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] dosoftirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024

Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time.

In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two deverr() calls. Therefore we replace them with deverrratelimited().

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

wifi: mac80211: Fix deadlock in ieee80211stapsdeliverwakeup()

The ieee80211stapsdeliverwakeup() function takes sta->pslock to synchronizes with ieee80211txhunicastpsbuf() which is called from softirq context. However using only spinlock() to get sta->pslock in ieee80211stapsdeliverwakeup() does not prevent softirq to execute on this same CPU, to run ieee80211txhunicastpsbuf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.

rcu: INFO: rcusched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpasupplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queuedspinlockslowpath+0x58/0x2d0 lr : invoketxhandlersearly+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queuedspinlockslowpath+0x58/0x2d0 ieee80211tx+0x80/0x12c ieee80211txpending+0x110/0x278 taskletactioncommon.constprop.0+0x10c/0x144 taskletaction+0x20/0x28 stext+0x11c/0x284 dosoftirq+0xc/0x14 callonirqstack+0x24/0x34 dosoftirqownstack+0x18/0x20 dosoftirq+0x74/0x7c localbhenableip+0xa0/0xa4 ieee80211waketxqs+0x3b0/0x4b8 ieee80211wakequeue+0x12c/0x168 ieee80211addpendingskbs+0xec/0x138 ieee80211stapsdeliverwakeup+0x2a4/0x480 ieee80211mpsstastatusupdate.part.0+0xd8/0x11c ieee80211mpsstastatusupdate+0x18/0x24 staapplyparameters+0x3bc/0x4c0 ieee80211changestation+0x1b8/0x2dc nl80211setstation+0x444/0x49c genlfamilyrcvmsgdoit.isra.0+0xa4/0xfc genlrcvmsg+0x1b0/0x244 netlinkrcvskb+0x38/0x10c genlrcv+0x34/0x48 netlinkunicast+0x254/0x2bc netlinksendmsg+0x190/0x3b4 syssendmsg+0x1e8/0x218 syssendmsg+0x68/0x8c syssendmsg+0x44/0x84 arm64syssendmsg+0x20/0x28 doel0svc+0x6c/0xe8 el0svc+0x14/0x48 el0t64synchandler+0xb0/0xb4 el0t64sync+0x14c/0x150

Using spinlockbh()/spinunlockbh() instead prevents softirq to raise on the same CPU that is holding the lock.

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

liquidio: Adjust a NULL pointer handling path in liovfrepcopypacket

In liovfrepcopypacket() pginfo->page is compared to a NULL value, but then it is unconditionally passed to skbaddrxfrag() which looks strange and could lead to null pointer dereference.

liovfrepcopypacket() call trace looks like: octeondroqprocesspackets octeondroqfastprocesspackets octeondroqdispatchpkt octeoncreaterecvinfo ...search in the dispatchlist... ->dispfn(rdisp->rinfo, ...) liovfreppktrecv(struct octeonrecvinfo recvinfo, ...) In this path there is no code which sets pginfo->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidiopushpacket() in liquidio/liocore.c does exactly the same.

Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skbaddrxfrag() into conditional scope.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

mptcp: ensure snduna is properly initialized on connect

This is strictly related to commit fb7a0d334894 ("mptcp: ensure sndnxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snduna is still left uninitialized.

Address the issue explicitly initializing snduna together with sndnxt and writeseq.

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

xfrm6: check ip6dstidev() return value in xfrm6getsaddr()

ip6dstidev() can return NULL, xfrm6getsaddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wgpackethandshakesendworker RIP: 0010:xfrm6getsaddr+0x93/0x130 net/ipv6/xfrm6policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrmgetsaddr net/xfrm/xfrmpolicy.c:2452 [inline] xfrmtmplresolveone net/xfrm/xfrmpolicy.c:2481 [inline] xfrmtmplresolve+0xa26/0xf10 net/xfrm/xfrmpolicy.c:2541 xfrmresolveandcreatebundle+0x140/0x2570 net/xfrm/xfrmpolicy.c:2835 xfrmbundlelookup net/xfrm/xfrmpolicy.c:3070 [inline] xfrmlookupwithifid+0x4d1/0x1e60 net/xfrm/xfrmpolicy.c:3201 xfrmlookup net/xfrm/xfrmpolicy.c:3298 [inline] xfrmlookuproute+0x3b/0x200 net/xfrm/xfrmpolicy.c:3309 ip6dstlookupflow+0x15c/0x1d0 net/ipv6/ip6output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wgsocketsendskbtopeer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wgsocketsendbuffertopeer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wgpacketsendhandshakeinitiation+0x227/0x360 drivers/net/wireguard/send.c:40 wgpackethandshakesendworker+0x1c/0x30 drivers/net/wireguard/send.c:51 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

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

drm/radeon: fix UBSAN warning in kvdpm.c

Adds bounds check for sumovidmappingentry.

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

ext4: do not create EA inode under buffer lock

ext4xattrsetentry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4xattrsetentry() into the callers.

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

wifi: mt76: mt7921s: fix potential hung tasks during chip recovery

During chip recovery (e.g. chip reset), there is a possible situation that kernel worker resetwork is holding the lock and waiting for kernel thread statworker to be parked, while statworker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device.

This patch prevents the execution of statworker during the chip recovery.