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:

fs: Fix uninitialized value issue in fromkuid and fromkgid

ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTRGID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTRGID are initialized, otherwise 0.

HID: core: zero-initialize the report buffer

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

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

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

netfilter: nftpayload: sanitize offset and length before calling skbchecksum()

If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON().

skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.

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

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:

Bluetooth: bnep: fix wild-memory-access in protounregister

There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:protounregister+0xee/0x400 Call Trace: <TASK> dosysdeletemodule+0x318/0x580 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

As bnepinit() ignore bnepsockinit()'s return value, and bnepsockinit() will cleanup all resource. Then when remove bnep module will call bnepsockcleanup() to cleanup sock's resource. To solve above issue just return bnepsockinit()'s return value in bnepexit().

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

igb: Do not bring the device up after non-fatal error

Commit 004d25060c78 ("igb: Fix igbdown hung on surprise removal") changed igbioerrordetected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igbdown() is called multiple times. This caused an issue when processing transient non-fatal errors. igbioresume(), which is called after igbioerrordetected(), assumes that device is brought down by igbioerrordetected() if the interface is up. This resulted in panic with stacktrace below.

[ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast errordetected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmioenabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napienable+0x37/0x40 [ T292] Call Trace: [ T292] <TASK> [ T292] ? die+0x33/0x90 [ T292] ? dotrap+0xdc/0x110 [ T292] ? napienable+0x37/0x40 [ T292] ? doerrortrap+0x70/0xb0 [ T292] ? napienable+0x37/0x40 [ T292] ? napienable+0x37/0x40 [ T292] ? excinvalidop+0x4e/0x70 [ T292] ? napienable+0x37/0x40 [ T292] ? asmexcinvalidop+0x16/0x20 [ T292] ? napienable+0x37/0x40 [ T292] igbup+0x41/0x150 [ T292] igbioresume+0x25/0x70 [ T292] reportresume+0x54/0x70 [ T292] ? reportfrozendetected+0x20/0x20 [ T292] pciwalkbus+0x6c/0x90 [ T292] ? aerprintportinfo+0xa0/0xa0 [ T292] pciedorecovery+0x22f/0x380 [ T292] aerprocesserrdevices+0x110/0x160 [ T292] aerisr+0x1c1/0x1e0 [ T292] ? disableirqnosync+0x10/0x10 [ T292] irqthreadfn+0x1a/0x60 [ T292] irqthread+0xe3/0x1a0 [ T292] ? irqsetaffinitynotifier+0x120/0x120 [ T292] ? irqaffinitynotify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromfork+0x2d/0x50 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromforkasm+0x11/0x20 [ T292] </TASK>

To fix this issue igbioresume() checks if the interface is running and the device is not down this means igbioerrordetected() did not bring the device down and there is no need to bring it up.

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

drm/mediatek: Fix potential NULL dereference in mtkcrtcdestroy()

In mtkcrtccreate(), if the call to mboxrequestchannel() fails then we set the "mtkcrtc->cmdqclient.chan" pointer to NULL. In that situation, we do not call cmdqpktcreate().

During the cleanup, we need to check if the "mtkcrtc->cmdqclient.chan" is NULL first before calling cmdqpktdestroy(). Calling cmdqpktdestroy() is unnecessary if we didn't call cmdqpktcreate() and it will result in a NULL pointer dereference.

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.

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.

fs/ntfs3: Fix possible deadlock in miread

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.

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.

fs/ntfs3: Additional check in niclear()

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

fs/ntfs3: Fix general protection fault in runismappedfull

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