atm: Fix NULL pointer dereference
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix management of listener transports
Currently, when no active threads are running, a root user using nfsdctl command can try to remove a particular listener from the list of previously added ones, then start the server by increasing the number of threads, it leads to the following problem:
[ 158.835354] refcountt: addition on 0; use-after-free. [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcountwarnsaturate+0x160/0x1a0 [ 158.836017] Modules linked in: rpcrdma rdmacm iwcm ibcm ibcore nfsd authrpcgss nfsacl lockd grace overlay isofs uinput sndseqdummy sndhrtimer nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 rfkill ipset nftables qrtr sunrpc vfat fat uvcvideo videobuf2vmalloc videobuf2memops uvc videobuf2v4l2 videodev videobuf2common sndhdacodecgeneric mc e1000e sndhdaintel sndinteldspcfg sndhdacodec sndhdacore sndhwdep sndseq sndseqdevice sndpcm sndtimer snd soundcore sg loop dmmultipath dmmod nfnetlink vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs libcrc32c crct10difce ghashce vmwgfx sha2ce sha256arm64 srmod sha1ce cdrom nvme drmclientlib drmttmhelper ttm nvmecore drmkmshelper nvmeauth drm fuse [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7 [ 158.840624] Tainted: [B]=BADPAGE, [W]=WARN [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 158.841563] pc : refcountwarnsaturate+0x160/0x1a0 [ 158.841780] lr : refcountwarnsaturate+0x160/0x1a0 [ 158.842000] sp : ffff800089be7d80 [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148 [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010 [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028 [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000 [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493 [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000 [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001 [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000 [ 158.845528] Call trace: [ 158.845658] refcountwarnsaturate+0x160/0x1a0 (P) [ 158.845894] svcrecv+0x58c/0x680 [sunrpc] [ 158.846183] nfsd+0x1fc/0x348 [nfsd] [ 158.846390] kthread+0x274/0x2f8 [ 158.846546] retfromfork+0x10/0x20 [ 158.846714] ---[ end trace 0000000000000000 ]---
nfsdnllistenersetdoit() would manipulate the list of transports of server's svpermsocks and close the specified listener but the other list of transports (server's spxprts list) would not be changed leading to the problem above.
Instead, determined if the nfsdctl is trying to remove a listener, in which case, delete all the existing listener transports and re-create all-but-the-removed ones.
In the Linux kernel, the following vulnerability has been resolved:
staging: gpib: Fix Oops after disconnect in agilent usb
If the agilent usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the businterface is set to NULL on disconnect.
This problem was introduced by setting usbdev from the businterface for devxxx messages.
Previously businterface was checked for NULL only in the functions directly calling usbfillbulkurb or usbcontrolmsg.
Check for valid businterface on all interface entry points and return -ENODEV if it is NULL.
In the Linux kernel, the following vulnerability has been resolved:
media: vimc: skip .sstream() for stopped entities
Syzbot reported [1] a warning prompted by a check in callsstream() that checks whether .sstream() operation is warranted for unstarted or stopped subdevs.
Add a simple fix in vimcstreamerpipelineterminate() ensuring that entities skip a call to .sstream() unless they have been previously properly started.
[1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 callsstream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace: <TASK> vimcstreamerpipelineterminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimcstreamerpipelineinit drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimcstreamersstream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimccapturestartstreaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2startstreaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2corestreamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2ioctlstreamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 videodoioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 videousercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2b85c01b19 ...
arm64: Don't call NULL in docompatalignmentfixup()
In the Linux kernel, the following vulnerability has been resolved:
net: ibmveth: make vethpoolstore stop hanging
v2: - Created a single error handling unlock and exit in vethpoolstore - Greatly expanded commit message with previous explanatory-only text
Summary: Use rtnlmutex to synchronize vethpoolstore with itself, ibmvethclose and ibmvethopen, preventing multiple calls in a row to napidisable.
Background: Two (or more) threads could call vethpoolstore through writing to /sys/devices/vio/30000002/pool/. You can do this easily with a little shell script. This causes a hang.
I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:
Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 taskflags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] switchto+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedulepreemptdisabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] mutexlock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napienable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmvethopen+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] vethpoolstore+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfskfwrite+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfsfopwriteiter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfswrite+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksyswrite+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] systemcallexception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] systemcallvectoredcommon+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcureadlock){....}-{1:2}, at: debugshowalllocks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sbwriters#3){.+.+}-{0:0}, at: ksyswrite+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfsfopwriteiter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfsfopwriteiter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napienable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sbwriters#3){.+.+}-{0:0}, at: ksyswrite+0x88/0x150 [ 243. ---truncated---
arcnet: Add NULL check in com20020pciprobe()
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix cryptofreeacomp() deadlock in zswapcpucompdead()
Currently, zswapcpucompdead() calls cryptofreeacomp() while holding the per-CPU acompctx mutex. cryptofreeacomp() then holds scomplock (through cryptoexitscompopsasync()).
On the other hand, cryptoallocacompnode() holds the scomplock (through cryptoscompinittfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acompctx mutex.
The above dependencies can cause an ABBA deadlock. For example in the following scenario:
(1) Task A running on CPU #1: cryptoallocacompnode() Holds scomplock Enters reclaim Reads percpuptr(pool->acompctx, 1)
(2) Task A is descheduled
(3) CPU #1 goes offline zswapcpucompdead(CPU #1) Holds percpuptr(pool->acompctx, 1)) Calls cryptofreeacomp() Waits for scomplock
(4) Task A running on CPU #2: Waits for percpuptr(pool->acompctx, 1) // Read on CPU #1 DEADLOCK
Since there is no requirement to call cryptofreeacomp() with the per-CPU acompctx mutex held in zswapcpucompdead(), move it after the mutex is unlocked. Also move the acomprequestfree() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future.
With this, only setting acompctx fields to NULL occurs with the mutex held. This is similar to how zswapcpucompprepare() only initializes acompctx fields with the mutex held, after performing all allocations before holding the mutex.
Opportunistically, move the NULL check on acompctx so that it takes place before the mutex dereference.
In the Linux kernel, the following vulnerability has been resolved:
PCI/bwctrl: Fix NULL pointer dereference on bus number exhaustion
When BIOS neglects to assign bus numbers to PCI bridges, the kernel attempts to correct that during PCI device enumeration. If it runs out of bus numbers, no pcibus is allocated and the "subordinate" pointer in the bridge's pcidev remains NULL.
The PCIe bandwidth controller erroneously does not check for a NULL subordinate pointer and dereferences it on probe.
Bandwidth control of unusable devices below the bridge is of questionable utility, so simply error out instead. This mirrors what PCIe hotplug does since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp probe").
The PCI core emits a message with KERNINFO severity if it has run out of bus numbers. PCIe hotplug emits an additional message with KERNERR severity to inform the user that hotplug functionality is disabled at the bridge. A similar message for bandwidth control does not seem merited, given that its only purpose so far is to expose an up-to-date link speed in sysfs and throttle the link speed on certain laptops with limited Thermal Design Power. So error out silently.
User-visible messages:
pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring [...] pcibus 0000:45: busnres: [bus 45-74] end is updated to 74 pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them [...] pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring [...] BUG: kernel NULL pointer dereference RIP: pcieupdatelinkspeed pciebwnotifenable pciebwnotifprobe pcieportprobeservice reallyprobe
In the Linux kernel, the following vulnerability has been resolved:
uprobes/x86: Harden uretprobe syscall trampoline check
Jann reported a possible issue when trampolinecheckip returns address near the bottom of the address space that is allowed to call into the syscall if uretprobes are not set up:
https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf
Though the mmap minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall checks for that.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: fix kernel panic due to null pointer dereference
Address a kernel panic caused by a null pointer dereference in the mt792xrxgetwcid function. The issue arises because the deflink structure is not properly initialized with the sta context. This patch ensures that the deflink structure is correctly linked to the sta context, preventing the null pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000400 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1 Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011 RIP: 0010:mt792xrxgetwcid+0x48/0x140 [mt792xlib] RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000 RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000 R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119 R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000 FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0 Call Trace: <TASK> ? diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2f0 ? searchmoduleextables+0x19/0x60 ? searchbpfextables+0x5f/0x80 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? mt792xrxgetwcid+0x48/0x140 [mt792xlib] mt7921queuerxskb+0x1c6/0xaa0 [mt7921common] mt76uallocqueues+0x784/0x810 [mt76usb] ? pfxmt76workerfn+0x10/0x10 [mt76] mt76workerfn+0x4f/0x80 [mt76] kthread+0xd2/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
staging: gpib: Fix Oops after disconnect in niusb
If the usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the businterface is set to NULL on disconnect.
This problem was introduced by setting usbdev from the businterface for devxxx messages.
Previously businterface was checked for NULL only in the the functions directly calling usbfillbulkurb or usbcontrolmsg.
Check for valid businterface on all interface entry points and return -ENODEV if it is NULL.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't ignore the return code of svcprocregister()
Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.
Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.
svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix missing shutdown check
xfstests generic/730 test failed because after deleting the device that still had dirty data, the file could still be read without returning an error. The reason is the missing shutdown check in ->readiter.
I also noticed that shutdown checks were missing from ->writeiter, ->spliceread, and ->mmap. This commit adds shutdown checks to all of them.
In the Linux kernel, the following vulnerability has been resolved:
iio: backend: make sure to NULL terminate stack buffer
Make sure to NULL terminate the buffer in iiobackenddebugfswritereg() before passing it to sscanf(). It is a stack variable so we should not assume it will 0 initialized.
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak on spufsnewfile() failure
It's called from spufsfilldir(), and caller of that will do spufsrmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gem: Fix error code msmparsedeps()
The SUBMITERROR() macro turns the error code negative. This extra '-' operation turns it back to positive EINVAL again. The error code is passed to ERRPTR() and since positive values are not an ISERR() it eventually will lead to an oops. Delete the '-'.
Patchwork: https://patchwork.freedesktop.org/patch/637625/
In the Linux kernel, the following vulnerability has been resolved:
staging: vchiqarm: Fix possible NPR of keep-alive thread
In case vchiqplatformconnstatechanged() is never called or fails before driver removal, kathread won't be a valid pointer to a taskstruct. So do the necessary checks before calling kthreadstop to avoid a crash.
In the Linux kernel, the following vulnerability has been resolved:
w1: fix NULL pointer dereference in probe
The w1uartprobe() function calls w1uartserdevopen() (which includes devmserdevdeviceopen()) before setting the client ops via serdevdevicesetclientops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receivebuf handler, as it assumes serdev->ops is valid when SERPORTACTIVE is set.
This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: crosecuart: properly fix race condition") where devmserdevdeviceopen() was called before fully initializing the device.
Fix the race by ensuring client ops are set before enabling the port via w1uartserdevopen().
bonding: check xdp prog when set bond mode
ASoC: imx-card: Add NULL check in imxcardprobe()
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriovnumvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnlgetlink+0x586/0x5a0 Modules linked in: xtconntrack xtMASQUERADE nfnetlink xtaddrtype iptablenat nfnat brnetfilter overlay mlx5ib macsec mlx5core tls rpcrdma rdmaucm ibuverbs ibiser libiscsi scsitransportiscsi ibumad rdmacm iwcm ibipoib fuse ibcm ibcore CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnlgetlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0xa5/0x230 ? rtnlgetlink+0x586/0x5a0 ? reportbug+0x22d/0x240 ? handlebug+0x53/0xa0 ? excinvalidop+0x14/0x50 ? asmexcinvalidop+0x16/0x20 ? skbtrim+0x6a/0x80 ? rtnlgetlink+0x586/0x5a0 ? pfxrtnlgetlink+0x10/0x10 ? rtnetlinkrcvmsg+0x1e5/0x860 ? pfxmutexlock+0x10/0x10 ? rcuiswatching+0x34/0x60 ? pfxlockacquire+0x10/0x10 ? stacktracesave+0x90/0xd0 ? filterirqstacks+0x1d/0x70 ? kasansavestack+0x30/0x40 ? kasansavestack+0x20/0x40 ? kasansavetrack+0x10/0x30 rtnetlinkrcvmsg+0x21c/0x860 ? entrySYSCALL64afterhwframe+0x76/0x7e ? pfxrtnetlinkrcvmsg+0x10/0x10 ? archstackwalk+0x9e/0xf0 ? rcuiswatching+0x34/0x60 ? lockacquire+0xd5/0x410 ? rcuiswatching+0x34/0x60 netlinkrcvskb+0xe0/0x210 ? pfxrtnetlinkrcvmsg+0x10/0x10 ? pfxnetlinkrcvskb+0x10/0x10 ? rcuiswatching+0x34/0x60 ? pfxnetlinklookup+0x10/0x10 ? lockrelease+0x62/0x200 ? netlinkdelivertap+0xfd/0x290 ? rcuiswatching+0x34/0x60 ? lockrelease+0x62/0x200 ? netlinkdelivertap+0x95/0x290 netlinkunicast+0x31f/0x480 ? pfxnetlinkunicast+0x10/0x10 ? rcuiswatching+0x34/0x60 ? lockacquire+0xd5/0x410 netlinksendmsg+0x369/0x660 ? lockrelease+0x62/0x200 ? pfxnetlinksendmsg+0x10/0x10 ? importubuf+0xb9/0xf0 ? importiovec+0x254/0x2b0 ? lockrelease+0x62/0x200 ? pfxnetlinksendmsg+0x10/0x10 syssendmsg+0x559/0x5a0 ? pfxsyssendmsg+0x10/0x10 ? pfxcopymsghdrfromuser+0x10/0x10 ? rcuiswatching+0x34/0x60 ? doreadfault+0x213/0x4a0 ? rcuiswatching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfxsyssendmsg+0x10/0x10 ? dofault+0x2cc/0x6f0 ? handleptefault+0x2e3/0x3d0 ? pfxhandleptefault+0x10/0x10 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak in spufscreatecontext()
Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufsmkdir() fails, we need to drop the reference to neighbor.
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlblconnsetattr(), addr->safamily is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipsosocksetattr() is triggered. Inside this function, the following code is executed:
skfullsock(sk) ? inetsk(sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6sk(sk) returns a NULL pointer before accessing pinet6.
In the Linux kernel, the following vulnerability has been resolved:
drm: xlnx: zynqmpdpsub: Add NULL check in zynqmpaudioinit
devmkasprintf() calls can return null pointers on failure. But some return values were not checked in zynqmpaudioinit().
Add NULL check in zynqmpaudioinit(), avoid referencing null pointers in the subsequent code.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: avoid NPD when ASIC does not support DMUB
ctx->dmubsrv will de NULL if the ASIC does not support DMUB, which is tested in dmdmubswinit.
However, it will be dereferenced in dmubhwlockmgrcmd if shouldusedmublock returns true.
This has been the case since dmub support has been added for PSR1.
Fix this by checking for dmubsrv in shouldusedmublock.
[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: errorcode(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS GoogleMorphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmubhwlockmgrcmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] <TASK> [ 37.577258] ? diebody+0x66/0xb0 [ 37.580756] ? pagefaultoops+0x3e7/0x4a0 [ 37.584861] ? excpagefault+0x3e/0xe0 [ 37.588706] ? excpagefault+0x5c/0xe0 [ 37.592550] ? asmexcpagefault+0x22/0x30 [ 37.596742] ? dmubhwlockmgrcmd+0x77/0xb0 [ 37.601107] dcn10cursorlock+0x1e1/0x240 [ 37.605211] programcursorattributes+0x81/0x190 [ 37.609923] commitplanesforstream+0x998/0x1ef0 [ 37.614722] updateplanesandstreamv2+0x41e/0x5c0 [ 37.619703] dcupdateplanesandstream+0x78/0x140 [ 37.624588] amdgpudmatomiccommittail+0x4362/0x49f0 [ 37.629832] ? srsoreturnthunk+0x5/0x5f [ 37.633847] ? markheldlocks+0x6d/0xd0 [ 37.637774] ? rawspinunlockirq+0x24/0x50 [ 37.642135] ? srsoreturnthunk+0x5/0x5f [ 37.646148] ? lockdephardirqson+0x95/0x150 [ 37.650510] ? srsoreturnthunk+0x5/0x5f [ 37.654522] ? rawspinunlockirq+0x2f/0x50 [ 37.658883] ? srsoreturnthunk+0x5/0x5f [ 37.662897] ? waitforcommon+0x186/0x1c0 [ 37.666998] ? srsoreturnthunk+0x5/0x5f [ 37.671009] ? drmcrtcnextvblankstart+0xc3/0x170 [ 37.675983] committail+0xf5/0x1c0 [ 37.679478] drmatomichelpercommit+0x2a2/0x2b0 [ 37.684186] drmatomiccommit+0xd6/0x100 [ 37.688199] ? cfidrmprintfninfo+0x10/0x10 [ 37.692911] drmatomichelperupdateplane+0xe5/0x130 [ 37.698054] drmmodecursorcommon+0x501/0x670 [ 37.702600] ? cfidrmmodecursorioctl+0x10/0x10 [ 37.707572] drmmodecursorioctl+0x48/0x70 [ 37.711851] drmioctlkernel+0xf2/0x150 [ 37.715781] drmioctl+0x363/0x590 [ 37.719189] ? cfidrmmodecursorioctl+0x10/0x10 [ 37.724165] amdgpudrmioctl+0x41/0x80 [ 37.728013] sesysioctl+0x7f/0xd0 [ 37.731685] dosyscall64+0x87/0x100 [ 37.735355] ? vmaendread+0x12/0xe0 [ 37.739024] ? srsoreturnthunk+0x5/0x5f [ 37.743041] ? findheldlock+0x47/0xf0 [ 37.746884] ? vmaendread+0x12/0xe0 [ 37.750552] ? srsoreturnthunk+0x5/0 ---truncated---
fs/9p: fix NULL pointer dereference on mkdir
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix pagesize variable overflow
Change all variables storing mlx5umemmkcfindbestpgsz() result to unsigned long to support values larger than 31 and avoid overflow.
For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the pagesize and try to use an mkey with 4GB entity size. The 'unsigned int' pagesize variable will overflow to '0' and we'll hit the WARNON() in alloccacheablemr().
WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloccacheablemr+0x22/0x580 [mlx5ib] Modules linked in: mlx5ib mlx5core bonding ip6gre ip6tunnel tunnel6 ipgre gre rdmarxe rdmaucm ibuverbs ibipoib ibumad rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm fuse ibcore [last unloaded: mlx5core] CPU: 2 UID: 70878 PID: 1203 Comm: rdmaresourcel Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloccacheablemr+0x22/0x580 [mlx5ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0x81/0x130 ? alloccacheablemr+0x22/0x580 [mlx5ib] ? reportbug+0xfc/0x1e0 ? handlebug+0x55/0x90 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? alloccacheablemr+0x22/0x580 [mlx5ib] createrealmr+0x54/0x150 [mlx5ib] ibuverbsregmr+0x17f/0x2a0 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0xca/0x140 [ibuverbs] ibuverbsrunmethod+0x6d0/0x780 [ibuverbs] ? pfxibuverbshandlerUVERBSMETHODINVOKEWRITE+0x10/0x10 [ibuverbs] ibuverbscmdverbs+0x19b/0x360 [ibuverbs] ? walksystemramrange+0x79/0xd0 ? pteoffsetmap+0x1b/0x110 ? pteoffsetmaplock+0x80/0x100 ibuverbsioctl+0xac/0x110 [ibuverbs] x64sysioctl+0x94/0xb0 dosyscall64+0x50/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
PCI: brcmstb: Fix error path after a call to regulatorbulkget()
If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.
If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.
While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().
[kwilczynski: commit log, use comma in the message to match style with other similar messages]
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: don't unregister hook when table is dormant
When nftablesupdchain encounters an error, hook registration needs to be rolled back.
This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block.