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

ELF: fix kernel.randomizevaspace double read

ELF loader uses "randomizevaspace" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.

Issue exactly one load for consistent value across one exec.

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

netfilter: flowtable: initialise extack before use

Fix missing initialisation of extack in flow offload.

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

bonding: fix null pointer deref in bondipsecoffloadok

We must check if there is an active slave before dereferencing the pointer.

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

bonding: fix xfrm realdev null pointer dereference

We shouldn't set realdev to NULL because packets can be in transit and xfrm might call xdodevoffloadok() in parallel. All callbacks assume realdev is set.

Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: errorcode(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? die+0x1f/0x60 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? pagefaultoops+0x142/0x4c0 kernel: ? douseraddrfault+0x65/0x670 kernel: ? kvmreadandresetapfflags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? excpagefault+0x7b/0x180 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? nsimbpfuninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bondipsecoffloadok+0x7b/0x90 [bonding] kernel: xfrmoutput+0x61/0x3b0 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ippushpendingframes+0x56/0x80

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

sctp: Fix null-ptr-deref in reuseportaddsock().

syzbot reported a null-ptr-deref while accessing sk2->skreuseportcb in reuseportaddsock(). [0]

The repro first creates a listener with SOREUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.

The second listen() calls reuseportaddsock() with the first listener as sk2, where sk2->skreuseportcb is not expected to be cleared concurrently, but the close() does clear it by reuseportdetachsock().

The problem is SCTP does not properly synchronise reuseportalloc(), reuseportaddsock(), and reuseportdetachsock().

The caller of reuseportalloc() and reuseport{add,detach}sock() must provide synchronisation for sockets that are classified into the same reuseport group.

Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.

1. Two sockets call listen() concurrently 2. No socket in the same group found in sctpephashtable[] 3. Two sockets call reuseportalloc() and form two reuseport groups 4. Only one group hit first in sctprcvlookupendpoint() receives incoming packets

Also, the reported null-ptr-deref could occur.

TCP/UDP guarantees that would not happen by holding the hash bucket lock.

Let's apply the locking strategy to sctphashendpoint() and sctpunhashendpoint().

[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseportaddsock+0x27e/0x5e0 net/core/sockreuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sctphashendpoint net/sctp/input.c:762 [inline] sctphashendpoint+0x52a/0x600 net/sctp/input.c:790 sctplistenstart net/sctp/socket.c:8570 [inline] sctpinetlisten+0x767/0xa20 net/sctp/socket.c:8625 syslistensocket net/socket.c:1883 [inline] syslisten+0x1b7/0x230 net/socket.c:1894 dosyslisten net/socket.c:1902 [inline] sesyslisten net/socket.c:1900 [inline] x64syslisten+0x5a/0x70 net/socket.c:1900 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIGRAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---

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

padata: Fix possible divide-by-0 panic in padatamthelper()

We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.

[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x8664 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: eventsunbound padatamthelper [ 10.017908] RIP: 0010:padatamthelper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] [ 10.018004] ? padatamthelper+0x39/0xb0 [ 10.018084] processonework+0x174/0x330 [ 10.018093] workerthread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] retfromfork+0x31/0x50 [ 10.018138] retfromforkasm+0x1a/0x30 [ 10.018147]

Looking at the padatamthelper() function, the only way a divide-by-0 panic can happen is when ps->chunksize is 0. The way that chunksize is initialized in padatadomultithreaded(), chunksize can be 0 when the minchunk in the passed-in padatamtjob structure is 0.

Fix this divide-by-0 panic by making sure that chunksize will be at least 1 no matter what the input parameters are.

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

block: initialize integrity buffer to zero before writing it to media

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:

USB: serial: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.

Fix this by implementing dedicated suspend and resume functions for mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

[ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usbkillurb() ]

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).

gfs2: Fix NULL pointer dereference in gfs2logflush

drm/amdgpu: avoid using null object of framebuffer

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:

netfilter: nftables: fully validate NFTDATAVALUE on store to data registers

register store validation for NFTDATAVALUE is conditional, however, the datatype is always either NFTDATAVALUE or NFTDATAVERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.

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