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

wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon

This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/

When a channel-switch announcement (CSA) beacon is received, cfg80211 queues a wiphy work item that eventually calls mt7921channelswitchrxbeacon(). If the station disconnects (or the channel context is otherwise torn down) between the time the work is queued and the time it runs, the driver's dev->newctx pointer can already have been cleared to NULL. mt7921channelswitchrxbeacon() then dereferences newctx unconditionally, triggering a NULL pointer dereference at address 0x0:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt7921channelswitchrxbeacon+0x1f/0x100 [mt7921common]

The same missing guard exists in mt7925channelswitchrxbeacon(), which shares the same code pattern introduced by the same commit.

Add an early-return NULL check for dev->newctx in both mt7921channelswitchrxbeacon() and mt7925channelswitchrxbeacon(). When newctx is NULL there is no pending channel switch to process, so returning immediately is the correct and safe action.

Oops-Analysis: http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

netfilter: xtables: allocate hook ops while under mutex

arp/ip(6)tregistertable() add the table to the per-netns list via xtregistertable() before allocating the per-netns hook ops copy via kmemduparray(). This leaves a window where the table is visible in the list with ops=NULL.

If the pernet exit happens runs concurrently the preexit callback finds the table via xtfindtable() and passes the NULL ops pointer to nfunregisternethooks(), causing a NULL dereference:

general protection fault in nfunregisternethooks+0xbc/0x150 RIP: nfunregisternethooks (net/netfilter/core.c:613) Call Trace: iptunregistertablepreexit iptablemanglenetpreexit opspreexitlist cleanupnet

Fix by moving the ops allocation into the xtables core so the table is never in the list without valid ops. Also ensure the table is no longer processing packets before its torn down on error unwind. nfregisternethooks might have published at least one hook; call synchronizercu() if there was an error.

audit log register message gets deferred until all operations have passed, this avoids need to emit another ureg message in case of error unwinding.

Based on earlier patch by Tristan Madani.

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

power: supply: max77705: Free allocated workqueue and fix removal order

Use devm interface for allocating workqueue to fix two bugs at the same time:

1. Driver leaks the memory on remove(), because the workqueue is not destroyed.

2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt.

The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory.

Change is not equivalent in the workqueue itself: use non-legacy API which does not set (WQLEGACY | WQMEMRECLAIM). The workqueue is used to update power supply (powersupplychanged()) status, thus there is no point to run it for memory reclaim. Note that devname() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format.

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

net: phonet: do not BUGON() in pnsocketautobind() on failed bind

syzbot reported a kernel BUG triggered from pnsocketsendmsg() via pnsocketautobind():

kernel BUG at net/phonet/socket.c:213! RIP: 0010:pnsocketautobind net/phonet/socket.c:213 [inline] RIP: 0010:pnsocketsendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: socksendmsgnosec+0x112/0x150 net/socket.c:797 socksendmsg net/socket.c:812 [inline] syssendto+0x402/0x590 net/socket.c:2280 ...

pnsocketautobind() calls pnsocketbind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero:

err = pnsocketbind(sock, ..., sizeof(struct sockaddrpn)); if (err != -EINVAL) return err; BUGON(!pnport(pnsk(sock->sk)->sobject)); return 0; / socket was already bound /

However pnsocketbind() also returns -EINVAL when sk->skstate is not TCPCLOSE, even when the socket has never been bound and pnport() is still 0. In that case the BUGON() fires and panics the kernel from a user-triggerable path.

Treat the "bind returned -EINVAL but pnport() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pnsocketautobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.

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

drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED

