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:

drm/vboxvideo: Replace fake VLA at end of vbvamousepointershape with real VLA

Replace the fake VLA at end of the vbvamousepointershape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning:

[ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 hgsmiupdatepointershape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmiupdatepointershape [vboxvideo] [ 13.320184] vboxcursoratomicupdate [vboxvideo]

Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.

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:

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

ACPI: battery: Fix possible crash when unregistering a battery hook

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

net: avoid potential underflow in qdiscpktleninit() with UFO

After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtionethdrtoskb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet.

Then commit cf9acc90c80ec ("net: virtionethdrtoskb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic :

IPv4 SKBGSOUDP, gsosize=3, skb->len = 28.

When this packet arrives in qdiscpktleninit(), we end up with hdrlen = 28 (IPv4 header + UDP header), matching skb->len

Then the following sets gsosegs to 0 :

gsosegs = DIVROUNDUP(skb->len - hdrlen, shinfo->gsosize);

Then later we set qdiscskbcb(skb)->pktlen to back to zero :/

qdiscskbcb(skb)->pktlen += (gsosegs - 1) hdrlen;

This leads to the following crash in fqcodel [1]

qdiscpktleninit() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel.

This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug.

[1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: errorcode(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fqcodelenqueue (net/sched/schfqcodel.c:120 net/sched/schfqcodel.c:168 net/sched/schfqcodel.c:230) schfqcodel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a: 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB

Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---

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

sctp: set skstate back to CLOSED if autobind fails in sctplistenstart

In sctplistenstart() invoked by sctpinetlisten(), it should set the skstate back to CLOSED if sctpautobind() fails due to whatever reason.

Otherwise, next time when calling sctpinetlisten(), if sctpsk(sk)->reuse is already set via setsockopt(SCTPREUSEPORT), sctpsk(sk)->bindhash will be dereferenced as skstate is LISTENING, which causes a crash as bindhash is NULL.

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctpinetlisten+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> syslistensocket net/socket.c:1883 [inline] syslisten+0x1b7/0x230 net/socket.c:1894 dosyslisten net/socket.c:1902 [inline]

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

net: add more sanity checks to qdiscpktleninit()

One path takes care of SKBGSODODGY, assuming skb->len is bigger than hdrlen.

virtionethdrtoskb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.

It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes.

- 20 bytes of IPv4 header - 60 bytes TCP header - a small gsosize like 8

virtionethdrtoskb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gsosize.

We need to make detect this case to not underflow qdiscskbcb(skb)->pktlen.

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