In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: Place upper limit on station AID
Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds.
In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash.
This crash was only seen on IFTYPEAP interfaces, and the fix does not appear to have an effect on IFTYPESTATION behavior.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Add missing NULL check for allocworkqueue()
allocworkqueue() can return NULL on memory allocation failure. Without proper error checking, this may lead to a NULL pointer dereference when queuework() is later called with the NULL workqueue pointer in epfntbepcinit().
Add a NULL check immediately after allocworkqueue() and return -ENOMEM on failure to prevent the driver from loading with an invalid workqueue pointer.
In the Linux kernel, the following vulnerability has been resolved:
HID: playstation: Add missing check for inputffcreatememless
The psgamepadcreate() function calls inputffcreatememless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered.
Add a check for the return value of inputffcreatememless().
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix die ID init and look up bugs
In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.
Remove the WARNONONCE(dieid == -1) check for two reasons:
- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.
- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.
Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.
Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().
Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ov5647: Initialize subdev before controls
In ov5647initcontrols() we call v4l2getsubdevdata, but it is initialized by v4l2i2csubdevinit() in the probe, which currently happens after initcontrols(). This can result in a segfault if the error condition is hit, and we try to access i2cclient, so fix the order.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Fix swapped parameters in pci{primary/secondary}epcepfunlink() functions
struct configfsitemoperations callbacks are defined like the following:
int (allowlink)(struct configitem src, struct configitem target); void (droplink)(struct configitem src, struct configitem target);
While pciprimaryepcepflink() and pcisecondaryepcepflink() specify the parameters in the correct order, pciprimaryepcepfunlink() and pcisecondaryepcepfunlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs:
Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintkdefault+0x38/0x4c vprintk+0xc4/0xe0 pciepfunbind+0xdc/0x108 configfsunlink+0xe0/0x208+0x44/0x74 vfsunlink+0x120/0x29c arm64sysunlinkat+0x3c/0x90 invokesyscall+0x48/0x134 doel0svc+0x1c/0x30prop.0+0xd0/0xf0
[mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix staticbranchdec() underflow for aqldisable.
syzbot reported staticbranchdec() underflow in aqlenablewrite(). [0]
The problem is that aqlenablewrite() does not serialise concurrent write()s to the debugfs.
aqlenablewrite() checks statickeyfalse(&aqldisable.key) and later calls staticbranchinc() or staticbranchdec(), but the state may change between the two calls.
aqldisable does not need to track inc/dec.
Let's use staticbranchenable() and staticbranchdisable().
[0]: val == 0 WARNING: kernel/jumplabel.c:311 at statickeyslowdeccpuslocked.part.0+0x107/0x120 kernel/jumplabel.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:statickeyslowdeccpuslocked.part.0+0x107/0x120 kernel/jumplabel.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: <TASK> statickeyslowdeccpuslocked kernel/jumplabel.c:297 [inline] statickeyslowdec kernel/jumplabel.c:321 [inline] statickeyslowdec+0x7c/0xc0 kernel/jumplabel.c:336 aqlenablewrite+0x2b2/0x310 net/mac80211/debugfs.c:343 shortproxywrite+0x133/0x1a0 fs/debugfs/file.c:383 vfswrite+0x2aa/0x1070 fs/readwrite.c:684 ksyspwrite64 fs/readwrite.c:793 [inline] dosyspwrite64 fs/readwrite.c:801 [inline] sesyspwrite64 fs/readwrite.c:798 [inline] x64syspwrite64+0x1eb/0x250 fs/readwrite.c:798 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xc9/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIGRAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: guard flow control update with globaltxfc in buffer switching
mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.
When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378
Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.
Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.
In the Linux kernel, the following vulnerability has been resolved:
iouring/io-wq: check IOWQBITEXIT inside work run loop
Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr file. Since this file type doesn't support ->readiter(), looprwiter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:
INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5256 [inline] schedule+0x1139/0x6150 kernel/sched/core.c:6863 scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalorrestart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback failure
mlx5enetdevchangeprofile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdevpriv. A retry to change profile, e.g. another attempt to call mlx5enetdevchangeprofile via switchdev mode change, will crash trying to access the now NULL priv->mdev.
This fix allows mlx5enetdevchangeprofile() to handle previous failures and an empty priv, by not assuming priv is valid.
Pass netdev and mdev to all flows requiring mlx5enetdevchangeprofile() and avoid passing priv. In mlx5enetdevchangeprofile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.
This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:
## Enabling switchdev mode first time:
mlx5core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)
## retry: Enabling switchdev mode 2nd time:
mlx5core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5edetachnetdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5enetdevchangeprofile+0x45/0xb0 mlx5evportrepload+0x27b/0x2d0 mlx5eswoffloadsrepload+0x72/0xf0 eswoffloadsenable+0x5d0/0x970 mlx5eswitchenablelocked+0x349/0x430 ? ismpsupported+0x57/0xb0 mlx5devlinkeswitchmodeset+0x26b/0x430 devlinknleswitchsetdoit+0x6f/0xf0 genlfamilyrcvmsgdoit+0xe8/0x140 genlrcvmsg+0x18b/0x290 ? pfxdevlinknlpredoit+0x10/0x10 ? pfxdevlinknleswitchsetdoit+0x10/0x10 ? pfxdevlinknlpostdoit+0x10/0x10 ? pfxgenlrcvmsg+0x10/0x10 netlinkrcvskb+0x52/0x100 genlrcv+0x28/0x40 netlinkunicast+0x282/0x3e0 ? allocskb+0xd6/0x190 netlinksendmsg+0x1f7/0x430 syssendto+0x213/0x220 ? sysrecvmsg+0x6a/0xd0 x64syssendto+0x24/0x30 dosyscall64+0x50/0x1f0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Don't store mlx5epriv in mlx5edev devlink priv
mlx5epriv is an unstable structure that can be memset(0) if profile attaching fails, mlx5epriv in mlx5edev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5edev and get mdev from the containing mlx5adev aux device structure.
This fixes a kernel oops in mlx5eremove when switchdev mode fails due to change profile failure.
$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12
$ devlink dev reload pci/0000:00:03.0 ==> oops
BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5eremove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsgdoit+0xe8/0x140
In the Linux kernel, the following vulnerability has been resolved:
net: mscc: ocelot: Fix crash when adding interface under a lag
Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.
This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.
Fix this by checking if the port pointer is valid before accessing it.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancelworksync() will prevent the work from running which also prevents destroying the ahattr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 releasegidtable drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gidtablereleaseone+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ahattr after canceling the work, it is safe to call this twice.
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Add validation before accessing cgx and lmac
with the addition of new MAC blocks like CN10K RPM and CN10KB RPMUSX, LMACs are noncontiguous and CGX blocks are also noncontiguous. But during RVU driver initialization, the driver is assuming they are contiguous and trying to access cgx or lmac with their id which is resulting in kernel panic.
This patch fixes the issue by adding proper checks.
[ 23.219150] pc : cgxlmacread+0x38/0x70 [ 23.219154] lr : rvuprogramchannels+0x3f0/0x498 [ 23.223852] sp : ffff000100d6fc80 [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27: 000000000000005a [ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24: fffffffffff0f000
In the Linux kernel, the following vulnerability has been resolved:
bonding: do not assume skb macheader is set
Drivers must not assume in their ndostartxmit() that skbs have their macheader set. skb->data is all what is needed.
bonding seems to be one of the last offender as caught by syzbot:
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skbmacoffset include/linux/skbuff.h:2913 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bondxmithash drivers/net/bonding/bondmain.c:4170 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bondxmit3adxorslaveget drivers/net/bonding/bondmain.c:5149 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond3adxorxmit drivers/net/bonding/bondmain.c:5186 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bondstartxmit drivers/net/bonding/bondmain.c:5442 [inline] WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bondstartxmit+0x14ab/0x19d0 drivers/net/bonding/bondmain.c:5470 Modules linked in: CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 RIP: 0010:skbmacheader include/linux/skbuff.h:2907 [inline] RIP: 0010:skbmacoffset include/linux/skbuff.h:2913 [inline] RIP: 0010:bondxmithash drivers/net/bonding/bondmain.c:4170 [inline] RIP: 0010:bondxmit3adxorslaveget drivers/net/bonding/bondmain.c:5149 [inline] RIP: 0010:bond3adxorxmit drivers/net/bonding/bondmain.c:5186 [inline] RIP: 0010:bondstartxmit drivers/net/bonding/bondmain.c:5442 [inline] RIP: 0010:bondstartxmit+0x14ab/0x19d0 drivers/net/bonding/bondmain.c:5470 Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283 RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000 RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6 RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584 R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76 FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> [<ffffffff8471a49f>] netdevstartxmit include/linux/netdevice.h:4925 [inline] [<ffffffff8471a49f>] devdirectxmit+0x4ef/0x850 net/core/dev.c:4380 [<ffffffff851d845b>] devdirectxmit include/linux/netdevice.h:3043 [inline] [<ffffffff851d845b>] packetdirectxmit+0x18b/0x300 net/packet/afpacket.c:284 [<ffffffff851c7472>] packetsnd net/packet/afpacket.c:3112 [inline] [<ffffffff851c7472>] packetsendmsg+0x4a22/0x64d0 net/packet/afpacket.c:3143 [<ffffffff8467a4b2>] socksendmsgnosec net/socket.c:716 [inline] [<ffffffff8467a4b2>] socksendmsg net/socket.c:736 [inline] [<ffffffff8467a4b2>] syssendto+0x472/0x5f0 net/socket.c:2139 [<ffffffff8467a715>] dosyssendto net/socket.c:2151 [inline] [<ffffffff8467a715>] sesyssendto net/socket.c:2147 [inline] [<ffffffff8467a715>] x64syssendto+0xe5/0x100 net/socket.c:2147 [<ffffffff8553071f>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff8553071f>] dosyscall64+0x2f/0x50 arch/x86/entry/common.c:80 [<ffffffff85600087>] entrySYSCALL64afterhwframe+0x63/0xcd
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: Fix PCI device refcount leak in mt7915pciinithif2()
As comment of pcigetdevice() says, it returns a pcidevice with its refcount increased. We need to call pcidevput() to decrease the refcount. Save the return value of pcigetdevice() and call pcidevput() to decrease the refcount.
In the Linux kernel, the following vulnerability has been resolved:
i2c: designware: Fix handling of real but unexpected device interrupts
Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2cdwxfermsg() when system resumes from S3 sleep state ("deep").
I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes:
- Issue happens when resuming from S3 but not when resuming from "s2idle" - PCI device 00:15.0 == i2cdesignware.0 is already in D0 state when system enters into pcipmresumenoirq() while all other i2cdesignware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pcipmresumenoirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2cdesignware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DWICRAWINTRSTAT register STARTDET, STOPDET, ACTIVITY and TXEMPTY bits are set indicating completed I2C transaction.
My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system.
I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TXEMPTY (or RXFULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data).
Introduce a new software status flag STATUSACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller.
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix reference count leak in hswephaslimitsbox()
pcigetdevice() will increase the reference count for the returned 'dev'. We need to call pcidevput() to decrease the reference count. Since 'dev' is only used in pcireadconfigdword(), let's add pcidevput() right after it.
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: pcie: fix NULL pointer dereference in iwlpcieirqrxmsixhandler()
rxq can be NULL only when transpcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if transpcie->rxq is NULL. Modify checker to check for transpcie->rxq.
bpf: Fix memleak due to fentry attach failure
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix memory leak in vkmsinit()
A memory leak was reported after the vkms module install failed.
unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloctrace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] dooneinitcall+0xd0/0x4f0 [<000000001505ee87>] doinitmodule+0x1a4/0x680 [<00000000958079ad>] loadmodule+0x6249/0x7110 [<00000000117e4696>] dosysfinitmodule+0x140/0x200 [<00000000f74b12d2>] dosyscall64+0x35/0x80 [<000000008fc6fcde>] entrySYSCALL64afterhwframe+0x46/0xb0
The reason is that the vkmsinit() returns without checking the return value of vkmscreate(), and if the vkmscreate() failed, the config allocated at the beginning of vkmsinit() is leaked.
vkmsinit() config = kmalloc(...) # config allocated ... return vkmscreate() # vkmscreate failed and config is leaked
Fix this problem by checking return value of vkmscreate() and free the config if error happened.
clk: xilinx: vcu: unregister pllpost only if registered correctly
In the Linux kernel, the following vulnerability has been resolved:
riscv:uprobe fix SRSPIE set/clear handling
In riscv the process of uprobe going to clear spie before exec the origin insn,and set spie after that.But When access the page which origin insn has been placed a page fault may happen and irq was disabled in archuprobeprexol function,It cause a WARN as follows. There is no need to clear/set spie in archuprobepre/post/abortxol. We can just remove it.
[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488 [ 31.684677] inatomic(): 0, irqsdisabled(): 1, nonblock: 0, pid: 76, name: work [ 31.684929] preemptcount: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Hardware name: riscv-virtio,qemu (DT) [ 31.686797] Call Trace: [ 31.687053] [<ffffffff80006442>] dumpbacktrace+0x30/0x38 [ 31.687699] [<ffffffff80812118>] showstack+0x40/0x4c [ 31.688141] [<ffffffff8081817a>] dumpstacklvl+0x44/0x5c [ 31.688396] [<ffffffff808181aa>] dumpstack+0x18/0x20 [ 31.688653] [<ffffffff8003e454>] mightresched+0x114/0x122 [ 31.688948] [<ffffffff8003e4b2>] mightsleep+0x50/0x7a [ 31.689435] [<ffffffff80822676>] downread+0x30/0x130 [ 31.689728] [<ffffffff8000b650>] dopagefault+0x166/x446 [ 31.689997] [<ffffffff80003c0c>] retfromexception+0x0/0xc
In the Linux kernel, the following vulnerability has been resolved:
selinux: fix memleak in securityreadstatekernel()
In this function, it directly returns the result of securityreadpolicy without freeing the allocated memory in data, cause memory leak issue, so free the memory if securityreadpolicy failed.
[PM: subject line tweak]
In the Linux kernel, the following vulnerability has been resolved:
PCI: microchip: Fix refcount leak in mcpcieinitirqdomains()
ofgetnextchild() returns a node pointer with refcount incremented, so we should use ofnodeput() on it when we don't need it anymore.
mcpcieinitirqdomains() only calls ofnodeput() in the normal path, missing it in some error paths. Add missing ofnodeput() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: ensure pages are unlocked on cowfilerange() failure
There is a hungtask report on zoned btrfs like below.
https://github.com/naota/linux/issues/59
[726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] <TASK> [726.331614] schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] ioschedule+0x3f/0x70 [726.331629] foliolock+0x125/0x200 [726.331634] ? findgetentries+0x1bc/0x240 [726.331638] ? filemapinvalidateunlocktwo+0x40/0x40 [726.331642] truncateinodepagesrange+0x5b2/0x770 [726.331649] truncateinodepagesfinal+0x44/0x50 [726.331653] btrfsevictinode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] dounlinkat+0x1c0/0x2b0 [726.331668] x64sysunlink+0x23/0x30 [726.331670] dosyscall64+0x3b/0xc0 [726.331674] entrySYSCALL64afterhwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIGRAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] </TASK>
While we debug the issue, we found running fstests generic/551 on 5GB non-zoned nullblk device in the emulated zoned mode also had a similar hung issue.
Also, we can reproduce the same symptom with an error injected cowfilerange() setup.
The hang occurs when cowfilerange() fails in the middle of allocation. cowfilerange() called from doallocationzoned() can split the give region ([start, end]) for allocation depending on current block group usages. When btrfs can allocate bytes for one part of the split regions but fails for the other region (e.g. because of -ENOSPC), we return the error leaving the pages in the succeeded regions locked. Technically, this occurs only when @unlock == 0. Otherwise, we unlock the pages in an allocated region after creating an ordered extent.
Considering the callers of cowfilerange(unlock=0) won't write out the pages, we can unlock the pages on error exit from cowfilerange(). So, we can ensure all the pages except @lockedpage are unlocked on error case.
In summary, cowfilerange now behaves like this:
- pagestarted == 1 (return value) - All the pages are unlocked. IO is started. - unlock == 1 - All the pages except @lockedpage are unlocked in any case - unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @lockedpage are unlocked
In the Linux kernel, the following vulnerability has been resolved:
net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null
Fixes a NULL pointer derefence bug triggered from tap driver. When tapgetuser calls virtionethdrtoskb the skb->dev is null (in tap.c skb->dev is set after the call to virtionethdrtoskb) virtionethdrtoskb calls devparseheaderprotocol which needs skb->dev field to be valid.
The line that trigers the bug is in devparseheaderprotocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->headerops || !dev->headerops->parseprotocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax
Setting skb->dev before the call in tap.c fixes the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtionethdrtoskb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tapgetuser+0x3f1/0x540 [tap] tapsendmsg+0x56/0x362 [tap] ? gettxbufs+0xc2/0x1e0 [vhostnet] handletxcopy+0x114/0x670 [vhostnet] handletx+0xb0/0xe0 [vhostnet] handletxkick+0x15/0x20 [vhostnet] vhostworker+0x7b/0xc0 [vhost] ? vhostvringcallreset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
net: fix potential refcount leak in ndiscrouterdiscovery()
The issue happens on specific paths in the function. After both the object rt and neigh are grabbed successfully, when lifetime is nonzero but the metric needs change, the function just deletes the route and set rt to NULL. Then, it may try grabbing rt and neigh again if above conditions hold. The function simply overwrite neigh if succeeds or returns if fails, without decreasing the reference count of previous neigh. This may result in memory leaks.
Fix it by decrementing the reference count of neigh in place.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhciwrite
Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810d81ac00 (size 240): [...] hex dump (first 32 bytes): 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 00 00 ................ backtrace: [<ffffffff838733d9>] allocskb+0x1f9/0x270 net/core/skbuff.c:418 [<ffffffff833f742f>] allocskb include/linux/skbuff.h:1257 [inline] [<ffffffff833f742f>] btskballoc include/net/bluetooth/bluetooth.h:469 [inline] [<ffffffff833f742f>] vhcigetuser drivers/bluetooth/hcivhci.c:391 [inline] [<ffffffff833f742f>] vhciwrite+0x5f/0x230 drivers/bluetooth/hcivhci.c:511 [<ffffffff815e398d>] callwriteiter include/linux/fs.h:2192 [inline] [<ffffffff815e398d>] newsyncwrite fs/readwrite.c:491 [inline] [<ffffffff815e398d>] vfswrite+0x42d/0x540 fs/readwrite.c:578 [<ffffffff815e3cdd>] ksyswrite+0x9d/0x160 fs/readwrite.c:631 [<ffffffff845e0645>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e0645>] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84600087>] entrySYSCALL64afterhwframe+0x63/0xcd ====================================
HCI core will uses hcirxwork() to process frame, which is queued to the hdev->rxq tail in hcirecvframe() by HCI driver.
Yet the problem is that, HCI core may not free the skb after handling ACL data packets. To be more specific, when start fragment does not contain the L2CAP length, HCI core just copies skb into conn->rxskb and finishes frame process in l2caprecvacldata(), without freeing the skb, which triggers the above memory leak.
This patch solves it by releasing the relative skb, after processing the above case in l2caprecvacldata().
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory leak in tracingreadpipe()
kmemleak reports this issue:
unreferenced object 0xffff888105a18900 (size 128): comm "testprogs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] kmallocnodetrackcaller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] traceiterexpandformat+0x99/0x150 [<000000005a53bdb6>] tracecheckvprintf+0x1e0/0x11d0 [<0000000065629d9d>] traceeventprintf+0xb6/0xf0 [<000000009a690dc7>] tracerawoutputbpftraceprintk+0x89/0xc0 [<00000000d22db172>] printtraceline+0x73c/0x1480 [<00000000cdba76ba>] tracingreadpipe+0x45c/0x9f0 [<0000000015b58459>] vfsread+0x17b/0x7c0 [<000000004aeee8ed>] ksysread+0xed/0x1c0 [<0000000063d3d898>] dosyscall64+0x3b/0x90 [<00000000a06dda7f>] entrySYSCALL64afterhwframe+0x63/0xcd
iter->fmt alloced in tracingreadpipe() -> .. ->traceiterexpandformat(), but not freed, to fix, add free in tracingreleasepipe()