[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.

The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(ininterrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.

[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.

(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

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

nbd: restrict sockets to TCP and UDP

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup") made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.

cgroup: split cgroupdestroywq into 3 workqueues

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

bonding: check xdp prog when set bond mode

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

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

x86/amdnb: Use rdmsrsafe() in amdgetmmconfigrange()

Xen doesn't offer MSRFAM10HMMIOCONFBASE to all guests. This results in the following warning:

unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xendoreadmsr+0x7f/0xa0) Call Trace: xenreadmsr+0x1e/0x30 amdgetmmconfigrange+0x2b/0x80 quirkamdmmconfigarea+0x28/0x100 pnpfixupdevice+0x39/0x50 pnpadddevice+0xf/0x150 pnpadddevice+0x3d/0x100 pnpacpiadddevicehandler+0x1f9/0x280 acpinsgetdevicecallback+0x104/0x1c0 acpinswalknamespace+0x1d0/0x260 acpigetdevices+0x8a/0xb0 pnpacpiinit+0x50/0x80 dooneinitcall+0x46/0x2e0 kernelinitfreeable+0x1da/0x2f0 kernelinit+0x16/0x1b0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30

based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.

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

USB: gadget: fmidi: fmidicomplete to call queuework

When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to fmiditransmit, causing a deadlock.

Fix it by using queuework() to schedule the inner fmiditransmit() via a high priority work queue from the completion handler.

dropmonitor: fix incorrect initialization order

bpf: avoid holding freezemutex during mmap operation

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the aedev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.

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

net: let net.core.devweight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? warn+0xcd/0x250 ? listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 syssendto+0x3bf/0x4e0 x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.devweight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueuetobacklog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).

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

KVM: x86: Reject Hyper-V's SENDIPI hypercalls if local APIC isn't in-kernel

Advertise support for Hyper-V's SENDIPI and SENDIPIEX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVMCAPHYPERVENFORCECPUID.

Rejecting SENDIPI and SENDIPIEX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:

dumpstack+0xbe/0xfd kasanreport.cold+0x34/0x84 kasanreport+0x3a/0x50 apicacceptirq+0x3a/0x5c0 kvmhvsendipi.isra.0+0x34e/0x820 kvmhvhypercall+0x8d9/0x9d0 kvmemulatehypercall+0x506/0x7e0 vmxhandleexit+0x283/0xb60 vmxhandleexit+0x1d/0xd0 vcpuenterguest+0x16b0/0x24c0 vcpurun+0xc0/0x550 kvmarchvcpuioctlrun+0x170/0x6d0 kvmvcpuioctl+0x413/0xb20 sesysioctl+0x111/0x160 dosyscal164+0x30/0x40 entrySYSCALL64afterhwframe+0x67/0xd1

Note, checking the sending vCPU is sufficient, as the per-VM irqchipmode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.

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

vxlan: check vxlanvnigroupinit() return value

vxlaninit() must check vxlanvnigroupinit() success otherwise a crash happens later, spotted by syzbot.

Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlanvnigroupuninit+0x89/0x500 drivers/net/vxlan/vxlanvnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlanuninit+0x1ab/0x200 drivers/net/vxlan/vxlancore.c:2942 unregisternetdevicemanynotify+0x12d6/0x1f30 net/core/dev.c:11824 unregisternetdevicemany net/core/dev.c:11866 [inline] unregisternetdevicequeue+0x307/0x3f0 net/core/dev.c:11736 registernetdevice+0x1829/0x1eb0 net/core/dev.c:10901 vxlandevcreate+0x7c6/0xa30 drivers/net/vxlan/vxlancore.c:3981 vxlannewlink+0xd1/0x130 drivers/net/vxlan/vxlancore.c:4407 rtnlnewlinkcreate net/core/rtnetlink.c:3795 [inline] rtnlnewlink net/core/rtnetlink.c:3906 [inline]

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 NULL pointer dereference occurs.

The following sequence deletes the interface:

brcmfdetach() brcmfremoveinterface() brcmfdelif()

Inside the brcmfdelif() function the drvr->if2bss[ifidx] is updated to BRCMFBSSIDXINVALID (-1) if the bsscfgidx matches.

After brcmfremoveinterface() call the brcmfprotodetach() function is called providing the following sequence:

brcmfdetach() brcmfprotodetach() brcmfprotomsgbufdetach() brcmfflowringdetach() brcmfmsgbufdeleteflowring() brcmfmsgbufremoveflowring() brcmfflowringdelete() brcmfgetifp() brcmftxfinalize()

Since brcmfgetip() can and actually will return NULL in this case the call to brcmftxfinalize() will result in a NULL pointer dereference inside brcmftxfinalize() 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 to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL.

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

vxlan: Fix uninit-value in vxlanvnifilterdump()

KMSAN reported an uninit-value access in vxlanvnifilterdump() [1].

If the length of the netlink message payload is less than sizeof(struct tunnelmsg), vxlanvnifilterdump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations.

[1] BUG: KMSAN: uninit-value in vxlanvnifilterdump+0x328/0x920 drivers/net/vxlan/vxlanvnifilter.c:422 vxlanvnifilterdump+0x328/0x920 drivers/net/vxlan/vxlanvnifilter.c:422 rtnldumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlinkdump+0x93e/0x15f0 net/netlink/afnetlink.c:2317 netlinkdumpstart+0x716/0xd60 net/netlink/afnetlink.c:2432 netlinkdumpstart include/linux/netlink.h:340 [inline] rtnetlinkdumpstart net/core/rtnetlink.c:6815 [inline] rtnetlinkrcvmsg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlinkrcvskb+0x467/0x660 net/netlink/afnetlink.c:2542 rtnetlinkrcv+0x35/0x40 net/core/rtnetlink.c:6944 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0xed6/0x1290 net/netlink/afnetlink.c:1347 netlinksendmsg+0x1092/0x1230 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x330/0x3d0 net/socket.c:726 syssendmsg+0x7f4/0xb50 net/socket.c:2583 syssendmsg+0x271/0x3b0 net/socket.c:2637 syssendmsg net/socket.c:2669 [inline] dosyssendmsg net/socket.c:2674 [inline] sesyssendmsg net/socket.c:2672 [inline] x64syssendmsg+0x211/0x3e0 net/socket.c:2672 x64syscall+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4110 [inline] slaballocnode mm/slub.c:4153 [inline] kmemcacheallocnodenoprof+0x800/0xe80 mm/slub.c:4205 kmallocreserve+0x13b/0x4b0 net/core/skbuff.c:587 allocskb+0x347/0x7d0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1323 [inline] netlinkalloclargeskb+0xa5/0x280 net/netlink/afnetlink.c:1196 netlinksendmsg+0xac9/0x1230 net/netlink/afnetlink.c:1866 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x330/0x3d0 net/socket.c:726 syssendmsg+0x7f4/0xb50 net/socket.c:2583 syssendmsg+0x271/0x3b0 net/socket.c:2637 syssendmsg net/socket.c:2669 [inline] dosyssendmsg net/socket.c:2674 [inline] sesyssendmsg net/socket.c:2672 [inline] x64syssendmsg+0x211/0x3e0 net/socket.c:2672 x64syscall+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

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

tomoyo: don't emit warning in tomoyowritecontrol()

syzbot is reporting too large allocation warning at tomoyowritecontrol(), for one can write a very very long line without new line character. To fix this warning, I use GFPNOWARN rather than checking for KMALLOCMAXSIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOCMAXSIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOCMAXSIZE.

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

team: prevent adding a device which is already a team device lower

Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.

This is not useful in practice and can lead to recursive locking:

$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0

============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973)

but task is already holding lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamaddslave (drivers/net/team/teamcore.c:1147 drivers/net/team/teamcore.c:1977)

other info that might help us debug this: Possible unsafe locking scenario:

CPU0 ---- lock(team->teamlockkey); lock(team->teamlockkey);

DEADLOCK

May be due to missing lock nesting notation

2 locks held by ip/7684:

stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:122) printdeadlockbug.cold (kernel/locking/lockdep.c:3040) lockacquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlinkbroadcastfiltered (net/netlink/afnetlink.c:1548) lockacquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? tracelockacquire (./include/trace/events/lock.h:24 (discriminator 2)) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? lockacquire (kernel/locking/lockdep.c:5822) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) mutexlock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? fibsyncup (net/ipv4/fibsemantics.c:2167) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devnotifyflags (net/core/dev.c:8993) ? devchangeflags (net/core/dev.c:8975) devchangeflags (net/core/dev.c:9027) vlandeviceevent (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? brdeviceevent (net/bridge/br.c:143) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devopen (net/core/dev.c:1519 net/core/dev.c:1505) teamaddslave (drivers/net/team/teamcore.c:1219 drivers/net/team/teamcore.c:1977) ? pfxteamaddslave (drivers/net/team/teamcore.c:1972) dosetmaster (net/core/rtnetlink.c:2917) dosetlink.isra.0 (net/core/rtnetlink.c:3117)

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

OPP: fix devpmoppfindbw() when bandwidth table not initialized

If a driver calls devpmoppfindbwceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbwceil+0x50/0x88 ...

In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().

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

remoteproc: core: Fix idafree call while not allocated

In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before idaalloc is called.

In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from warn+0x80/0x12c [ 4.260134] warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc

Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.