iio: light: veml6030: fix IIO device retrieval from embedded device

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

staging: iio: frequency: ad9832: fix division by zero in ad9832calcfreqreg()

In the ad9832writefrequency() function, clkgetrate() might return 0. This can lead to a division by zero when calling ad9832calcfreqreg(). The check if (fout > (clkgetrate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832writefrequency() function is called from ad9832write(), and fout is derived from a text buffer, which can contain any value.

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

pinctrl: ocelot: fix system hang on level based interrupts

The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts.

for (i = 0; i < info->stride; i++) { uregmapread(info->map, idreg + 4 i, &reg); if (!reg) continue;

chainedirqenter(parentchip, desc);

However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt.

Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware.

The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chainedirqenter drivers/pinctrl

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

net: systemport: fix potential memory leak in bcmsysportxmit()

The bcmsysportxmit() returns NETDEVTXOK without freeing skb in case of dmamapsingle() fails, add devkfreeskb() to fix it.

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

nilfs2: fix potential deadlock with newly created symlinks

Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock.

This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem().

This is not a problem for symlinks read from the backing device, because the GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held:

Fix this issue by dropping the GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.

iio: adc: ad7124: fix division by zero in ad7124setchannelodr()

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

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove():

[ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] vfsremovexattr+0x92/0xc0 [ 57.339182] vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...]

Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: 1st: in ocfs2xacleanupvaluetruncate(); 2nd: returning back to ocfs2xaremove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.

filemap: Fix bounds checking in filemapread()

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

signal: restore the overriderlimit logic

Prior to commit d64696905554 ("Reimplement RLIMITSIGPENDING on top of ucounts") UCOUNTRLIMITSIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if overriderlimit is set. This behavior change caused production issues.

For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueuealloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications.

Fix this by passing overriderlimit into incrlimitgetucounts() and skip the comparison to max there if overriderlimit is set. This effectively restores the old behavior.

ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize()

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

media: v4l2-tpg: prevent the risk of a division by zero

As reported by Coverity, the logic at tpgprecalculateline() blindly rescales the buffer even when scaledwitdh is equal to zero. If this ever happens, this will cause a division by zero.

Instead, add a WARNONONCE() to trigger such cases and return without doing any precalculation.

fsl/fman: Fix refcount handling of fman-related devices

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

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AFINET

Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen{s,d}, since that's how prefixlen is going to be used later on.

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

net: enetc: allocate vfstate during PF probes

In the previous implementation, vfstate is allocated memory only when VF is enabled. However, netdeviceops::ndosetvfmac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetcpfsetvfmac() will access vfstate, resulting in access to a null pointer. The simplified error log is as follows.

root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetcpfsetvfmac+0x3c/0x80 Message from sy [ 173.641973] lr : dosetlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetcpfsetvfmac+0x3c/0x80 [ 173.738847] rtnlnewlink+0x530/0x89c [ 173.742692] rtnlnewlink+0x50/0x7c [ 173.746189] rtnetlinkrcvmsg+0x128/0x390 [ 173.750298] netlinkrcvskb+0x60/0x130 [ 173.754145] rtnetlinkrcv+0x18/0x24 [ 173.757731] netlinkunicast+0x318/0x380 [ 173.761665] netlinksendmsg+0x17c/0x3c8

be2net: fix potential memory leak in bexmit()

ALSA: hda/cs8409: Fix possible NULL dereference

bpf: Make sure internal and UAPI bpfredirect flags don't overlap

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelfind()

The per-netns IP tunnel hash table is protected by the RTNL mutex and iptunnelfind() is only called from the control path where the mutex is taken.

Add a lockdep expression to hlistforeachentryrcu() in iptunnelfind() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1].

[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/iptunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 iptunnelfind+0x435/0x4d0 iptunnelnewlink+0x517/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

arm64: probes: Fix uprobes for big-endian kernels

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

scsi: target: core: Fix null-ptr-deref in targetallocdevice()

There is a null-ptr-deref issue reported by KASAN:

BUG: KASAN: null-ptr-deref in targetallocdevice+0xbc4/0xbe0 [targetcoremod] ... kasanreport+0xb9/0xf0 targetallocdevice+0xbc4/0xbe0 [targetcoremod] coredevsetupvirtuallun0+0xef/0x1f0 [targetcoremod] targetcoreinitconfigfs+0x205/0x420 [targetcoremod] dooneinitcall+0xdd/0x4e0 ... entrySYSCALL64afterhwframe+0x76/0x7e

In targetallocdevice(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->freedevice(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem.

Fixing this bug by freeing dev with hba->backend->ops->freedevice().

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

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

RDMA/bnxtre: Avoid CPU lockups due fifo occupancy check loop

Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high.

Add a loop count for FPGA and exit the waitforfifooccupancybelowth if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxtrepacingtimerexp and further scheduling the work for pacing based on the fifo occupancy.

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

net/sun382586: fix potential memory leak in sun382586sendpacket()

The sun382586sendpacket() returns NETDEVTXOK without freeing skb in case of skb->len being too long, add devkfreeskb() to fix it.

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

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/.

Plug the race by checking the value of vmappcount, which tracks whether the VPE is mapped ot not, and returning an error in this case.

This involves making vmappcount common to both GICv4.1 and its v4.0 ancestor.

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelinitflow()

There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1].

Fix by using l3mdevmasterupperifindexbyindex() which will acquire the RCU read lock before calling l3mdevmasterupperifindexbyindexrcu().

[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 devgetbyindexrcu+0x1d3/0x210 l3mdevmasterupperifindexbyindexrcu+0x2b/0xf0 iptunnelbinddev+0x72f/0xa00 iptunnelnewlink+0x368/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

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

wifi: iwlwifi: mvm: fix 6 GHz scan construction

If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope.

Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.

ACPI: CPPC: Make rmwlock a rawspinlock

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

virtio/vsock: Fix acceptqueue memory leak

As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.

vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release

Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromforkasm+0x1a/0x30

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

vt: prevent kernel-infoleak in confontget()

font.data may not initialize all memory spaces depending on the implementation of vc->vcsw->confontget. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.

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

iouring/rw: fix missing NOWAIT check for ODIRECT start write

When iouring starts a write, it'll call kiocbstartwrite() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But iouring unconditionally uses kiocbstartwrite(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:

task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: switchto+0x1d8/0x348 schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpurwsemwait+0x1e8/0x3f8 percpudownread+0xe8/0x500 iowrite+0xbb8/0xff8 ioissuesqe+0x10c/0x1020 iosubmitsqes+0x614/0x2110 arm64sysiouringenter+0x524/0x1038 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963

with the attempting freezer stuck trying to grab the rwsem:

task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: switchto+0x1d8/0x348 schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpudownwrite+0x2b0/0x680 freezesuper+0x248/0x8a8 dovfsioctl+0x149c/0x1b18 arm64sysioctl+0xd0/0x1a0 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170

Fix this by having the iouring side honor IOCBNOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCBNOWAIT would always be set, this returns -EAGAIN which will have iouring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.

Since freezing requires CAPSYSADMIN in the first place, this isn't something that can be triggered by a regular user.